Re: [RFC PATCH] git log: support "auto" decorations

[Jeff King <peff@peff.net>]

On Thu, May 29, 2014 at 03:31:58PM -0700, Linus Torvalds wrote:

> From: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Thu, 29 May 2014 15:19:40 -0700
> Subject: [RFC PATCH] git log: support "auto" decorations

I will spare you the usual lecture on having these lines in the message
body. ;)

> I actually like seeing decorations by default, but I do *not* think our 
> current "log.decorate" options make sense, since they will change any 
> random use of "git log" to have decorations. I much prefer the 
> "ui.color=auto" behavior that we have for coloration. This is a trivial 
> patch that tries to approximate that.

Yeah, I think this makes a lot of sense. I do use log.decorate=true, and
it is usually not a big deal. However, I think I have run into
annoyances once or twice when piping it. I'd probably use
log.decorate=auto if we had it.

> It's marked with RFC because
> 
>  (a) that "isatty(1) || pager_in_use()" test is kind of hacky, maybe we 
>      would be better off sharing something with the auto-coloration?

The magic for this is in color.c, want_color() and check_auto_color().

The color code checks "pager_use_color" when the pager is in use, but I
do not think that makes any sense here.  It also checks that $TERM is
not "dumb", but that also does not make sense here.

So I think your check is fine. It would be nice to share with the color
code, but I doubt it will end up any more readable, because of
conditionally dealing with those two differences.

>  (b) I also think it would be nice to have the equivalent for 
>      "--show-signature", but there we don't have any preexisting config 
>      file option.

Potentially yes, though there is a real performance impact for "log
--show-signature" if you actually have a lot of signatures. Even on
linux.git, a full "git log" is 15s with --show-signature, and 5s
without. Maybe that is acceptable for interactive use (and certainly it
is not a reason to make it an _option_, if somebody wants to turn it
on).

>  (c) maybe somebody would like a way to combine "auto" and "full", 
>      although personally that doesn't seem to strike me as all that useful 
>      (would you really want to see the full refname when not scripting it)

Yeah, "full/short" is really orthogonal to "true/false/auto". If we were
starting from scratch, I think putting "full/short" into
log.decorateStyle would make more sense, but it is probably not worth
changing now. I agree that "full auto" is probably not something useful,
and we can live without it.

-Peff