Merge Conflicts Resolving and Remembering them

Work in Progress as I try and work out how to do this (06-04-2019)..

When building a new release for Git-for-Windows, the full range of Windows patches the maintainer applies need to be moved (rebased) from being on top of the old upstream Git, to being on top of the new upstream release.

There is a process, a script and the support of the merging-rebase code, but still there maybe conflicts, old and new, especially if some of the Windows code has been adopted upstream in a different form.

This note looks at how to remember those resolutions, reuse them, and to learn from previous Git-for-Windows rebases. The magic is in the REuse REcorded REsolution (rerere) command and it's underlying database.

The documentation is terse, so let's also point to some on-line articles:

• Fun with rerere from the Git maintainer
• Fix conflicts only once with git rerere Nice graphs and examples.
• Do you even rerere? Good discussion, including rerere-train.
• rerere-train.sh use the 'blame' button for extra commit info.
• Are there any downsides to enabling git rerere? Not really, but read and learn.
• Smarter rebase avoiding redundant work? more rerere-train answers
• 7.9 Git Tools (book) - Rerere.

So, enable rerere - git config --global rerere.enabled true,
consider setting git config --global rerere.autoupdate true and away you go!

Determine a previous Git-for-Windows merging-rebase end points and run the contrib/rerere-train.sh

Remember the parameters passed to rerere-train are <rev-list-args> (apparently) for selecting the training set.

From the git List

Threads about the internal workings:

saving and replaying multiple variants with rerere 2015-09-14
Should rerere auto-update a merge resolution? 2017-08-23
rebase: use OPT_RERERE_AUTOUPDATE() 2019-03-19
git/Documentation/technical/rerere.txt