More new git tricks:
A 'git rebase -i' allows you to edit a past commit. However, it will 'serialize' the history, losing any branch/merge 'structure' there might have been.
A 'git rebase -i --rebase-merges' keeps the branch/merge 'structure', however, it is not obvious how to 'edit' a merge commit.
You can, though: you can insert a 'break' in the rebase to edit and 'commit --amend' a merge commit.
https://stackoverflow.com/questions/9930637/edit-a-merge-commit-with-git-rebase
Unfortunately, you'll have to solve all merge conflicts again.
If you had "git rerere" enabled, it can at least have it re-solve 'both modified' conflicts for you, though you'll still have to explicitly 'add' them and it won't solve conflicts in added/removed files.
If you didn't have "git rerere" enabled yet, you can try "rerere-train.sh HEAD" https://raw.githubusercontent.com/git/git/master/contrib/rerere-train.sh
@raboof Oh, nice!
> the break command (added in Git 2.20)
Sweet! I've been using the trick originally described, putting a dummy edit after the merge and then resetting back to the merge, for years!
I absolutely love --rebase-merges and use it many times per day to build and keep track of multiple parallel PRs.
@clacke yeah - it's still a huge pain in the butt though, especially with (re)moved files or when a merge contains fixes that are not directly visible to git as merge conflicts.
I guess you could say "don't do that then", but... too late for that ;)
raboof
Ben Companjen 🟥
clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛