Hash of a github release changes because of versioneer

Problem:

I created a github release, which makes use of versioneer to generate a version number. I downloaded the tar.gz archive and computed the hash (which is required by third-party package managers, like macports and homebrew-core). A few days later, however, I was notified that the hash of the released archive file changed.

Inspecting the original and subsequent tar.gz files, I found that the tar.gz archive did indeed change, and the cause of this change is git_refnames in the file _version.py generated by versioneer.

diff -r SHTOOLS-4.7.1 SHTOOLS2-4.7.1
diff -r SHTOOLS-4.7.1/pyshtools/_version.py SHTOOLS2-4.7.1/pyshtools/_version.py
26c26
<     git_refnames = " (HEAD -> master, tag: v4.7.1)"
---
>     git_refnames = " (HEAD -> master, tag: v4.7.1, develop)"

The only thing that makes sense is that Github recreated the project tar.gz file a few days later, and that for some reason, the git tag was modified somehow. Though I don’t know why github would recreate this file, I also question whether git_refnames is required by versioneer. and _version.py.

Additional context: The release of our project, along with the release tag “v4.7.1” was created using the Github release page. I then pulled the tags to my local repository using git pull --tags. We work on a parallel develop branch, and have since pushed new commits to the develop branch on Github.

Examples of other people having the same problem:

• https://github.com/jborg/attic/issues/335
• https://github.com/spack/spack/issues/7937
• https://trac.macports.org/ticket/41657#comment:2
• https://github.com/macports/macports-ports/pull/8518

Solution I don’ know the solution, nor if there is one. I have opened an issue at GiHub support to find out why the tar.gz file was recreated after the release: This seems very dangerous to me, but perhaps there is a reason this was done.

If there is not a solution, then at a minimum, versioneer should provide a warning in the documentation as to how to avoid this problem. It is not 100% clear what I could have done differently to avoid this.

[exquo]

Side note: a convenient one-liner to get the contents of the archive’d VERSION file:

git archive main | tar -Oxf - VERSION 

[effigies]

No, unfortunately this is just how git archive works, providing all refnames for the commit.

It looks like you’re setting up a process to basically snapshot the initial archive. If you’d like to avoid the possibility of changes, you can also modify your process to never push a branch head and tag together. e.g.,

git tag -a vX.Y.Z
# Make some small change or commit with --allow-empty
git commit -m 'post-tag bump'
git push origin master

Another option is to use an uploaded sdist as your source distribution, rather than a git archive. You could fetch it from PyPI or add it to your GitHub release. Those do only have tag and commit information in them, and are not subject to the variability inherent to git archive.