Re: Premerging topics

[Junio C Hamano <gitster@pobox.com>]

Johan Herland <johan@herland.net> writes:

> Can you solve this problem with a tree object, instead of inventing a
> specially-formatted blob?

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.