From: Linus Torvalds Date: Thu, 09 Jun 2005 17:37:45 GMT Subject: Re: [PATCH 3/3] read-tree -m 3-way: handle more trivial merges internally Message-ID: In-Reply-To: <7v7jh3phkk.fsf@assigned-by-dhcp.cox.net> 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