Re: Strange behavior of git rev-list

From: Stefan Beller <sbeller@google.com>
Date: Sep 7, 2017, 19:24 UTC
Message-ID: <CAGZ79kaubRDXnetj+EXawnr50LMo4tGObz+-Bd-=KerndLfSaA@mail.gmail.com>
In-Reply-To: <20170907101126.u574pr7l5odff6zo@sigill.intra.peff.net>

On Thu, Sep 7, 2017 at 3:11 AM, Jeff King <peff@peff.net> wrote:

Show 13 quoted lines

> On Thu, Sep 07, 2017 at 11:50:25AM +0200, Paweł Marczewski wrote:
>
>> Thanks. Any plans to fix that? Or is there a way to turn off this heuristic?
>
> I don't think there's a way to turn it off for `rev-list`. Merge-base
> computations are more careful, so you could determine the correct
> endpoints that way. But when you fed them to `rev-list`, it would hit
> the same run of skewed commits.
>
> We've discussed storing true generation numbers in the past, which would
> make this optimization more robust, as well as allow us to speed up many
> other traversals (e.g., the "tag --contains"). It's something I'd like
> to revisit, but it's not at the top of the pile.

(We just had an office discussion if this is part of the hash transition plan, i.e. have a field in the commit object to contain its generation number. and as I think the generation numbers would lead to fast and correct behavior unlike the current heuristic which is only fast, I would try to make a strong point actual generation numbers inside commit objects)

Show 6 quoted lines

>
> In the meantime, it would probably be possible to write a patch that
> conditionally disables the optimization. But it would mean all of your
> rev-lists run a _lot_ slower.
>
> -Peff