Crash if there's a tag on the root commit

[ewjoachim]

Description

Dunamai crashes if there's a tag on the root git commit

It seems there's a bug in git that prevents it from listing a tag in git log --simplify-by-decoration if that tag happens to be of the first commit, but the tag still appears in git tags --list. Consequently, commit_offset fails with a runtime error because the tag cannot be found.

I'll let you be the judge of whether you want to fix or wait for a proper upstream fix

Workaround

The workaround for me will be to delete my root tag. It wasn't 100% useful anyway, but I didn't expect I'd have to delete it.

Additional info

I spent 20 minutes failing to determine whether this was fixed in recent git version, or at least a known bug in git, let alone reporting it. This is an open source investement I'm not ready to make :D

Reference

$ poetry export --dev --without-hashes |grep dunamai
dunamai==1.5.4; python_version >= "3.5" and python_version < "4.0"

$ poetry run dunamai from git
Unable to determine commit offset for ref refs/tags/0.0.0 in data: {'refs/tags/1.0.3': 0, 'refs/tags/1.0.2': 1, 'refs/tags/1.0.1': 2, 'refs/tags/1.0.0': 3}

$ git tag -l
0.0.0
1.0.0
1.0.1
1.0.2
1.0.3

$ git log --simplify-by-decoration --topo-order --decorate=full HEAD "--format=%H%d"
7374a4b0e06f708a33690e358cd3750a0f5e3c02 (HEAD -> refs/heads/main, tag: refs/tags/1.0.3)
771eec2673f85cef430fb48eefccfc3653866f65 (refs/heads/fix-draft)
b4e39239ff5958fb1a83eacf2f39058cb83fb349 (refs/heads/github-actions)
b6fd6bafeb10e1d2a1a1a88a780f42f3dc4f6ab0 (tag: refs/tags/1.0.2)
8b7fa1df8b8c0cd7c7dc1d5652c5aa2922b4f3f1 (refs/heads/draft-releases)
07f5f7b0cb4d58b2aca7a7798853a10c0f0f6b0a (tag: refs/tags/1.0.1)
cc1930a90a7b030f5c4e8a47117b14d3384adc27 (tag: refs/tags/1.0.0)

[mtkennerly]

That's an interesting find! I was able to reproduce it on Windows using both Git 2.27.0 and 2.31.1 (the latest). I can reproduce it with --allow-empty like in your screenshot on Twitter:

$ git init
Initialized empty Git repository in C:/tmp/repro/.git/

$ git commit --allow-empty -m init
[master (root-commit) bc54978] init

$ git log --simplify-by-decoration

$ git log
commit d7814029effeb7e824e480ca52e30f5a9d1e8058 (HEAD -> master)
Author: mtkennerly <[email protected]>
Date:   Fri Apr 16 19:48:06 2021 -0400

    init

However, the issue does not occur if the first commit is non-empty:

$ git init
Initialized empty Git repository in C:/tmp/repro2/.git/

$ echo hi > foo.txt
$ git add .
$ git commit -m init
[master (root-commit) 35b6427] init
 1 file changed, 1 insertion(+)
 create mode 100644 foo.txt

$ git log --simplify-by-decoration
commit 35b6427461fe48c0e918dfea2bc5ddab9dc8844d (HEAD -> master)
Author: mtkennerly <[email protected]>
Date:   Fri Apr 16 19:51:06 2021 -0400

    init

$ git log
commit 35b6427461fe48c0e918dfea2bc5ddab9dc8844d (HEAD -> master)
Author: mtkennerly <[email protected]>
Date:   Fri Apr 16 19:51:06 2021 -0400

    init

I've reported this on the Git mailing list here: https://lore.kernel.org/git/CAKqNo6TFudrXnuPzQcOaVQrRpq_0K_fxyyMA5god-WQL7y=RcQ@mail.gmail.com/ . If you ever want to report something to them in the future, you just have to send a plain-text email to the address listed on this page: https://git.wiki.kernel.org/index.php/GitCommunity

If they confirm that it's a bug, and given the limited scope of where it can occur, I would probably just add a note to the README in the meantime.

[ewjoachim]

Thanks :)
Indeed, I had not realized that empty commit was also a requirement to hit this bug.

Thanks for posting to the git ML!

[mtkennerly]

No progress on the mailing list report yet, but I've updated the documentation, so I'll go ahead and close this for now.