From: Daniel Barkalow Date: Sat, 27 Aug 2005 21:57:29 GMT Subject: Re: Comments in read-tree about #nALT Message-ID: In-Reply-To: <7vwtm726xq.fsf@assigned-by-dhcp.cox.net> On Sat, 27 Aug 2005, Junio C Hamano wrote: > Daniel Barkalow writes: > > > Part of threeway_merge, however, wants to search the rest of the cache for > > interfering entries in some cases, which would have to happen differently, > > because I won't have the cache completely filled out beforehand. I'm > > trying to figure out what the comments are talking about, and they seem to > > refer to a list of the possible cases. Is that list somewhere convenient? > > Please look for END_OF_CASE_TABLE in t/t1000-read-tree-m-3way.sh; > the table talks about some of the (ALT) not implemented, but > some of them are ("git whatchanged t/t1000-read-tree-m-3way" > would tell you which). It looks like all of them are implemented: #2ALT, #3ALT, #5ALT, and #14ALT, according to the commit comments, and the others seem from the email you quote to have been done in the process of getting #5ALT. > Two way cases are described in Documentation/git-read-tree.txt, > if you care. If you were not touching the three-way case right > now, I'd move/copy the three way cases there as well, but that > can wait until after your changes. I'd actually like to introduce Documentation/technical/trivial-merge for this stuff; I think it would be good to have documentation for people who need to know how the stuff works, rather than just how to use it, so we get a balance between reams of information that users don't want to wade through and being too vague for future developers. Okay, so it looks to me like the only cases that care about the contents of the index, other than in stage 0 (which is effectively another tree, but already in index-form rather than tree-form), are 2 and 3, and these only care because read-tree modifies the stage of entries, rather than removing them and adding a stage-0 replacement entry; if it went through the add logic without SKIP_DFCHECK, that would reject the same things that causes_df_conflict rejects (at the point where whichever is second is done). So if I do the merge on tree entries (plus a stage-0 ce for the input from the index), and then add the result(s) to the cache, I can skip causes_df_conflict() in favor of just not using SKIP_DFCHECK. Is this right? Also, there doesn't actually seem to be a DF test in t1000; I think the t1005 DF test covers these cases (by the emu23 path into this code). Is this right? -Daniel *This .sig left intentionally blank*