Subject: Re: Bug report: git branch behaves as if --no-replace-objects is passed

From: Junio C Hamano <[email-masked]>
Date: Tue, 30 Mar 2021 14:59:30 -0700

Elijah Newren <[email-masked]> writes:

> On Tue, Mar 30, 2021 at 2:19 PM Elijah Newren <[email-masked]> wrote:
>>
>> On Tue, Mar 30, 2021 at 11:58 AM Junio C Hamano <[email-masked]> wrote:
>> >
>> > Jeff King <[email-masked]> writes:
>> >
>> > > ... though if we go that route, I suspect we ought to be adding both the
>> > > original _and_ the replacement.
>> >
>> > So "branch --contains X" would ask "which of these branches reach X
>> > or its replacement?" and "branch --no-contains X" would ask "which
>> > of these do not reach X nor its replacement?" --- I guess the result
>> > is still internally consistent (meaning: any and all branches fall
>> > into either "--contains X" or "--no-contains X" camp).
>>
>> I'm not so sure about this interpretation.  Based on the documentation
>> in git-replace(1):
>>
>>        Replacement references will be used by default by all Git commands
>>        except those doing reachability traversal (prune, pack transfer and
>>        fsck).

This "rechability" sidenote is primarily so that we won't result in
a corrupt repository when replacement is lifted.  When object A is
replaced by object B, and somebody makes A reachable (e.g. a ref
points at deadbeef), we mark both A (and the objects A refers to)
and B reachable, so that "prune" won't lose A.  It would allow the
replacement lifted after "prune".

Tweaking "branch --contains X" to list branches that reach either X
or its replacement would probably have the same effect, so I would
think it would be a good change (and fix to your original issue).

The "the result is still internally consistent" comment was the
result of my attempt to make sure such a change would not introduce
gross incoherency to the resulting system.