Another alternative that I like is pepper¹. It doesn't have the interactive menu interface that the OP script has, but it can produce nice results² and does support other VCSs.
As an added benefit you can just use pepper to generate the data and shift to your favourite tool for display.
> Extracting this information is not always trivial, mostly because of 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 :).
Or Junio Hamano, for that matter (although there is a greater chance :)
The more interesting question with git statistics is what they are actually useful for. Tools like this seem to be guided by which data is available and easy to extract. What is commits per hour useful for?
Sometimes these metrics are useful. For example, the top committers are interesting, because it instantly gives you a good hint who is very experienced with the codebase and its structure.
Two metrics I find useful to know where to refactor: Files with the most commits and with the most authors.
The commits per hour statistic looks to be how many commits occurred in each hour of the day: https://github.com/arzzen/git-quick-stats/blob/master/git-qu.... For CI/CD requirements you really want to measure the time difference between every commit and the previous commit. That way you can say that if your CI/CD processes take less than X amount of time, they will finish before the next commit Y% of the time.
At any reasonable size, you have to be able to run builds and tests for features in parallel. And at that point, throughput and scale throughout the day is rather important.
So I installed and use `git open`. How do these applications get to work, prefaced by `git`? Wouldn't `git quick-stats` just invoke `git` with an invalid parameter?
When you installed it, `make` changed your global .gitconfig file and added the respective Git aliases to it, so that Git would know what to do and not complain about invalid commands.
Aside from aliases in your `.gitconfig`, as far as I know, if `git-subcommand` exists in your path, `git subcommand` will call that script for you automatically.
ie if you put `git-monkey` in `$HOME/bin`, add `$HOME/bin` to your path, now `git monkey` is a valid subcommand.
17 comments
[ 4.7 ms ] story [ 52.8 ms ] threadAs an added benefit you can just use pepper to generate the data and shift to your favourite tool for display.
1. https://jgehring.github.io/pepper/ 2. https://jgehring.github.io/pepper/gallery/
Or Junio Hamano, for that matter (although there is a greater chance :)
Sometimes these metrics are useful. For example, the top committers are interesting, because it instantly gives you a good hint who is very experienced with the codebase and its structure.
Two metrics I find useful to know where to refactor: Files with the most commits and with the most authors.
At any reasonable size, you have to be able to run builds and tests for features in parallel. And at that point, throughput and scale throughout the day is rather important.
I had a script to do it and when I discovered this project I contributed this feature
This happens on this line of the project's Makefile: https://github.com/arzzen/git-quick-stats/blob/master/Makefi...
ie if you put `git-monkey` in `$HOME/bin`, add `$HOME/bin` to your path, now `git monkey` is a valid subcommand.