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

From: Linus Torvalds <torvalds@osdl.org>
Date: Jun 9, 2005, 17:37 UTC
Message-ID: <Pine.LNX.4.58.0506091033300.2286@ppc970.osdl.org>
In-Reply-To: <7v7jh3phkk.fsf@assigned-by-dhcp.cox.net>

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

Show 6 quoted lines

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