Re: [PATCH] modify/delete conflict resolution overwrites untracked file

From: Clemens Buchacher <drizzd@aon.at>
Date: Dec 28, 2008, 11:44 UTC
Message-ID: <20081228114445.GA8511@localhost>
In-Reply-To: <7vskopwxej.fsf@gitster.siamese.dyndns.org>

On Mon, Dec 15, 2008 at 02:22:28AM -0800, Junio C Hamano wrote:

Show 20 quoted lines

> Clemens Buchacher <drizzd@aon.at> writes:
> > On Sun, Dec 14, 2008 at 07:34:46PM -0800, Junio C Hamano wrote:
> >> merge-recursive: do not clobber untracked working tree garbage
> >> 
> >> When merge-recursive wanted to create a new file in the work tree (either
> >> as the final result, or a hint for reference purposes while delete/modify
> >> conflicts), it unconditionally overwrote an untracked file in the working
> >> tree.  Be careful not to lose whatever the user has that is not tracked.
> >
> > This leaves the index in an unmerged state, however, so that a subsequent
> > git reset --hard still kills the file. And I just realized that the same
> > goes for merge-resolve. So I'd prefer to abort the merge, leave everything
> > unchanged and tell the user to clean up first.
> 
> That is unfortunately asking for a moon, I am afraid.
> 
> It needs a major restructuring of the code so that the recursive works
> more like the way resolve works, namely, changing the final "writeout"
> into two phase thing (the first phase making sure nothing is clobbered in
> the work tree, and then the second phase actually touching the work tree).

I've been giving this some thought and I would like to propose the following solution:

1. Save index state.
2. Merge using whichever strategy, in index only, ignoring work tree.
   This step includes rename detection.
3. Check that work tree files match original index, if index does not match
   HEAD. Otherwise abort, restore index and leave everything unchanged.
4. Checkout index, overwriting work tree files, and removing files which are
   in HEAD, but not in the index.
5. If the merge was clean, commit.

AFAICS, this is largely the behavior right now, except that steps 3 and 4 are intermingled with step 2, which makes it impossible to abort the merge if an untracked file is in the way after rename detection.

The idea at step 3 is that we can decide whether or not to proceed, based only on the merge result, irrespective of the strategy used, possible rename detection, or conflict resolution.

Apart from the fact that this seems like the sane thing to do, I want this behavior because it allows me to do

git merge <branch> # Conflicts? I don't have time for that now. git reset --hard HEAD

under all circumstances, without touching any untracked files.

Do you agree that this is a desireable goal?

I have not looked into d/f conflicts, but I am under the impression that this could also be handled at step 3, as far as the work tree is concerned. Is the above proposal a workable approach, which I can pursue independently of the major rewrite wrt. d/f conflicts Johannes indicated?