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. 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. -- 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
