Git shortlog returns empty output when run in non-interactive environments like scripts, CI systems, or when no revision is specified. This occurs because shortlog expects either a terminal or explicit revision argument.
The "git shortlog no output" error occurs when git shortlog is invoked without proper context or arguments. Git shortlog is designed to summarize git log output, grouping commits by author. However, it has specific behavior that causes it to produce no output in certain scenarios. According to the official Git documentation, "if no revisions are passed on the command line and either standard input is not a terminal or there is no current branch, git shortlog will output a summary of the log read from standard input, without reference to the current repository." This means when you run git shortlog in automated environments (cron jobs, CI pipelines, pre-commit hooks) or non-interactive shells, it waits for input from stdin rather than defaulting to the repository's history. This is not technically an error in most cases, but rather unexpected behavior that results from how git shortlog determines its data source. When run interactively in a terminal with a current branch, it defaults to HEAD, but this automatic behavior doesn't apply in non-interactive contexts.
First, confirm that your repository has commits and that git log works properly:
git log --onelineIf this shows commits, the repository is fine and the issue is with how shortlog is being invoked. If this also shows nothing, you may have a different issue (empty repository, detached state, etc.).
The simplest fix is to explicitly tell git shortlog which revision to summarize. Use HEAD to get the entire history leading to the current commit:
git shortlog HEADFor summary format with commit counts:
git shortlog -sn HEADFor email addresses with counts:
git shortlog -sne HEADThis works in all contexts: scripts, hooks, CI systems, and interactive terminals.
If you need commits from a specific range, provide explicit start and end points:
# All commits between two tags
git shortlog v1.0..v2.0
# Commits in current branch since main
git shortlog main..HEAD
# Commits in the last 30 days
git shortlog --since="30 days ago"
# All commits reachable from a specific branch
git shortlog origin/mainThis is particularly useful in CI environments where you want release notes or specific branch statistics.
The official alternative approach is to pipe git log output to shortlog:
git log --pretty=short | git shortlogWith additional formatting options:
# Summary by author with counts
git log --pretty=short | git shortlog -sn
# Include email addresses
git log --pretty=short | git shortlog -sneThis method explicitly provides the input shortlog needs, working around the terminal detection issue.
If you have existing scripts or CI jobs failing, update them to include explicit revisions:
Before (fails in CI):
#!/bin/bash
git shortlog -snAfter (works everywhere):
#!/bin/bash
git shortlog -sn HEADFor Jenkins, GitLab CI, GitHub Actions, or similar:
# Example GitLab CI
generate_stats:
script:
- git shortlog -sne HEAD > contributors.txt
- git shortlog -sn --since="1 month ago" HEAD > monthly_stats.txtWhy this behavior exists: Git shortlog's dual-mode behavior (reading from stdin vs. repository) is designed for flexibility. It allows shortlog to be used as both a standalone summarization tool and as a filter for git log output. The terminal detection prevents it from accidentally hanging while waiting for stdin in scripts.
Pre-commit hook specifics: During pre-commit hooks, Git maintains the repository in a semi-detached state. The staging area (index) is being prepared, and there's no guarantee of a current branch context. Always use git shortlog HEAD or git log --pretty=short | git shortlog in hooks.
Bare repositories: In bare repositories (like those on Git servers), always specify revisions explicitly since there's no working tree or current branch concept.
Performance considerations: For large repositories, using revision ranges (e.g., v1.0..HEAD) is more efficient than processing the entire history. Consider using --since or --until flags for time-bounded statistics.
Alternative tools: If you need more robust contributor statistics that work consistently across environments, consider tools like git-fame, git-stats, or parsing git log --format directly with explicit formatting.
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