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

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.

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

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.