Not wrong of course — thank you for your amazing guides! But feedback re: "15.7 Multiple Conflicts in the Rebase":

There are two things I suggest as workflows for people when I teach them about rebase workflows.

> Since rebase “replays” your commits onto the new base one at a time, each replay is a merge conflict opportunity. This means that as you rebase, you might have to resolve multiple conflicts one after another. ... This is why you can conclude a merge with a simple commit, but ...

For multiple conflicts on several commits being replayed, if it's _not_ useful to go through them all one at a time, I suggest that people do a squash first rebase from the fork point (which by definition can not have conflicts) to collapse their commits into a single commit first, and then rebase again from the branch.

For instance, if forked from main:

    git rebase -i `git merge-base main --fork-point`

Squash all of those, and then as usual:

    git rebase -i main

Second, when rebasing repeatedly onto an evolving branch over time, you'll often find yourself resolving the same merge conflicts over and over again.

"rerere" (https://git-scm.com/book/en/v2/Git-Tools-Rerere) will allow git to "reuse recorded resolution" so that you don't have to do them manually each time.

My gitconfig for these:

    [alias]
     forked = "!f() { git merge-base $1 --fork-point; }; f"
     squash-first = "!f() { git rebase -i `git merge-base $1 --fork-point`; }; f"
    [rerere]
     enabled = true

user:	yrotslluf
created:	February 5, 2025
karma:	6