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

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