On Thu, 8 Mar 2007, Junio C Hamano wrote:
>
> Not so. "git shortlog" acts as a filter when no revs are given,
> unlike "git log" which defaults to HEAD. It was reading from
> its standard input.
Could we just change that?
There aren't *that* many users of "git shortlog", I bet, and I'm not sure
the "filter mode" is really worth it, especially since it ends up being
confusing once you get used to using it as just another "git log" variant.
It was a filter not really because people wanted a filter, but for
historical reasons, and because it wasn't really able to do things on its
own, and it was just an external script...
Yeah, as a filter it *can* stil lbe useful, of course, but I suspect the
usefullness is limited.
> + if (rev.pending.nr == 0) {
> + if (isatty(0))
> + fprintf(stderr, "(reading log to summarize from standard input)\n");
Sure, this probably gets some cases (and the one you tried in particular),
but if you pipe the output to a pager, I doubt it's actually all that
useful.
To simulate a "wait a long time without output" case, try this:
( echo "Important warning" >&2 ; sleep 10) | less -S
and at least for me, I don't see squat _in_case_I'm_at_the_top_ of the
window, simply because "less" will clear the screen for me.
In other words, putting warnings on stderr usually isn't all that useful
when you have something like a pager that will do tty stuff - it will
easily overwrite the warning so quickly that you'll never see it at all.
So I think your patch is an improvement, but I suspect it would be a
bigger improvement to just make "git shortlog" work as "git log". If we
want to support the filtering mode, we could just make it be a separate
command ("git shortlog-filter") instead?
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html