Git-quick-stats – A simple and efficient way to access various statistics | Hacker News Reader

Git-quick-stats – A simple and efficient way to access various statistics

github.com

112 pointsarzzen18 comments

I think this is a bad interface. Showing a menu that clears the terminal rather than letting one use a specific command e.g. `git quick-stats commits` or `git quick-stats authors` is very annoying. If anything the menu should be a special option e.g. restricted to `git quick-stats menu`.

I wouldn't call it a bad interface. Although it is definitely orthogonal to the git interface. It isn't officially part of git.

Neat. I may end up using this.

fwiw as feedback:

- 1 would be far more useful to me if it suggested reviewers based on the files changed in this commit / branch / ?. probably true for most large projects.

- 7 is a thing I made myself as well (though yours is noticeably faster), and I LOVE it. glad to see it appearing elsewhere :)

- what Zikes said. non-interactive input is a must for script-ability (e.g. to add an alias to output one option).

- easily readable awk and bash... nice work. scripts like this are really handy for teaching people about sane complex bash scripting. I'll spread it around at work a bit :)

agreed re: #7, heres another project I use that just does that: https://github.com/paulirish/git-recent

I have the following aliased to gbl:

    git for-each-ref --sort=-committerdate refs/heads/

With formatting:

    git for-each-ref --sort=-committerdate refs/heads/ --format='%(HEAD) %(color:yellow)%(refname:short)%(color:reset) - %(color:red)%(objectname:short)%(color:reset) - %(contents:subject) - %(color:cyan)%(authorname)%(color:reset) (%(color:green)%(committerdate:relative)%(color:reset))'

I like what this offers, however I would prefer to be able to access each individual "report" via a direct command as opposed to a menu. It would make it much more composable.

If you look at the code they are all oneliners so you could just add aliases

Certainly, and this project could take on a structure which enables that sort of usage. A really great project with similar utility is https://github.com/tj/git-extras, which I think could provide a good model for refactoring git-quick-stats.

This could really use an asciinema showcase: https://asciinema.org/

I want this for email! As far as I can tell, there is no great open-source tool for processing my mail archive and giving me similar stats. Everyone wants me to hand over a fully-privileged OAUTH token to some random person's website, and then it never gives me the stats I want.

What format do you have your mail archive in? What analytics are you interested in? Most of the ones I've seen focus on basic social network analysis tasks.

Those tools ask for credentials because most folks have their archive on the cloud.

While on this, are there any tools floating around for summarizing a Mailman archive into some basic stats? I have a few lists that I'd love gathering some stats for. Things like most prolific writer per week, general mail count per month, first occurrence of authors, etc. I wanted to throw something together myself, but thought I might be able to find something similar online, unfortunately to no avail.

mboxstats[1] is pretty good for this if you're fetching the monthly archives from the web interface and desire a quick overview. It supports mbox and maildir, and can produce XML output for easier post-processing.

The mboxstats author has a variety of interesting tools on his site, if you're in to strange stats and log processing like me ;)

I've submitted it here[2] in the hope others pile in with other cool options.

1. http://www.vanheusden.com/mboxstats/ 2. https://news.ycombinator.com/item?id=13418463

Thanks for the link! Will definitely have a look! :)

I'd like this as a GitLab Plug-In.

Sadly the GitLab Team thinks that Plug-In Support is not necessary. :(

I'm pretty sure you could wire this up with CI to run and give you output. The only feature that you can't get out of GitLab right now would be suggested code reviewers. The rest looked like they'd be pretty visible via the UI.

disclosure: I work at GitLab, but this is opinion is my own, posted on my own time, reading HN.

Be good if you tracked sloc, like mine does :) https://github.com/kaihendry/graphsloc

I'm not sure about the HN rules on this; shouldn't the title be "Show HN: [...]" when posting something you made yourself?

Reply on news.ycombinator.com