Re: Strange behavior of git rev-list

[Stefan Beller <sbeller@google.com>]

On Thu, Sep 7, 2017 at 3:11 AM, Jeff King <peff@peff.net> wrote:
> 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)

>
> 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