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

[Varun Naik <vcnaik94@gmail.com>]

On Thu, Aug 15, 2019 at 9:34 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> 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