From: Junio C Hamano <gitster@pobox.com>
To: Elijah Newren <newren@gmail.com>
Cc: Jeff King <peff@peff.net>, Git Mailing List <git@vger.kernel.org>
Subject: Re: Bug report: git branch behaves as if --no-replace-objects is passed
Date: Tue, 30 Mar 2021 14:59:30 -0700 [thread overview]
Message-ID: <xmqq5z18cngd.fsf@gitster.g> (raw)
In-Reply-To: <CABPp-BFewHGOx-RCVtDKhn3=0QC9YWdA--Wtbb_MTHQbu3FQcw@mail.gmail.com> (Elijah Newren's message of "Tue, 30 Mar 2021 14:30:56 -0700")
Elijah Newren <newren@gmail.com> writes:
> 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.
next prev parent reply other threads:[~2021-03-30 22:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-30 6:05 Bug report: git branch behaves as if --no-replace-objects is passed Elijah Newren
2021-03-30 7:02 ` Jeff King
2021-03-30 18:58 ` Junio C Hamano
2021-03-30 21:19 ` Elijah Newren
2021-03-30 21:30 ` Elijah Newren
2021-03-30 21:59 ` Junio C Hamano [this message]
2021-03-30 21:53 ` Junio C Hamano
2021-03-30 22:43 ` Elijah Newren
2021-03-30 23:04 ` Junio C Hamano
2021-03-31 0:32 ` Elijah Newren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq5z18cngd.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=newren@gmail.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.