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.
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.
First, verify whether tags exist at all:
git tag -lIf 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.
For immediate resolution, use the --always flag which returns an abbreviated commit hash when no tags are found:
git describe --alwaysThis outputs something like "848392c" instead of failing. For more complete output:
git describe --always --tags --dirtyThis handles missing tags, includes lightweight tags, and shows if working tree is dirty.
If your repository genuinely needs tags, create an annotated tag:
git tag -a v1.0.0 -m "Initial release"For the current commit, or tag a specific commit:
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.
If tags exist remotely but not locally, fetch them:
git fetch --tagsOr fetch all remotes with tags:
git fetch --all --tagsVerify tags were fetched with git tag -l.
For GitHub Actions, ensure full history is fetched:
- uses: actions/checkout@v4
with:
fetch-depth: 0 # Fetch all history for all branches and tagsFor GitLab CI:
variables:
GIT_DEPTH: 0For general Git operations in CI:
git fetch --unshallow --tagsIf you have lightweight tags (created without -a), use the --tags flag:
git describe --tagsOr combine with --always for maximum compatibility:
git describe --always --tagsThe 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.
warning: BOM detected in file, this may cause issues
UTF-8 Byte Order Mark (BOM) detected in file
fatal: Server does not support --shallow-exclude
Server does not support --shallow-exclude
warning: filtering out blobs larger than limit
Git partial clone filtering large blobs warning
fatal: Server does not support --shallow-since
Server does not support --shallow-since in Git
kex_exchange_identification: Connection closed by remote host
Connection closed by remote host when connecting to Git server