On Sat, Jan 5, 2019 at 2:47 PM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > This is a ridiculous patch. And I understand entirely if nobody else > cares, because I don't think anybody else has ever even noticed. > > It turns out that I still use "git rev-list" outside of some hard-core > scripting for one silly reason: the linux-next statistics are all > about non-merge commits, and so to do a rough comparison with > linux-next, I do > > git rev-list --count --no-merges v4.20.. > > to get an approximate idea of how much I've merged compared to what is > in linux-next. > > (See also > > http://neuling.org/linux-next-size.html > > for the graphical view of it all, even though it looks a bit odd right > now because of how linux-next wasn't being updated over the holidats > and right at the 4.19 release). > > Anyway, I've occasionally thought to myself that I should just fix > "git log" to learn that too, so that I wouldn't have to type out "git > rev-list". Because "git log" does actually take the "--count" > argument, it just doesn't honor it. > > This is that patch. Sounds reasonable to me to have such functionality, as I tend to use git log --oneline origin/master..origin/next --no-merges |wc -l for such queries, which I always assume to be doing useless work as I'd be interested in *only* the count, and not the intermediate oneline output, but that is the best output that wc works on. So maybe the --count option would want to suppress other output if given (or we'd want to have another option for no output)? Instead of printing, do we want to redirect to rev->diffopt.file, or send it through the diff codes buffer if we ever anticipate needing this output in buffered? A test would be nice, too. Stefan
