Re: history damage in linux.git

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Apr 21, 2016, 17:59 UTC
Message-ID: <CA+55aFzYWoeUq3MFgGtELaN-2sEc4j3egsAHZHVzK1CNPOqhKQ@mail.gmail.com>
In-Reply-To: <CA+55aFwOtyW7zLHdJND=FGBWKBfhQV95RPVRG5gcoRUrtGCrAQ@mail.gmail.com>

On Thu, Apr 21, 2016 at 10:43 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote:

>
> In other words, I'm trying to convince people that my patch not only
> gives a good result, but that the "weight numbers" I use make some
> kind of conceptual sense from a complexity cost angle.

Basically, the patch approximates the numerical representation of the distance measure with the complexity of the suffix.

It's not a *true* length of the suffix (which does heavily favor first-parent use, kind of like the current code), but I think it's better than the pretty random "+65535" that the current git code has. That number is clearly just completely made up. The new numbers at least have some kind of logic behind them.

And the current code obviously does give really bad results. Picking the v4.6-rc1 tag as a base just because it happens to get a lot of first-parent traversals (800!) from one second-parent commit that is close to 4.6-rc1 is just obscene.

So the more I look at my patch, the more I go "it's a real improvement on the current situation".

That said, I do think that a much bigger conceptual change that actually does full traversal and be much more complicated might be the only "correct" solution.

So my patch is just a "improve heuristics" small fixlet rather than something optimal.

                 Linus