Re: history damage in linux.git

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Apr 21, 2016, 18:18 UTC
Message-ID: <CA+55aFzEVy6BsVzTrYda3Nfo4o+QtqiqsX5xJqRt=se0eREDsA@mail.gmail.com>
In-Reply-To: <20160421180507.GA12950@sigill.intra.peff.net>

On Thu, Apr 21, 2016 at 11:05 AM, Jeff King <peff@peff.net> wrote:

>
> I actually think the best name for aed06b9 is probably:
>
>   v3.13-rc1~65^2^2~42

Sounds likely. I don't know how to find that best match without a complete rewrite, though.

My recent patch that got

  v3.13-rc2~32^2^2~47

comes close to that, and the complexity is similar but the numbers are actually smaller, so I guess my heuristic did indeed find a "simpler" name, but yes, the one based on 3.13-rc1 would definitely be the better one.

> which I found by picking the oldest tag from "git tag --contains" and
> plugging it into "git describe --match".

Yeah, so you basically did the "let's figure out minimal inclusion" by hand.

> Sadly, neither git's internal
> version-sorting nor GNU's "sort -V" knows that "v1.0-rc1" comes before
> "v1.0", so I had to rely on "--sort=taggerdate".

I'm not seeing the "sadly".

I think "--sort=taggerdate" is pretty much the only sane sort there is for tags, unless you do a true and full topological one (ie sort based on by how many commits that tag encompasses, but also by how each tag contains another tag).

              Linus