mtkennerly/dunamai

Crash if there's a tag on the root commit

ewjoachim opened this issue · 3 comments

ewjoachim commented

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 commented

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 <mtkennerly@gmail.com>
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 <mtkennerly@gmail.com>
Date:   Fri Apr 16 19:51:06 2021 -0400

    init

$ git log
commit 35b6427461fe48c0e918dfea2bc5ddab9dc8844d (HEAD -> master)
Author: mtkennerly <mtkennerly@gmail.com>
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 commented

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 commented

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

  • 👍1