45

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

Improve this question
1
  • 1
    FYI: It is possible to run into this situation where you've previously tagged commit SHA(s), then rewritten history and force pushed, resulting in previous tags now falling outside of the history of the branch. Be warned, writing history and ignoring previous tagged commits can be a bad idea. Commented May 2, 2022 at 2:37

7 Answers 7

Reset to default
26

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'
Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

The git describe command has a --tags option which you can enable: "Instead of using only the annotated tags, use any tag found in refs/tags namespace. This option enables matching a lightweight (non-annotated) tag." This way you don't need to change your tags.
This did it for me.
26

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.

Improve this answer

3 Comments

Also the case with ReadTheDocs #5031
I had this exact problem inside a jenkins pipeline. Even after disabling shallow clone, the project wouldn't build anymore (due to git describe returning garbage). Deleting .git\shallow resolved my issue, thanks!
This is also an issue with Azure Pipelines after Sept 2022, where depth is defaulted to 1, meaning there's a good chance the tag you expect to reference hasn't been fetched learn.microsoft.com/en-us/azure/devops/pipelines/yaml-schema/…
14

It happens because you only fetch the tag, not the commit history of the tag. git describe uses this history, which is why it has an error.

The only workaround is to fetch repo's history containing the tag you're interested in, using git fetch <remote-name>.

Improve this answer

11 Comments

$ git fetch remote: Counting objects: 10, done. remote: Compressing objects: 100% (6/6), done. remote: Total 6 (delta 4), reused 0 (delta 0) Unpacking objects: 100% (6/6), done. From thoroughbred:flt/root facbb9f..045ec3a main -> origin/main facbb9f..045ec3a main_int -> origin/main_int $ git describe --tags --match MAIN_INT-74 fatal: No tags can describe '2eb966ad1c2a9b78be2b09e8e329f54a695a0f86'. Try --always, or create some tags.
Yes I meant git fetch remote. Can you see the tag in gitk or any other viewing mean? Are you sure that the tag is a parent of your current HEAD?
I just ran git pull and updated the workspace, and the describe command still fails. Is this really expected?
maybe you're in detached HEAD? What happens if you run describe without --match?
Yes, I can see the tag when I run git tag.
|
3

There might be 2 reasons for this.

  1. The fetch-depth: 0 is missing while using actions/checkout since it requires the history upto the previous tag commit which might miss if you are doing shallow fetch.
  2. You are running it on a non-main branch which doesn't have the changes since the last tag is created. Do a git pull and push those changes to the remote and see if it is working.
Improve this answer

1 Comment

Extra big thank you for this. #1 was the issue. I tried using just fetch-tags: true but that wasn't enough in actions/checkout. It needs the full depth in order to get the previous tag and the git diff between that and the current commit. Thanks again.
1

I actually ran into this error when I have created a git tag based on git reference.

It seems that the git reference was not "in master" and this cause some problems.

So the fix was to find the proper commit reference in master and recreate the tag.

Improve this answer

Comments

0

For me it worked after using git pull instead of git fetch.

Enhancing on the solutions already provided: My git tag already had a tag message and git fetch <remote-name> didn't help in my case as well.

Improve this answer

Comments

0

I have solved this issue with using below tag while doing git checkout. fetch-depth: '0'

Improve this answer

1 Comment

Always put the full commands as answers and keep it on a new line. Also surround your command with backticks ` character to display it as different from normal text.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.