git-absorb (https://github.com/tummychow/git-absorb) does a bit more, figuring out the exact changes that should be fixed up.

JJ absorb does the same as far as I understand

git-autofixup is better and easier to install: https://github.com/torbiak/git-autofixup

Could you elaborate how it is better?

They are quite different methods, explained by the respective implementations. IME autofixup finds the relevant commit successfully more often. There's no reason you can't use both, of course. I would always check the results of either before actually doing the rebase.

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.

git-absorb does exist [1]. It seems to be inspired by a mercurial subcommand of the same name. It's also available in most distro repos.

[1] https://github.com/tummychow/git-absorb

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: git add . git commit --amend

and when I make a nee "keyframe commit": git commit -m "wip: [desc 2]"

and still amend fixes.

Occasionally I'll make a change that I know fixes something earlier (i.e. an earlier "keyframe" commit) but I won't remember it. I'll commit and then do: git add . git commit -m "fixup: wip desc, enough to describe which keyframe commit should be amended"

at the end I'll do a git rebase -i main and see something like:

123 wip: add readme (it's already had a number of amends made to it) 456 wip: add Makefile (also has had amendments) 789 wip: add server (ditto) 876 fixup: readme stuff 098 fixup: more readme 543 fixup: makefile

and I'll use git rebase -i to change it to reword for the good commits, and put the fixups right under the ones they edit. then i'll have a nice history to fast forward into main.

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.

You can combine this with the `:/<text>` syntax [0] for matching the most recent commit with a given text in the commit message, e.g.

    $ commit frobinator/ -m "refactor the frobnicator"

    [ more work ]

    $ commit echaton/ -m "immanentize the eschaton"

    [ oops, missed a typo ]

    $ commit frobinator/ --fixup :/frobic

0: https://stackoverflow.com/a/52039150

Thanks, I am —- but I always found it easier to just give the new commit a name I know how to squash rather than type in a SHA.

The other post about being able to do it on a substring match sounds way more ergonomic though, I’ll have to try that!