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