I'm adding Releases to my projects on GitHub by adding tags to various commits in the Main branch.
In one of my projects I did not add the tags to the commits in chronological order. (I found obvious commits and tagged them, and then I found less obvious, older commits and tagged them.)
Now GitHub is showing v1.0.1 as current, with v0.7.0 preceding it, and v1.1.2 preceding that.
It appears to use the date on a tag's creation as the Release date instead of the commit that is being tagged. How can I edit my tags so that their dates are the same as the commit they are tagging?
We are required to delete/update branches or delete/update files etc. Similar to this, sometimes, we are required to update the tags in Git. Updating a tag will take your tag to another commit. For example, we can update the tag v1.
A tag is a git concept whereas a Release is GitHub higher level concept. As stated in the official announcement post from the GitHub blog: "Releases are first-class objects with changelogs and binary assets that present a full project history beyond Git artifacts."
WARNING: This will not preserve tag messages for annotated tags.
For each tag that needs to be changed:
In code:
# Fixing tag named '1.0.1' git checkout 1.0.1 # Go to the associated commit git tag -d 1.0.1 # Locally delete the tag git push origin :refs/tags/1.0.1 # Push this deletion up to GitHub # Create the tag, with a date derived from the current head GIT_COMMITTER_DATE="$(git show --format=%aD | head -1)" git tag -a 1.0.1 -m"v1.0.1" git push --tags # Send the fixed tags to GitHub
According to How to Tag in Git:
If you forget to tag a release or version bump, you can always tag it retroactively like so:
git checkout SHA1_OF_PAST_COMMIT git tag -m"Retroactively tagging version 1.5" v1.5
And while that's perfectly usable, it has the effect of putting your tags out of chronological order which can screw with build systems that look for the "latest" tag. But have no fear. Linus thought of everything:
# This moves you to the point in history where the commit exists git checkout SHA1_OF_PAST_COMMIT # This command gives you the datetime of the commit you're standing on git show --format=%aD | head -1 # And this temporarily sets git tag's clock back to the date you copy/pasted in from above GIT_COMMITTER_DATE="Thu Nov 11 12:21:57 2010 -0800" git tag -a 0.9.33 -m"Retroactively tagging version 0.9.33" # Combining the two... GIT_COMMITTER_DATE="$(git show --format=%aD | head -1)" git tag -a 0.9.33 -m"Retroactively tagging version 0.9.33"
However, if you have already added the tag, you cannot use the above with git tag -f existingtag
or else git will complain when you try to merge:
Rammy:docubot phrogz$ git push --tags To [email protected]:Phrogz/docubot.git ! [rejected] 1.0.1 -> 1.0.1 (already exists) error: failed to push some refs to '[email protected]:Phrogz/docubot.git' hint: Updates were rejected because the tag already exists in the remote.
Instead, you must remove the tag locally:
git tag -d 1.0.1
Push that deletion remotely:
git push origin :refs/tags/1.0.1
On GitHub, reload Releases—the release has now been marked as a "Draft"—and remove the draft.
Now, add the backdated tag based on the instructions above, and finally push the resulting tag to GitHub:
git push --tags
and then go and re-add the GitHub Release information again.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With