On Mon, Feb 13, 2017 at 01:01:49PM -0800, Junio C Hamano wrote:
> Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:
>
> > 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).
>
> OK. So let's wait to hear from others if they like the "obviously"
> improved output. Even though I find the decorations indispensable
> in my "git log" output, I personally do not have much preference
> either way, as my screen is often wide enough ;-)
I have a slight preference for the new output (decorations at the end)
versus the original, but I could go either way.
I don't think the scripting compatibility concerns are an issue, for all
the reasons given in the thread.
There is one related option, --source, which also puts its data between
the hash and the subject in --oneline. In theory that should be treated
similarly, though:
1. It's already really ugly, as it does not even get the parentheses
and coloring.
2. It's perhaps more likely to get scripted, as it really is parseable
in the current state.
I'm not sure if a better path forward would be to just extend the idea
of "decorator" to possibly include more than just ref-tips. On the other
hand, if you really want to get fancy with formatting, we already have a
complete formatting language. Perhaps it should learn a placeholder for
the "--source" data.
Similarly, I've often wanted a "contained in this tags/branches"
annotation for each commit. It's not too expensive to compute if you
topo-sort the set of commits and just paint down as you traverse.
Anyway, I think none of that needs to block changes to --decorate
output. Just thinking out loud.
-Peff