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

From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Mike Ralphson <mike.ralphson@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	Clemens Buchacher <drizzd@aon.at>,
	git@vger.kernel.org, raa.lkml@gmail.com
Subject: Re: [PATCH] modify/delete conflict resolution overwrites untracked file
Date: Mon, 15 Dec 2008 12:09:04 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.1.00.0812151206360.30933@intel-tinevez-2-302> (raw)
In-Reply-To: <e2b179460812150250t6e028330xf0e0ff626c1b6b3c@mail.gmail.com>

Hi,

On Mon, 15 Dec 2008, Mike Ralphson wrote:

> 2008/12/15 Junio C Hamano <gitster@pobox.com>:
> > 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 wonder if another approach is workable... to read 'vulnerable' 
> untracked working tree files into a new (temporary, uncommittable) stage 
> in the index, perform whatever merging is required, then reinstate all 
> entries from the new stage.

I think the solution is not in making things more complicated, but 
simpler.  I agree with Junio that the recursive merge needs a major 
rewrite which respects d/f conflicts and renames in the _design_, not as 
an afterthought.

Besides, I really do not want untracked files to be inserted into a stage.  
Remember, adding something to the index means to hash it, and I do have 
half-a-gigabyte untracked data in some of my worktrees.

Ciao,
Dscho