Junio C Hamano <gits...@pobox.com> writes: > To populate the database, we'd need a reverse. > ... > * Then the user tells Git that semantic conflicts were resolved and > need to be recorded (just like running "git rerere" manually, > before "git commit" automatically does it for them these days). > This will result in the following: > > - The database is updated so that key <A, B> yields the > "merge-fix" commit; > ...
I probably should have been aiming for stars, as I were outlining the ideal merge-fix logic. The key <A, B> is merely a default, and the worst one at that. There should be a way for the user to tell which exact pair of commits (i.e. another side branch that was merged earlier to the mainline A that renamed 'xyzzy' to 'frotz' wholesale, and the exact commit on the side branch B that added an extra mention of 'xyzzy'). If the logic can figure out what these two commits are without user's help, mechanically by only looking at the merge-fix commit, that would be even better. But I do not believe in miracles, so...
