Re: [PATCH 3/3] read-tree -m 3-way: handle more trivial merges internally

On Thu, 9 Jun 2005, Junio C Hamano wrote:

I need to regurgitate other points you raised, but one immediate
comment on the "lost remove" case.  The current two-way code has
the same brokenness in that it does not unlink removed files
under "-u".  We either need the "list of files to be removed",
or we need to make two-way abort if we see these "remove" cases.

Yes, you're right.

Ho humm. I'll think about it. There's no "next" pointer in a struct 
cache-struct, and because we use the on-disk layout (good or bad, I dunno, 
but it does remove the need for copying megabytes of data for some cases) 
we can't just add one. So to generate a list of "deleted" files we'd have 
to make a separate array or something.

Not hard, but it's a bit ugly. I don't see any alternative, though, unless
we really do end up using the same "leave it in the different stages and
force people to run git-merge-cache on the result" thing that the
three-way merge does.

The fact that the three-way merge _might_ also like to remove the entries,
and that the two-way merge already handles the addition of new files, does
kind of argue that we should do it. For symmetry witht he "file add" case, 
if nothing else.

			Linus