Re: [RFC PATCH] unpack-trees.c: handle empty deleted ita files

From: Varun Naik <vcnaik94@gmail.com>
Date: Aug 19, 2019, 15:35 UTC
Message-ID: <CAK_rgsHKaLkO_wputOKcHBTDTnyvOUNTABUKK3fKc3ddiaNzQQ@mail.gmail.com>
In-Reply-To: <xmqqtvai4cc4.fsf@gitster-ct.c.googlers.com>

On Thu, Aug 15, 2019 at 9:34 AM Junio C Hamano <gitster@pobox.com> wrote:

Show 19 quoted lines

>
> Varun Naik <vcnaik94@gmail.com> writes:
>
> > On Tue, Aug 13, 2019 at 1:33 PM Junio C Hamano <gitster@pobox.com> wrote:
> >>
> >> So perhaps
> >>
> >> +       !ce_intent_to_add(a) && !ce_intent_to_add(b) &&
> >>
> >> i.e. "a cache entry is eligible to be same with something else only
> >> when its I-T-A bit is unset".
> >>
> >
> > I decided to follow René's suggestion in response to this. Patch coming soon.
>
> Either is fine as the implementation of the same semantics; I
> however am not sure if two I-T-A entries should compare "same" or
> "not same", or if we are better off catching the caller that feeds
> two I-T-A entries to same() with a BUG().

I'd argue that two ita cache entries should be a BUG. Since we believe that a cache entry in the tree can never have the intent-to-add bit set, it suffices to show that no call to same() ever passes two cache entries from the index.

The call in unpack-trees.c:merged_entry() compares the "old" entry (which comes from the index in all cases) to a newly created "merge" entry (which is a duplicate of an entry from a tree in all cases). All other calls compare either entries from two trees, or an entry from a tree and an entry from the index. I also can't think of any case where someone would want to check if two index entries are the "same" in the future.

The same argument probably extends to the conflicted bit, but changing that is probably out of scope of this patch.

Varun