Re: Why doesn't git-rerere automatically commit a resolution?

[Shawn Pearce <spearce@spearce.org>]

Junio C Hamano <junkio@cox.net> wrote:
> Not merging the index after rerere re-applies a previous
> resolution to the working tree file is a deliberate design
> decision.  During conflict resolution, "git diff" against
> unmerged index file is the second most useful command to check
> your hand-merge result, and running update-index on these path
> automatically robs this useful tool from the user.  So, in order
> to help more disciplined workflow, a bit of convenience for
> lazier people is sacrficed here.

OK, I agree with all of the above.  Except in the following case:

	git update-ref BACKUP HEAD
	git pull . sp/topicA
	git pull . sp/topicB
	..fix conflicts..
	git commit -F .git/MERGE_MSG
	git reset --hard BACKUP

	git pull . sp/topicA
	git pull . sp/topicB
	..ah, come on!..

By pulling the exact same two heads together in the exact same
order I would expect the exact same merge result.  And since I
have git-rerere enabled I would expect it to autocommit the result
of the merge as I have already checked it before and verified its
correct when I first fixed the conflicts.

After reading your message I agree with you however that pulling in
the reverse direction (e.g. topicB then topicA) shouldn't autocommit
the merge result as I haven't hand verified it to be correct - yet.
However if I do and I merge it again later with the same two commits
then it should still be correct.

Further if I alter sp/topicA by changing a file path which wasn't
conflicted in the merge with sp/topicB I would expect it to
carry out the merge assuming the conflicts were remembered as-is.
Because that's what a trivial in-index merge would do and that will
commit despite conflicts possibly existing between files.


I guess what I'm saying is maybe git-rerere (or git-merge in general)
could benefit from a slightly higher level cache.  Store 4 sets
of (mode, sha1) tuples: stage1 stage2 stage3 result in a cache
somewhere.  If you get a conflicted merge which has been previously
fixed by hand wherein all 3 stages in the index are found in the
cache then update the index and working directory with the result
(mode, sha1) tuple.

If any of the 3 stages differs then fall back to git-rerere and
attempt a file level merge, stopping before commit to allow the
user to verify (and possibly correct) the resulting merge.

One advantage of this higher level cache is it can be used for
binary files which `merge` can't normally process, as well as for
structual conflicts.

Thoughts?  I can prototype this higher level cache into git-rerere
later tonight after I get home from work.

-- 
Shawn.