How to fix fatal: No names found, cannot describe anything in Git

GitBEGINNERLOWUpdated Dec 2, 2025· 157 views

This error occurs when git describe cannot find any tags in the repository history. The command requires at least one tag to generate version-like output based on the most recent tag.

Quick fix

Fixes fatal: No names found, cannot describe anything

git tag -l
  1. Check if any tags exist in your repository
  2. Use --always flag to fall back to commit hash
  3. Create your first tag
  4. Fetch tags from remote repository
git — error
git tag -l
fatal: No names found, cannot describe anything

What this error means

The git describe command generates a human-readable name for a commit based on available tags. It finds the most recent tag reachable from the current commit and creates a string like "v1.0.0-5-g1234abcd" (tag name, commits since tag, abbreviated commit hash). When Git reports "No names found, cannot describe anything," it means there are no tags in the repository that can be used as reference points. By default, git describe only considers annotated tags, though it can be configured to use lightweight tags as well. This error is particularly common in CI/CD environments where repositories are cloned with limited history (shallow clones), or in brand new repositories that haven't established a tagging strategy yet.

Typical symptoms

  • Running "git describe" fails with fatal error
  • Build scripts or version generation commands fail
  • CI/CD pipelines fail at the versioning step
  • Commands work locally but fail in automated environments
  • Error message mentions "No names found" or "No tags can describe"

Common causes

  1. Repository has no tags created yet
  2. Only lightweight tags exist but git describe expects annotated tags by default
  3. Shallow clone in CI/CD environment didn't fetch tag history
  4. Tags exist remotely but haven't been fetched to local repository
  5. Working in a detached HEAD state without reachable tags

How to fix "fatal: No names found, cannot describe anything"

1Check if any tags exist in your repository

First, verify whether tags exist at all:

bash
git tag -l

If this returns empty, you need to create tags. If it shows tags but git describe still fails, the tags may not be in your current branch's history.

2Use --always flag to fall back to commit hash

For immediate resolution, use the --always flag which returns an abbreviated commit hash when no tags are found:

bash
git describe --always

This outputs something like "848392c" instead of failing. For more complete output:

bash
git describe --always --tags --dirty

This handles missing tags, includes lightweight tags, and shows if working tree is dirty.

3Create your first tag

If your repository genuinely needs tags, create an annotated tag:

bash
git tag -a v1.0.0 -m "Initial release"

For the current commit, or tag a specific commit:

bash
git tag -a v1.0.0 <commit-hash> -m "Initial release"

Annotated tags (created with -a) are recommended as they're full Git objects with metadata.

4Fetch tags from remote repository

If tags exist remotely but not locally, fetch them:

bash
git fetch --tags

Or fetch all remotes with tags:

bash
git fetch --all --tags

Verify tags were fetched with git tag -l.

5Fix shallow clone issues in CI/CD

For GitHub Actions, ensure full history is fetched:

yaml
- uses: actions/checkout@v4
  with:
    fetch-depth: 0  # Fetch all history for all branches and tags

For GitLab CI:

yaml
variables:
  GIT_DEPTH: 0

For general Git operations in CI:

bash
git fetch --unshallow --tags
6Use --tags flag for lightweight tags

If you have lightweight tags (created without -a), use the --tags flag:

bash
git describe --tags

Or combine with --always for maximum compatibility:

bash
git describe --always --tags

Advanced notes

The git describe command has several modes controlled by flags. By default it only uses annotated tags, but --tags includes lightweight tags, and --all includes any ref in refs/ namespace (branches, remotes, etc.).

In CI/CD pipelines, the depth parameter controls how much history is fetched. Azure Pipelines defaults to depth 1 (since Sept 2022), meaning only the latest commit is fetched. Even if tags are fetched separately, git describe needs the commit history between the tag and current commit to function properly.

For version generation in build systems, a robust pattern is: git describe --always --tags --dirty --abbrev=7. This provides maximum compatibility (works with or without tags), indicates uncommitted changes, and gives enough hash digits for uniqueness in large repositories.

If you're establishing a tagging strategy for the first time, consider semantic versioning (v1.0.0, v1.0.1, etc.) with annotated tags that include release notes. Tools like semantic-release can automate this process.

Frequently asked questions

What does "fatal: No names found, cannot describe anything" mean?
The git describe command generates a human-readable name for a commit based on available tags. 0-5-g1234abcd" (tag name, commits since tag, abbreviated commit hash). When Git reports "No names found, cannot describe anything," it means there are no tags in the repository that can be used as reference points.
How do I fix "fatal: No names found, cannot describe anything"?
This error occurs when git describe cannot find any tags in the repository history. The command requires at least one tag to generate version-like output based on the most recent tag.
What causes "fatal: No names found, cannot describe anything"?
Repository has no tags created yet Only lightweight tags exist but git describe expects annotated tags by default Shallow clone in CI/CD environment didn't fetch tag history
Is the "fatal: No names found, cannot describe anything" error serious?
It is a low-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading