Johan Herland <jo...@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.
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 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?"
*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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html