Re: git mergetool broken when rerere active

From: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Date: Jan 6, 2011, 12:47 UTC
Message-ID: <alpine.DEB.1.10.1101060634480.26654@debian>
In-Reply-To: <alpine.DEB.1.10.1101052119530.26654@debian>

On Wed, 5 Jan 2011, Martin von Zweigbergk wrote:

Show 7 quoted lines

>  (2) When running mergetool again after resolving some (or all)
>      conflicts, so that some of the files have already been added to
>      the index, mergetool will now print something like
> 
>      file1: file does not need merging
>      Continue merging other unresolved paths (y/n) ?
>

The same problem should arise even the first time mergetool if run if rerere autoupdate is active and has added some files to the index.

> I would like to have both the original properties in (1) and (2) back,
> i.e. being ready for commit once 'git mergetool' has been successfully
> completed, and having it ignore any files that have already been added
> to the index.

Well, if rerere.autoupdate is disabled, any files resolved by rerere should not be touched by 'git mergetool' (this was the original request that lead to the change), but they would not be added to the index, so we would not be ready for commit. I take that part of my request back. I guess it would be ok (or even necessary) if, after resolving all the conflicts reported by 'git mergetool', the user would still have to explicitly add any files resolved by rerere and thus ignored by 'git mergetool'.

So I guess what I'm saying here, is that I think only the problem with 'delete/modify' conflicts should be fixed regarding issue (1).