My new Git utility `what-changed-twice` needs a new name
blog.plover.com
My new Git utility `what-changed-twice` needs a new name
1–10 of 65 posts
Re: My new Git utility `what-changed-twice` needs a new name
#2You know, I find myself partially agreeing that a number of utilities for git could be done quite nicely in perl.
Re: My new Git utility `what-changed-twice` needs a new name
#3Jujutsu 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).
Re: My new Git utility `what-changed-twice` needs a new name
#4Jujutsu 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).
Yes, totally useful compared to default git base commands.
And also - melding the "changed twice" (or thrice...) mutations into a single commit is a brilliant isolation of a subtle common pattern.
Re: My new Git utility `what-changed-twice` needs a new name
#5I am familiar with an algorithm that stably brings a disjoint selection of items together around a specified point. Sounds similar to this case, where the disjoint selection are changes that happened to a given file.
The name of the algorithm is “gather”, by Sean Parent and Marshall Clow.
Re: My new Git utility `what-changed-twice` needs a new name
#6> 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 this can still cause conflicts. Ie it can break your tests. Not at the end, but for the intermediate commits.
Re: My new Git utility `what-changed-twice` needs a new name
#7You know, I find myself partially agreeing that a number of utilities for git could be done quite nicely in perl.
Git's repository includes quite a bit of Perl, but they want to get rid of it.
Re: My new Git utility `what-changed-twice` needs a new name
#8I am familiar with an algorithm that stably brings a disjoint selection of items together around a specified point. Sounds similar to this case, where the disjoint selection are changes that happened to a given file. The name of the algorithm is “gather”, by Sean Parent and Marshall Clow.
"muster" comes to mind and is different than "gather".
Re: My new Git utility `what-changed-twice` needs a new name
#9> 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).
Re: My new Git utility `what-changed-twice` needs a new name
#10FlipFlopStop?
FFS for short, which has suitably disgruntled other exclamatory meanings.