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

From: Jeff King <peff@peff.net>
Date: May 30, 2014, 01:58 UTC
Message-ID: <20140530015855.GG28683@sigill.intra.peff.net>
In-Reply-To: <alpine.LFD.2.11.1405291523520.8270@i7.linux-foundation.org>

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. ;)

Show 5 quoted lines

> 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