change-cluster?
My new Git utility `what-changed-twice` needs a new name
31–40 of 65 posts
Re: My new Git utility `what-changed-twice` needs a new name
#32> There's bonus information too. If a commit is not mentioned in the report, then it only changed files that didn't change in any other commit. That means that in a rebase, I can move that commit literally anywhere else in the sequence without creating a conflict. Only the commits in the report can cause conflicts if they are reordered. This is only true in the textual level. Semantically, re-shuffling commits like t…
This is why I no longer do atomic commits. I've just never had it be a benefit to walk through and guarantee that each commits tests and builds successfully. I so rarely back out changes that when I do, I test then that everything is working (and let's be honest, I back out usually at the PR level, not the commit).
If you want atomic commits, you need to set up your CI/CD to ensure that each intermediate commit builds and passes tests.
Most pull requests should probably be squashed to appear as a single commit in the final history. But you should have the option of leaving history intact, when you want that, and then your CI/CD should run the checks as above.
Re: My new Git utility `what-changed-twice` needs a new name
#33Earlier quoted context omitted.
This is why I no longer do atomic commits. I've just never had it be a benefit to walk through and guarantee that each commits tests and builds successfully. I so rarely back out changes that when I do, I test then that everything is working (and let's be honest, I back out usually at the PR level, not the commit).
The other benefit of this is the git bisect workflow. If you can’t build your intermediate commits then you likely can’t easily identify whether a bug was present on that commit (for many types of bug), and you therefore can’t identify the commit that introduced the bug.
Yes, but at least git bisect lets you mark a commit as 'skip' in these cases.
Re: My new Git utility `what-changed-twice` needs a new name
#34Earlier quoted context omitted.
I agree. I decided years ago that that was a lot of work for little or no benefit. It's enough for the tests to pass at each merge point.
…and that’s why squash merge should be the default setting in PRs.
Yes, it should be the default, but ideally you have the option of preserving history (for PRs where that makes sense) and then your CI/CD should also check that the individual commits build and pass tests.
In general, your CI/CD should make sure that each commit that appears in the 'public' history of main builds and passes tests.
Re: My new Git utility `what-changed-twice` needs a new name
#35Jujutsu has a command which is helpful for this sort of workflow called absorb which pushes all changes from the current commit into the most recent commit which modified that file. (Each file may be merged into a different commit).
git-absorb ( https://github.com/tummychow/git-absorb ) does a bit more, figuring out the exact changes that should be fixed up.
git-autofixup is better and easier to install: https://github.com/torbiak/git-autofixup
Re: My new Git utility `what-changed-twice` needs a new name
#36Earlier quoted context omitted.
git-absorb ( https://github.com/tummychow/git-absorb ) does a bit more, figuring out the exact changes that should be fixed up.
git-autofixup is better and easier to install: https://github.com/torbiak/git-autofixup
Could you elaborate how it is better?
Re: My new Git utility `what-changed-twice` needs a new name
#37"what-changed-twice" tells me exactly what the command does. "squash-what" tells me nothing, why is the program name asking me what to squash, and then why does it not squash? The only inaccuracy I can think of in the name is that it's technically "what-changed-more-than-once." But if something has changed thrice, by definition it's also been changed twice.
what-changed-once-moreRe: My new Git utility `what-changed-twice` needs a new name
#38> There's bonus information too. If a commit is not mentioned in the report, then it only changed files that didn't change in any other commit. That means that in a rebase, I can move that commit literally anywhere else in the sequence without creating a conflict. Only the commits in the report can cause conflicts if they are reordered. This is only true in the textual level. Semantically, re-shuffling commits like t…
This is why I no longer do atomic commits. I've just never had it be a benefit to walk through and guarantee that each commits tests and builds successfully. I so rarely back out changes that when I do, I test then that everything is working (and let's be honest, I back out usually at the PR level, not the commit).
I often wonder what the point of using git at all is at this point. I suppose it's just your interface to the source repo, but a massively overly capable one. If you don't care about atomic commits then you might as well just do `git commit -a --amend --no-edit` periodically (you could even do it on every save). Then the reflog is your "undo" but you don't pollute the shared repo with shit commits.
Re: My new Git utility `what-changed-twice` needs a new name
#39Jujutsu has a command which is helpful for this sort of workflow called absorb which pushes all changes from the current commit into the most recent commit which modified that file. (Each file may be merged into a different commit).
This seems very similar to how I work by default. I sort of think in terms of "keyframes" and "frames", or "commits" and "fixes to commits." Whenever I sit down to code with a purpose, I'll make a branch for that purpose: git checkout -b wip/[desc] When I make changes that I think will be a "keyframe" commit, I use: git add . git commit -m "wip: desc of chunk" (like maybe "wip: readme") if I make refinements, I'll do…
I think you might be aware given the specific words you use but for the benefit of others:
Git commit --fixup lets you attach new commits to previous hashes you specify and then can automatically (or semi-manually depending on settings) squash them in rebases.
Re: My new Git utility `what-changed-twice` needs a new name
#40Tools like this are also useful if you need to cherry pick a patch onto a release branch and want to know potential dependencies:
↑ newer
D* fixes bug in crypto.py
C
B* rewrites crypto.sh in Python
A
0 last month’s release
↓ older
You get false positives and false negatives: if B fixed a comment typo for example it’s not really a dependency, and if C updated a module imported in the new code in D you’d miss it. (For the latter, in Python at least, you can build an import DAG with ast. It’s a really useful module and is incredibly fast!)
So I would say the author’s tool is really multiple tools:
1/ build a dependency graph between commits based on file changes in a range of commits;
2/ automate the reordering and squashing of dependent commits on a private dev branch;
3/ automate cherry-picking commits onto a proposed release branch (which is basically the same as git-rebase -i); and
4/ build a dependency graph based on external analysis (in my example, Python module imports) rather than / as well as file changes.
Their use case is (1) and (2), (3) is a similar but slightly different tool to (2), and (4) is a language specific nicety that goes beyond the scope of simple git changes for, arguably, diminished returns.