You know, I find myself partially agreeing that a number of utilities for git could be done quite nicely in perl.

Jujutsu 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).

I 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.

> 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.

FlipFlopStop?

FFS for short, which has suitably disgruntled other exclamatory meanings.

git-delta -n <times>

i.e. git-delta -n 2 = 'what changed twice'

or if its just what changed twice in every case then just 'git-delta-delta'