[dmsnell]

You can interactively rebase after the fact while preserving merges even. I usually work these days on stacked branches, and instead of using —-fixup I just commit with a dumb message.

    git rebase -i --rebase-merges --keep-base trunk

This lets me reorganize commits, edit commit messages, split work into new branches, etc… When I add --update-refs into the mix it lets me do what I read are the biggest workflow improvements from jj, except it’s just git.

This article from Andrew Lock on stacked branches in git was a great inspiration for me, and where I learned about --update-refs:

https://andrewlock.net/working-with-stacked-branches-in-git-...

[sshine]

That’s great advice, thanks for sharing --update-refs!

But I don’t see how that removes the usefulness of fixup commits, only that you can do them across stacked branches with ease.

But you’re saying I don’t need the particular hash of the parent, I can just rebase all the way back to main/trunk each time. That’s a good point!

I think I’m still saving time by fixup, it was the second hash lookup I wasn’t happy with.

I like to rebase my fixups immediately when possible so I don’t forget.

[dmsnell]

You understand it correctly: it doesn’t remove any value from fixup; instead it just means you can fixup to whatever and move the commit visually to where you want it — doesn’t have to be the main/trunk branch, and you can do it whenever is convenient.

That’s where I made the comment about not actually running fixup. Instead of claiming to fix a SHA, I leave myself a note like “fix tests” so I can move it appropriately even if I get distracted for a few days