Re: [RFC PATCH] show decorations at the end of the line

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Feb 13, 2017, 19:33 UTC
Message-ID: <CA+55aFy-vvOBu5Y4KDeteUyK-7U7yTa1HoqHo+hME1=8bq7Xhw@mail.gmail.com>
In-Reply-To: <xmqq1sv2fq6m.fsf@gitster.mtv.corp.google.com>

On Mon, Feb 13, 2017 at 12:30 AM, Junio C Hamano <gitster@pobox.com> wrote:

>
> An obvious downside is that people (against all recommendations) are
> likely to have written a loose script expecting the --oneline format
> is cast in stone.

Actually, I don't believe that is the case wrt decorations.

Why?

If you script the --oneline format and parse the output, you won't have any decorations at all unless you are crazy (you can set "log.decorations=true", but that will truly screw up any scripting).

And if you actually want decorations, and you're parsing them, you are *not* going to script it with "--oneline --decorations", because the end result is basically impossible to parse already (because it's ambiguous - think about parentheses in the commit message).

So if you actually want decorations for parsing, you'd do something like

   git log --pretty="%h '%D' %s"

which is at least parseable (because now the decoration separator is unconditional.

Yeah, I guess you could use "--decorations --color=always" and then use the color codes to parse the decorations, but that's so complicated as to be unrealistic.

And I considered adding a format string explanation, something along the lines of

 - oneline used to mean "--pretty=%h%d %s", now it means "%h %s%d" instead

but that's actually not true. The "oneline" format was much more complex than that, in that it has special rules for "-g", and it has all those colorization ones too.

           Linus