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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 30, 2021, 21:59 UTC
Message-ID: <xmqq5z18cngd.fsf@gitster.g>
In-Reply-To: <CABPp-BFewHGOx-RCVtDKhn3=0QC9YWdA--Wtbb_MTHQbu3FQcw@mail.gmail.com>

Elijah Newren <newren@gmail.com> writes:

Show 21 quoted lines

> On Tue, Mar 30, 2021 at 2:19 PM Elijah Newren <newren@gmail.com> wrote:
>>
>> On Tue, Mar 30, 2021 at 11:58 AM Junio C Hamano <gitster@pobox.com> wrote:
>> >
>> > Jeff King <peff@peff.net> 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.