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

I'm curious... I have a pair of topic branches which don't merge together cleanly by recursive (due to conflicting hunks in the same line segments). I enabled git-rerere, ran the merge, fixed up the hunks and committed it. git-rerere built its cache, as the next time I pulled the two topic branches together and got the same conflicts it correctly regenerated the prior resolution (and printed a message saying as much).

But it git-rerere left the files unmerged in the index and it doesn't generate a commit for the merge, even though there are no merge conflicts remaining. I expected it to update the index (to merge the stages) and to generate a commit if possible; especially in this case as I was pulling the exact same two commits together again with the exact same merge base commit.

So I'm wondering why doesn't it try to finish the merge? Was there a really deep rooted reason behind it or was it simply easier/safer to let the user sort out the working directory state every time?

Shawn Pearce <spearce@spearce.org> writes:

After all your merge is conflicting, so it should be sanity checked. At least you would want to run a compile test and preferably a whole test cycle if your project has one, before making the result into a commit.

You _could_ make it to automatically make a commit, and run a test then if the test does not succeed fix the mismerge with "git commit --amend", but people are lazy.

The philosophy is to optimize the tools to support disciplined workflows better, and make sure that the users do not have to worry about automated tools makeing mismerges.

Now, I am not against helping lazy workflows per se, but only on one condition. Doing so should never make more disciplined workflows harder or more difficult.

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.

Junio C Hamano <junkio@cox.net> wrote:

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 Pearce (spearce@spearce.org) wrote:

I am maintaining different websites from one git repository. The code is almost the same between all versions, but the HTML templates are not. Sometimes, modified templates in feature branches produce mismerges which I want to fix up in different ways for different websites. There, git-rerere doesn't help me at all. It does help very much with the code and configuration files though.

To conclude, I have rerere enabled, but it does not always do the right thing, so I am happy that I get a chance to inspect the files before committing (I could also amend the commit later, but I still think it's better that the user still needs to acknowledge the result of the automatic merge.)

	Matthias