Mismatch between published version on crates.io and tagged version in git repo for v0.8.11

[VorpalBlade]

Using cargo-goggles I discovered that ahash has differences between the version on crates.io and the version in the repo at the tag v0.8.11:

• The tests are missing in lib.rs on crates.io
• The tests are different in operations.rs on crates.io
• In specialize.rs there are larger differences around CallHasher

In the Cargo.toml the version is wrong in the git version (v0.8.10).

The changes don't seem malicious (and I would assume this is an honest mistake with placing the tag at the wrong commit), but they are somewhat concerning given the recent xz backdoor. I would like an explanation of what is going on here.

[tkaitchuck]

The 0.8 releases are released from the 0.8-release branch. The master branch has some unreleased changes, that will be included in future releases. Those are the only differences I am aware of.

[VorpalBlade]

Hm, I checked out the tag v0.8.11 and compared that to the version from crates.io. They didn't quite match, and it seems like the tag simply points to an older commit (from before 0.8.10 was changed to 0.8.11).

[paolobarbolini]

I think using commit db36e4c4f0606b786bc617eefaffbe4ae9100762 clears the issue:

git clone https://github.com/tkaitchuck/aHash.git
cd aHash
git checkout db36e4c4f0606b786bc617eefaffbe4ae9100762 # current last commit from release-0.8 branch
cargo publish --no-verify --dry-run --package ahash
cd ..
cp aHash/target/package/ahash-0.8.11.crate our-release.tar.gz
curl -o upstream.tar.gz --fail "https://static.crates.io/crates/ahash/ahash-0.8.11.crate"
mkdir our-release
mkdir upstream
tar -xvzf our-release.tar.gz -C our-release
tar -xvzf upstream.tar.gz -C upstream
diff -r our-release upstream

[tkaitchuck]

Ok, it looks like I just tagged the last PR in the release as opposed to the PR with the version bump. That's is an issue in that if the tag is checked out it will list the wrong version in the toml. (I don't know if / when that is relevant) But it looks like the only way to fix that is a force push, which I am reluctant to do as it rewrites history.

[VorpalBlade]

Would it not be possible to just repoint the tag to a different version? Tags can be moved. You don't need to force push actual commits (which I agree would be bad). Or is the issue that the correct commit would be on a PR branch, not the actual repo history? And it was e.g. rebased or such.

https://stackoverflow.com/questions/8044583/how-can-i-move-a-tag-on-a-git-branch-to-a-different-commit comes up when searching for this (I admit I didn't know, I normally use SmartGit as a GUI for git when doing "scary" operations, as I find it is much more obvious what exactly I'm doing.)

[tkaitchuck]

@VorpalBlade Ah, thank you. I didn't realize the -d flag existed. I only saw the top response with the -f. The tag is now updated. Shall I close this?

[VorpalBlade]

@tkaitchuck just turned off my computer for the evening (writing this on my phone), so I won't be able to provide feedback on this until after work tomorrow.

[VorpalBlade]

This seems to be fixed now. Thank you very much.