Hi, On Mon, 15 Dec 2008, Mike Ralphson wrote: > 2008/12/15 Junio C Hamano <gitster@xxxxxxxxx>: > > Clemens Buchacher <drizzd@xxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
