Crash if there's a tag on the root commit
ewjoachim opened this issue · 3 comments
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)
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.
Thanks :)
Indeed, I had not realized that empty commit was also a requirement to hit this bug.
Thanks for posting to the git ML!
No progress on the mailing list report yet, but I've updated the documentation, so I'll go ahead and close this for now.