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

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

[Shawn Pearce]

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.

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

[Junio C Hamano]

Shawn Pearce <spearce@spearce.org> writes:

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

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.

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

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.

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

[Matthias Kestenholz]

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

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

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

[Shawn Pearce]

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.