On Mon, Feb 13, 2017 at 12:30 AM, Junio C Hamano <gits...@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
