git-quick-statsis a simple and efficient way to access various statistics in a git repository.
Any git repository may contain tons of information about commits, contributors, and files. Extracting this information is not always trivial, mostly because there are a gadzillion options to a gadzillion git commands – I don’t think there is a single person alive who knows them all. Probably not even Linus Torvalds himself :).
Table of Contents
- Command-line arguments
- Git log since and until
- Git log limit
- Git pathspec
- Color themes
git-quick-stats has a built-in interactive menu that can be executed as such:
For those who prefer to utilize command-line options,
git-quick-stats also has a non-interactive mode supporting both short and long options:
git quick-stats <optional-command-to-execute-directly>
Possible arguments in short and long form:
-r, --suggest-reviewers show the best people to contact to review code -T, --detailed-git-stats give a detailed list of git stats -R, --git-stats-by-branch see detailed list of git stats by branch -d, --commits-per-day displays a list of commits per day -m, --commits-by-month displays a list of commits per month -w, --commits-by-weekday displays a list of commits per weekday -o, --commits-by-hour displays a list of commits per hour -A, --commits-by-author-by-hour displays a list of commits per hour by author -a, --commits-per-author displays a list of commits per author -S, --my-daily-stats see your current daily stats -C, --contributors see a list of everyone who contributed to the repo -b, --branch-tree show an ASCII graph of the git repo branch history -D, --branches-by-date show branches by date -c, --changelogs see changelogs -L, --changelogs-by-author see changelogs by author -j, --json-output save git log as a JSON formatted file to a specified area -h, -?, --help display this help text in the terminal
Git log since and until
You can set the variables
_GIT_UNTIL before running
git-quick-stats to limit the git log. These work similar to git's built-in
--until log options.
export _GIT_SINCE="2017-01-20" export _GIT_UNTIL="2017-01-22"
Once set, run
git quick-stats as normal. Note that this affects all stats that parse the git log history until unset.
Git log limit
You can set variable
_GIT_LIMIT for limited output. It will affect the "changelogs" and "branch tree" options.
You can exclude a directory from the stats by using pathspec
You can also exclude files from the stats. Note that it works with any alphanumeric, glob, or regex that git respects.
You can change to the legacy color scheme by toggling the variable
UNIX and Linux
git clone https://github.com/arzzen/git-quick-stats.git && cd git-quick-stats sudo make install
For uninstalling, open up the cloned directory and run
sudo make uninstall
sudo make reinstall
brew install git-quick-stats
Or you can follow the UNIX and Linux instructions if you wish.
If you are installing with Cygwin, use these scripts:
If you are wishing to use this with WSL, follow the UNIX and Linux instructions.
- An OS with a Bash shell
- Tools we use: awk ; basename ; cat ; column ; echo ; git ; grep ; head ; seq ; sort ; tput ; tr ; uniq ; wc
apt install bsdmainutils
Q: I get some errors after run git-quick-stats in cygwin like
/usr/local/bin/git-quick-stats: line 2: $'\r': command not found
A: You can run the dos2unix app in cygwin as follows:
/bin/dos2unix.exe /usr/local/bin/git-quick-stats. This will convert the script from the CR-LF convention that Microsoft uses to the LF convention that UNIX, OS X, and Linux use. You should then should be able to run it as normal.
Want to contribute? Great! First, read this page.
All submissions, including submissions by project members, require review.
We use GitHub pull requests for this purpose.
Some tips for good pull requests
- Use our code
When in doubt, try to stay true to the existing code of the project.
- Write a descriptive commit message. What problem are you solving and what are the consequences? Where and what did you test? Some good tips: here and here.
- If your PR consists of multiple commits which are successive improvements / fixes to your first commit, consider squashing them into a single commit (
git rebase -i) such that your PR is a single commit on top of the current HEAD. This make reviewing the code so much easier, and our history more readable.
This documentation is written using standard markdown syntax. Please submit your changes using the same syntax.
MIT see LICENSE for the full license text.
Thank you to all our backers!
Support this project by becoming a sponsor. Your logo will show up here with a link to your website. [Become a sponsor]