Re: Premerging topics

Johan Herland <johan@herland.net> writes:

Hmm.  What problem are you guys trying to solve?

I think Michael's use of a merge commit to record a merge result is sufficient as a means to record how to recreate an evil merge.

  http://thread.gmane.org/gmane.comp.version-control.git/212570/focus=212578

FWIW, in the [RFD], I wasn't asking for ideas on that part. When rebuiling 'pu', I use an even simpler solution to have rerere autoresolve the mechanical part of the merge, and then cherry-pick a separate commit from refs/merge-fix/ hierarchy on the result, and it works perfectly fine (this is done by the 'Reintegrate' script on the 'todo' branch; see Documentation/howto/maintain-git.txt).

When topic A is closer to be done than topic B (in other words, when I merge topic B to an integration branch, topic A is already merged there), and these topics have semantic conflicts (e.g. A renames a function foo() to bar(), while B adds a new callsite of foo()), a mechanical merge of B may succeed without any textual conflict (or if there is, rerere can resolve it), but a semantic fix-up needs to do "s/foo/bar/g" on the result.

I would do something like this for the first time:

	... while on 'pu', A has already been merged ...
        git merge B ;# may conflict
        edit textual conflicts away
        git rerere ;# remember the textual resolution
        git commit ;# commit _without_ semantics adjustment
        edit semantic conflict away, i.e. s/foo/bar/g
        git commit
        git update-ref refs/merge-fix/B

After that, next time I rebuild 'pu', when the automated procedure processes B, it would "git merge B", "git rerere", make sure textual conflicts are gone, and "git cherry-pick refs/merge-fix/B". To make sure this would work, what I typically do immediately after doing all of the above is:

	git reset --hard HEAD^^

to drop the fix-up commit and merge of B, and actually tell the automated procedure to process B. It should recreate the evil merge using the information I just recorded.

So "how a recipe to recreate an evil merge is recorded", as far as I am concerned, is an already solved problem.

The part of the existing solution I was not happy was deciding when to use which "merge-fix" commit to cherry-pick. If I start merging topic B before topic A, the "merge-fix/B" needs to be renamed to "merge-fix/A" in the above. Otherwise, when B is merged to 'pu', there is no 'A' merged to it yet, so merge-fix that munges its new call to foo() to call bar() instead will _break_ things [*1*].

And that was why I wanted to have a data structure that is quick to query to answer "I am about to merge B. Does the history already have an A for which I have recorded a merge-fix for <A,B> pair?"

[Footnote]

*1* If A has other kinds of conflicts with other topics, it is not sufficient to just rename "merge-fix/B" to "merge-fix/A"---the effect of cherry-picking "merge-fix/B" needs to be merged to existing "merge-fix/A". If a merge-fix is recorded for a pair of commits that necessitates an evil merge, this naturally goes away. I can keep a merge-fix for the <A,B> pair whether I merge A before or after B, and semantic conflicts A may have with another topic C would be stored in a separate merge-fix for <A,C> pair.