Re: Comments in read-tree about #nALT

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Aug 27, 2005, 23:15 UTC
Message-ID: <Pine.LNX.4.63.0508271855100.23242@iabervon.org>
In-Reply-To: <Pine.LNX.4.63.0508271709530.23242@iabervon.org>

On Sat, 27 Aug 2005, Daniel Barkalow wrote:

Show 13 quoted lines

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

What I missed was that the effect of causes_df_conflict is to give "no merge" for the entry, rather than giving an error overall. So I do need an equivalent.

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

Looks like stuff all over the place fails if causes_df_conflict is messed up, so I should be covered.

	-Daniel
*This .sig left intentionally blank*