git describe fails with "fatal: No names found, cannot describe anything."

Question

I'm using git 1.7.1 on Ubuntu 10.10 amd64, and I'm trying to extract the hash of my repository HEAD to use it in an automated version information that I compile into my project.

In the past, this always worked by using

git describe --tags

however, git is now throwing

fatal: No names found, cannot describe anything.

at me. What does that mean?

Answer 1

git describe needs the commit history and tags to be fetched in order to work properly. The git history can be fetched efficiently using "treeless clones". This fetches the HEAD commit fully and only the commit objects for the rest of the history.

For GitHub Actions:

  - uses: actions/checkout@v4
    with:
      fetch-depth: 0 # fetch full history
      filter: tree:0

Answer 2

Worked for me with

- name: Checkout repo
    uses: actions/checkout@v4
    with:
      fetch-depth: 0
      submodules: recursive

Answer 3

If you're using Github Actions and checkout@v3

You'll run into this issue because by default the action fetches only the last commit, and as mentioned by the other posts, if this commit is not tagged, then git describe --tags will crash (it crashes when it cannot find a tag)

There is a open PR somewhat ignored by the Github staff meant to fix this.

In the meantime, you have several options

• fetch all commits (see answer)
• hacking the aforementioned answer and taking inspiration from other answers/comments : fetch X commits (hoping you don't have more than X untagged commits between your head and the last tagged commit) with something like (X = 50)

# ...
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 50

Answer 4

Gitlab 14.7 changed the default git depth from 50 to 20 which caused our CI pipelines to fail with this error. Where this is an issue you might notice something like the following in the CI logs:

INFO:git.cmd:git describe --tags -> 128; stdout: '<OUTPUT_STREAM>'; stderr: 'fatal: No names found, cannot describe anything.'

This can be solved by:

• including GIT_DEPTH in the .gitlab-ci.yml file

  or

• changing the 'Git shallow clone' value in the Gitlab UI via Settings -> CI/CD -> General Pipelines. Change to 0 to disable shallow cloning.
  Refer to the gitlab docs for further details.

Answer 5

If you're using GitHub Actions and the actions/checkout, you should set the fetch-depth to 0:

# ...
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0

Answer 6

This issue happens after cloning a forked branch, and disappears after rebasing from the upstream.

Before rebasing:

#  git describe --tags
fatal: No names found, cannot describe anything.

After rebasing:

# git describe --tags
v0.1.xxxx

The command to rebase:

git remote add upstream xxxxx
git checkout main
git remote prune origin
git fetch -p upstream 
git rebase upstream/main

Answer 7

This command helped me: git fetch -t

It fetch the latest tags from the git repository, and is therefore enable to describe the tags.

Answer 8

This happens if you don't have any tags in your repository. If the repository does have tags, then you're in a shallow clone (this is the default in CI systems like TravisCI or GitHub Actions).

To fetch the history (including tags) from within a shallow clone, run

git fetch --prune --unshallow

For example, in the case of GitHub actions:

- uses: actions/checkout@v2
- run: git fetch --prune --unshallow

Afterwards, git describe should work again.

Answer 9

If you came here due to this error message in Travis CI, you can use the following setting to avoid shallow clones:

git:
  depth: false

I tested git fetch --tags but that did not work.

Answer 10

I had the similar issue while working on a CI job, the issue was git clone or checkout scm used did not fetch tags while cloning the repo.

Fetching without tags Fetching upstream changes from https://github.**********

You can enable fetch tags by selecting "Advanced clone behaviours" and then clicking on fetch tags ..

Answer 11

If you want the id of your HEAD then you don't need describe, you should just use rev-parse.

git rev-parse HEAD

If you want an abbreviated hash you can use --short.

git rev-parse --short HEAD

If you want a "describe" to fall back to an abbreviated hash if it can't find any suitable tags, you can use --always.

git describe --always

Answer 12

I have had this problem in a CI build environment where the CI tool was performing a shallow clone of the repository. This was frustrating, because in my development environment, the command

git describe --tags

would give me output like

2.2.12-7-g8ec9d6c9

whereas in the build environment I would get the "fatal no names found" error. If I tried using the --always tag

git describe --tags --always

then I would simply get the hash of the latest commit, but not the most recent tag prior to that commit

8ec9d6c9

Performing a git pull in the build environment wouldn't help, because once the repo has been cloned shallowly, future pulls will not update the tags.

The solution was to ensure that the initial clone of the repo in the build environment was not a shallow clone (i.e. the git clone command was not used with --depth, --shallow-since or --shallow-exclude parameters).

Answer 13

It sounds like you're expecting git-describe to include the most recent tag and number of commits since that tag. However, the fatal: No names found message means you don't have any tags in your repository. You need to have at least one tag in the commit history in order for git describe to tell you the latest tag.

Just guessing, but perhaps you tagged a commit somewhere else, but never pushed the tag upstream (maybe you pushed the commit upstream, tagged it later, and didn't repush?). Now a new clone of your upstream is giving you this error (since it doesn't have any tag). If that's the case, you could try git push --tags from the repository that has the tag you want (where git describe is doing what you expect). Then do git pull on the repository that doesn't have the tag.