Regarding the determinacy of 'git describe'

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

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

On Fri, 16 Jan 2015 14:29:17 +0000, Andreas Krey wrote: ...

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