Menu
I am using tags by applying them to nightly builds. Then later, I want to use the output of describe --tags --match <latest tag> to tell me how far from the nightly build my images are. This is for QA testing.
I just ran into an error in a clone that is older than the current tag. I ran git fetch --tags, so I see the tag in git tag output, but when I run git describe --tags --match <tagname>, I get fatal: No tags can describe <head sha1 version number>. I cannot do a git pull to update the workspace at this point. Why does this happen and is there a workaround? Thanks very much
499
In order to create a Git tag for the last commit of your current checked out branch, use the “git tag” command with the tag name and specify “HEAD” as the commit to create the tag from. Similarly, if you want your tag to be annotated, you can still use the “-a” and “-m” options to annotate your tag.
The `git describe` command finds the most recent tag that is reachable from a commit. If the tag is on the current commit, then only the tag is shown. Otherwise, it shows the tag name appended with the number of additional commits and the abbreviated SHA of the current commit.
If the working tree has local modification "-dirty" is appended to it. If a repository is corrupt and Git cannot determine if there is local modification, Git will error out, unless '--broken' is given, which appends the suffix "-broken" instead. --all.
Tags are ref's that point to specific points in Git history. Tagging is generally used to capture a point in history that is used for a marked version release (i.e. v1. 0.1). A tag is like a branch that doesn't change. Unlike branches, tags, after being created, have no further history of commits.
I just ran into this error with git version 2.8.3 and command git describe --abbrev=0.
The problem was that while the tag existed in the origin and my local repository was up to date, the tag did not have a commit message.
The error was resolved after I re-tagged the commit with a tag message:
git tag v1.1.1 -m 'some message' Another explanation can be that the repository was cloned with a depth=xyz setting (which Travis does by default). In that case, the history might be cut off before the most current tag.
Technically, cloning with depth=xyz creates a shallow clone with entries in .git/shallow that describe where to cut off history. When git describe then walks the history it might get to that cut-off point and stops searching for a tag. That even happens if you fetched tags manually after the initial shallow clone with git fetch --tags.
If this is the problem, you need to unshallow the repository (or create a full (enough) clone in the first place). See How to convert a Git shallow clone to a full clone? to solve the problem.
38
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
