Regarding the determinacy of 'git describe'

Regarding the determinacy of 'git describe'

[Andreas Krey]

Hi all again,

today another expectation crumbled.

I expected the algo of 'git describe' to be deterministic,
but it happens to return different tags in structurally
identical repositories. These are generated on each run
of a test (and obviously have different dates and thus
commit IDs), and 'git describe' doesn't return the same
tags in all of them.

Is that expected behaviour?

The repos each look like
(commit id and parents truncated to three chars):

538 26d 8f5         (HEAD, origin/r2.4/feature-2, r2.4/feature-2) Merge branch 'r2.4/master' into r2.4/feature-2
    26d         20c feature: 1st part
        8f5 ac6     (origin/r2.4/master, origin/HEAD, r2.4/master) main: 3rd commit
            ac6 20c (tag: r2.4/bl-1) main: 2nd commit
                20c (tag: r2.4/bl-0, origin/sidestep) module: initial

So HEAD is two hops away from both tags (bl-0 via 26d and bl-1 via 8f5),
but for one I'd hoped that it always pick bl-1, and especially I'd expect
it to be consistent for a given structure).

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Regarding the determinacy of 'git describe'

[Andreas Krey]

To follow up on myself, this is the output of 'git describe --debug
--tags' and 'git log --oneline --decor --parents' for each of the
two repos.

The one irritating thing is that in two of them the inital commit is
not the bottommost in the log output.

To make my expectation more concrete: I would expect 'git describe'
to output the tag where the number of commits that are in HEAD but not
in the tag is the lowest, and that would (always) be the bl-1 here.


=== /tmp/tmp-ws-20150116-11061-169bt1w

searching to describe HEAD
 lightweight        3 r2.4/bl-1
 lightweight        4 r2.4/bl-0
traversed 5 commits
r2.4/bl-1-3-gd760b4b

d760b4b 6e15dfc d905814 (HEAD, origin/r2.4/feature-2, r2.4/feature-2) Merge branch 'r2.4/master' into r2.4/feature-2
6e15dfc ad4e371 feature: 1st part
d905814 86f7fcf (origin/r2.4/master, origin/HEAD, r2.4/master) main: 3rd commit
86f7fcf ad4e371 (tag: r2.4/bl-1) main: 2nd commit
ad4e371 (tag: r2.4/bl-0, origin/sidestep) module: initial

=== /tmp/tmp-ws-20150116-11355-v7zfcc

searching to describe HEAD
 lightweight        4 r2.4/bl-0
 lightweight        4 r2.4/bl-1
traversed 5 commits
r2.4/bl-0-4-g689e350

689e350 93d9eb5 d768596 (HEAD, origin/r2.4/feature-2, r2.4/feature-2) Merge branch 'r2.4/master' into r2.4/feature-2
93d9eb5 e17d86b feature: 1st part
d768596 6e35c9c (origin/r2.4/master, origin/HEAD, r2.4/master) main: 3rd commit
e17d86b (tag: r2.4/bl-0, origin/sidestep) module: initial
6e35c9c e17d86b (tag: r2.4/bl-1) main: 2nd commit

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Regarding the determinacy of 'git describe'

[Andreas Krey]

On Fri, 16 Jan 2015 14:29:17 +0000, Andreas Krey wrote:
...
> === /tmp/tmp-ws-20150116-11355-v7zfcc
> 
> searching to describe HEAD
>  lightweight        4 r2.4/bl-0
>  lightweight        4 r2.4/bl-1
> traversed 5 commits
> r2.4/bl-0-4-g689e350

Apparently, this comes because two of the commit have the same timestamp,
affecting the log ordering (and presumably the order in which they
are used by 'git describe' as well). Also explains why it happens with
different probability on different machines.

But should 'git describe' behave this way?

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800