Re: limiting git branch --contains

[Oswald Buddenhagen <oswald.buddenhagen@gmx.de>]

On Fri, Mar 24, 2023 at 04:45:04PM -0400, Jeff King wrote:
>On Fri, Mar 24, 2023 at 08:58:39PM +0100, Oswald Buddenhagen wrote:
>> so i tried git log --graph ... and still nothing?!
>
>That "--graph" option is unrelated. It asks for Git to draw a graph in
>the output.
>
i know. it just happens to be the go-to example from derrick's blog post 
about commit-graph, so that not working was a dead giveaway that 
something is really wrong.

>> a3628e41a9946c4fe93d9b2ae5906e1b2184fa8e refs/replace/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
>
>Ah, that is your problem. When "replace" refs are in use, the data
>stored in the commit-graph can't reliably be used. [...]
>
why isn't the commit-graph built with the replaces applied (and tagged 
by a hash of the used replaces, so we know when to ignore it)?

at minimum, i'd expect a warning giving a reason when the graph is 
ignored.

>  git -c core.useReplaceRefs=false branch --contains ...
>
>which I think should get faster.
>
yes, that works. and _rather_ convincingly, to put it that way.

>I'd still be curious to see the
>difference between "just commit graphs" and "commit graphs plus the
>patch I showed earlier". I think it should make things faster, but if
>it's only a few milliseconds on average, it's not that urgent to pursue.
>
if there is a speed difference at all, it gets drowned out by the noise.