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

Jeff King [off-list ref] writes:

quoted

The updates to the expectation look like this (already squashed).
The --source decorations in 4202 are also shown at the end, which
probably is in line with the way --show-decorations adds them at the
end of the line, but was somewhat surprising from reading only the
log message.

Hrm, that does surprise me. I'm not sure if that's desirable or not. I
do think some of the "nobody could possibly be parsing these" arguments
about decorations do not apply to --source (and also, they're harder for
humans to pick out from the end of the line as they lack punctuation and
color).

I just got bitten by a fallout.  I have

    $ git recent --help
    `git recent' is aliased to `log --oneline --branches --no-merges \
	 --source --since=3.weeks'

and often do

    $ git recent name-hash.c

primarily to see if I already queued a patch series to a topic (and
forgot about it), and/or what other recent topics in flight touch
the same thing.

I'd need that the topic name to be shown rather prominently for this
use case, i.e.

    eb2263adb1      jh/memihash-opt name-hash: remember previous dir_...
    0c04267dc8      jh/memihash-opt name-hash: specify initial size f...
    57463ce445      jh/memihash-opt name-hash: precompute hash values...
    dd3170e2cf      jh/memihash-opt name-hash: eliminate duplicate me...

but now the branch names are shown at the end, which defeats the
whole point of the alias.

If nobody gets around to fixing it, I may take a look at it when
able, but for now let me just vent^Wreport a regression first.

On Fri, Feb 17, 2017 at 9:27 PM, Junio C Hamano [off-list ref] wrote:

I just got bitten by a fallout.  I have

    $ git recent --help
    `git recent' is aliased to `log --oneline --branches --no-merges \
         --source --since=3.weeks'

but now the branch names are shown at the end, which defeats the
whole point of the alias.

Yes, your situation actually wants those decorations as primary
things, so having them at the end is indeed pointless.

So I think we should just discard that patch of mine.

                 Linus

On Sun, Feb 19, 2017 at 2:33 PM, Linus Torvalds
[off-list ref] wrote:

On Fri, Feb 17, 2017 at 9:27 PM, Junio C Hamano [off-list ref] wrote:

quoted

I just got bitten by a fallout.  I have

    $ git recent --help
    `git recent' is aliased to `log --oneline --branches --no-merges \
         --source --since=3.weeks'

but now the branch names are shown at the end, which defeats the
whole point of the alias.

Yes, your situation actually wants those decorations as primary
things, so having them at the end is indeed pointless.

So I think we should just discard that patch of mine.

                 Linus

I would think that in general putting them at the end makes more
sense, but we should have the ability to use them in format specifiers
so that users are free to customize it exactly how they want. That is,
I agree with the reasoning presented in the original patch, but think
Junio's case can be solved by strengthening the custom formats.

Thanks,
Jake

On Sun, Feb 19, 2017 at 03:03:21PM -0800, Jacob Keller wrote:

quoted

quoted

I just got bitten by a fallout.  I have

    $ git recent --help
    `git recent' is aliased to `log --oneline --branches --no-merges \
         --source --since=3.weeks'

but now the branch names are shown at the end, which defeats the
whole point of the alias.

Yes, your situation actually wants those decorations as primary
things, so having them at the end is indeed pointless.

So I think we should just discard that patch of mine.

                 Linus

I would think that in general putting them at the end makes more
sense, but we should have the ability to use them in format specifiers
so that users are free to customize it exactly how they want. That is,
I agree with the reasoning presented in the original patch, but think
Junio's case can be solved by strengthening the custom formats.

I think there are two potential patches:

  1. Add a custom-format placeholder for the --source value.
     This is an obvious improvement that doesn't hurt anyone.

  2. Switch --decorate to the end by default, but _not_ --source.

     This use case _could_ be served already by using a custom format
     with "%d". So it's really just a matter of having better-looking
     default.

     It might hurt somebody's script, but for the reasons discussed
     earlier in the thread, people are unlikely to be parsing it (it's
     more likely somebody would just complain because they think the
     decoration-first behavior is prettier).

-Peff

On Sun, Feb 19, 2017 at 4:46 PM, Jeff King [off-list ref] wrote:

I think there are two potential patches:

  1. Add a custom-format placeholder for the --source value.
     This is an obvious improvement that doesn't hurt anyone.

Right.

  2. Switch --decorate to the end by default, but _not_ --source.

.. and in fact the whole "--source" printing should not even have been
mixed up with the decorations.

So (2) is actually easy to fix: just don't mix "show_source()" with
"show_decorations()", because they are totally different things to
begin with.

That source showing should never have been in "show_decorations()" in
the first place. It just happened to be a convenient place for it.

So this attached patch is just my original patch updated to split up
"show_source()" from "show_decorations()", and show it where it used
to be.

Maybe this works for Junio's alias?

              Linus