Re: [RFC PATCH] GIT-VERSION-GEN: set --abbrev=9 to match auto-scaling

Jeff King [off-list ref] writes:

On Sun, Dec 04, 2016 at 08:45:59PM +0000, Ramsay Jones wrote:

quoted

Signed-off-by: Ramsay Jones <redacted>
---

Hi Junio,

I recently noticed that:

    $ make >pout 2>&1
    $ ./git version
    git version 2.11.0.286.g109e8a9
    $ git describe
    v2.11.0-286-g109e8a99d
    $

... for non-release builds, the commit part of the version
string was still using an --abbrev=7.

It seems like this kind of discussion ought to go in the commit message.
:)

That said, I think the right patch may be to just drop --abbrev
entirely.
...
I think at that point it was a noop, as 7 should have been the default.
And now we probably ought to drop it, so that we can use the
auto-scaling default.

Yeah, I agree.

It does mean that snapshot binaries built out of the same commit in
the same repository before and after a repack have higher chances of
getting named differently, which may surprise people, but that
already is possible with a fixed length if the repacking involves
pruning (albeit with lower probabilities), and I do not think it is
a problem.

On Mon, Dec 05, 2016 at 10:01:19AM -0800, Junio C Hamano wrote:

quoted

That said, I think the right patch may be to just drop --abbrev
entirely.
...
I think at that point it was a noop, as 7 should have been the default.
And now we probably ought to drop it, so that we can use the
auto-scaling default.

Yeah, I agree.

It does mean that snapshot binaries built out of the same commit in
the same repository before and after a repack have higher chances of
getting named differently, which may surprise people, but that
already is possible with a fixed length if the repacking involves
pruning (albeit with lower probabilities), and I do not think it is
a problem.

I think that the number is already unstable, even with --abbrev, as it
just specifies a minimum. So any operation that creates objects has a
possibility of increasing the length. Or more likely, two people
describing the same version may end up with different strings because
they have different objects in their repositories (e.g., I used to
carry's trast's git-notes archive of the mailing list which added quite
a few objects).

I agree that having it change over the course of a repack is slightly
_more_ surprising than those cases, but ultimately the value just isn't
stable.

-Peff