--no-decorate and %d in git-log(1)
Hi!
I use a custom alias that is very similar to
git log --oneline
The reason is that the command above doesn't show the signatures on commits, and if I were to show it (--show-signature) that would take too much space (I really want --oneline). So I use the following format:
--format=tformat:'%C(magenta)%G?%C(reset) %C(auto)%h%d%C(reset) %C(auto)%s%C(reset)'
which imitates --oneline, except for the %G? at the beginning of the format.
A problem with it is that '%d' is unconditional. I'd like to be able to use --no-decorate to turn it off. This would be consistent with %h being affected by core.abbrev, and %cd and %ad being affected by log.date.
Would you mind changing %d to be affected by --decorate=?
Have a lovely day!
Alex
Signature · 1 line
<https://www.alejandro-colomar.es>
Quoted 1 line · Alejandro Colomar
Would you mind changing %d to be affected by --decorate=?
I would imagine everybody would strongly mind as the scripts they have already written and have been using for years will be broken by such a change. So changing how %d works is a non-starter.
But that does not mean we cannot add a different placeholder that behaves that way. I wonder if it is the cleanest to extend the %(decoreate:<option>,...) notation, perhaps like
$ git log --format="%(decorate:optional=yes)"
with and without --decorate/--no-decorate may be a way forward?
Hi Junio,
Quoted 7 lines · Junio C Hamano
Quoted 1 line · Alejandro Colomar
Would you mind changing %d to be affected by --decorate=?
I would imagine everybody would strongly mind as the scripts they have already written and have been using for years will be broken by such a change. So changing how %d works is a non-starter.
Makes sense.
Quoted 8 lines
But that does not mean we cannot add a different placeholder that behaves that way. I wonder if it is the cleanest to extend the %(decoreate:<option>,...) notation, perhaps like
$ git log --format="%(decorate:optional=yes)"with and without --decorate/--no-decorate may be a way forward?
That could work for me.
Alternatively, we could add another level to --decorate=. Currently, there are --decorate[=(short|full|auto|no)]. We could add 'never' to also exclude %d.
What do you think?
Cheers,
Alex
Signature · 1 line
<https://www.alejandro-colomar.es>
Quoted 3 lines · Alejandro Colomar
Alternatively, we could add another level to --decorate=. Currently, there are --decorate[=(short|full|auto|no)]. We could add 'never' to also exclude %d.
I like that better, actually. Nice.
Quoted 20 lines · Alejandro Colomar
Hi Junio,
Quoted 7 lines · Junio C Hamano
Quoted 1 line · Alejandro Colomar
Would you mind changing %d to be affected by --decorate=?
I would imagine everybody would strongly mind as the scripts they have already written and have been using for years will be broken by such a change. So changing how %d works is a non-starter.
Makes sense.
Quoted 7 lines
But that does not mean we cannot add a different placeholder that behaves that way. I wonder if it is the cleanest to extend the %(decoreate:<option>,...) notation, perhaps like
$ git log --format="%(decorate:optional=yes)"
Quoted 7 lines
Quoted 1 line
with and without --decorate/--no-decorate may be a way forward?
That could work for me.
Alternatively, we could add another level to --decorate=. Currently, there are --decorate[=(short|full|auto|no)]. We could add 'never' to also exclude %d.
Having both "no" and "never" is a bit confusing...
I disagree that having --decorate=no disable %d placeholders is an evil change. %d is, after all, "ref names, like the --decorate option" so controlling it with --decorate seems reasonable.
Indeed, some quick experiments with "git log --format=%h:%d" show that, as documented, using --decorate=short or --decorate=long changes whether or not the %d refs are prefixed. (The same holds for %D, too.) Also, --decorate=no has the same effect as --decorate=short, so if you look at it a certain way, one could argue that it's a bug that --decorate=no doesn't disable %d/%D placeholders.
BTW, --decorate=auto is documented as "if the output is going to a terminal, the ref names are shown as if short were given, otherwise no ref names are shown." But in my experiments %d still shows refs even when the output is piped to a file. Seems like another symptom of the same bug?
(Do people who use --format (with or without %d) *also* use --decorate? It seems like the two are naturally exclusive, even if the code allows them both.)
But if people really want %d/%D to be unaffected by --decorate=no, then instead of Junio's suggested %(decorate:optional=yes), maybe just make --decorate=no turn off all %(decorate) placeholders? That seems natural to me, since the word "decorate" hints at a connection.
M.
ps. "--decorate=no" doesn't seem to be explicitly documented like the other possible --decorate values.
Quoted 5 lines · Marc Branchaud
BTW, --decorate=auto is documented as "if the output is going to a terminal, the ref names are shown as if
shortwere given, otherwise no ref names are shown." But in my experiments %d still shows refs even when the output is piped to a file. Seems like another symptom of the same bug?
Isn't that documentation merely referring to "git log" without "--format=... %d ..." and not about the case where you explicitly ask for "%d"? That is, the description is there to explain the differences between
git log --oneline --decorate=auto -1 git log --oneline --decorate=auto -1 | cat
isn't it? I think --decorate=auto is the default so the above without --decorate=auto would behave similarly.
Quoted 3 lines
(Do people who use
--format(with or without %d) *also* use--decorate? It seems like the two are naturally exclusive, even if the code allows them both.)
That is an interesting question, but I am not sure if it affects how we decide to resolve this discussion.
Quoted 13 lines · Junio C Hamano
Quoted 5 lines · Marc Branchaud
BTW, --decorate=auto is documented as "if the output is going to a terminal, the ref names are shown as if
shortwere given, otherwise no ref names are shown." But in my experiments %d still shows refs even when the output is piped to a file. Seems like another symptom of the same bug?Isn't that documentation merely referring to "git log" without "--format=... %d ..." and not about the case where you explicitly ask for "%d"? That is, the description is there to explain the differences between
Quoted 4 lines
git log --oneline --decorate=auto -1 git log --oneline --decorate=auto -1 | catisn't it?
I'm sure that's how the code works, but I don't see any indication in the documentation that this is for when --format isn't used or when the format doesn't contain %d. The descriptions of --decorate and --format mostly just ignore each other.
We do have this at the end of the --format section:
The %d and %D placeholders will use the "short" decoration format if --decorate was not already provided on the command line.
Given this documented connection between %d/%D and --decorate, it seems reasonable for a reader to assume that --decorate=auto would do the same thing regardless of whether or not a --format=...%d... was present.
Quoted 9 lines
I think --decorate=auto is the default so the above without --decorate=auto would behave similarly.
Quoted 3 lines
(Do people who use
--format(with or without %d) *also* use--decorate? It seems like the two are naturally exclusive, even if the code allows them both.)That is an interesting question, but I am not sure if it affects how we decide to resolve this discussion.
Yeah, it's more philosophical, though if we did know the answer was "the two are almost never used together" we'd be more comfortable changing how --decorate=no and --format=%d interact.
I note that currently --decorate has no effect at all if the --format doesn't contain %d or %D. To me this bolsters the argument for making --decorate=no suppress %d/%D.
To expand on my earlier point: --decorate=no currently has the same effect on %d/%D as --decorate=short, so it seems to me that we can change what --decorate=no does because if anyone needs to preserve the existing behavior for their favorite --format they can just use --decorate=short. (I'd be surprised if anyone is using --decorate=no to ensure that they get the short ref names).
M.
Hi Junio, Marc,
Quoted 54 lines · Marc Branchaud
Quoted 13 lines · Junio C Hamano
Quoted 5 lines · Marc Branchaud
BTW, --decorate=auto is documented as "if the output is going to a terminal, the ref names are shown as if
shortwere given, otherwise no ref names are shown." But in my experiments %d still shows refs even when the output is piped to a file. Seems like another symptom of the same bug?Isn't that documentation merely referring to "git log" without "--format=... %d ..." and not about the case where you explicitly ask for "%d"? That is, the description is there to explain the differences between
Quoted 4 lines
git log --oneline --decorate=auto -1 git log --oneline --decorate=auto -1 | catisn't it?
I'm sure that's how the code works, but I don't see any indication in the documentation that this is for when --format isn't used or when the format doesn't contain %d. The descriptions of --decorate and --format mostly just ignore each other.
We do have this at the end of the --format section:
The %d and %D placeholders will use the "short" decoration format if --decorate was not already provided on the command line.
Given this documented connection between %d/%D and --decorate, it seems reasonable for a reader to assume that --decorate=auto would do the same thing regardless of whether or not a --format=...%d... was present.
Quoted 9 lines
I think --decorate=auto is the default so the above without --decorate=auto would behave similarly.
Quoted 3 lines
(Do people who use
--format(with or without %d) *also* use--decorate? It seems like the two are naturally exclusive, even if the code allows them both.)That is an interesting question, but I am not sure if it affects how we decide to resolve this discussion.
Yeah, it's more philosophical, though if we did know the answer was "the two are almost never used together" we'd be more comfortable changing how --decorate=no and --format=%d interact.
I note that currently --decorate has no effect at all if the --format doesn't contain %d or %D. To me this bolsters the argument for making --decorate=no suppress %d/%D.
Quoted 6 lines
To expand on my earlier point: --decorate=no currently has the same effect on %d/%D as --decorate=short, so it seems to me that we can change what --decorate=no does because if anyone needs to preserve the existing behavior for their favorite --format they can just use --decorate=short. (I'd be surprised if anyone is using --decorate=no to ensure that they get the short ref names).
I agree with this. If anyone has a script, I expect it won't use both --decorate=no and %d together, because it makes no sense (at least with the current behavior). And if there's some case where they do it for some reason, they're able to change =no to =short to keep the old behavior.
Cheers,
Alex
Quoted 3 lines
M.
Signature · 1 line
<https://www.alejandro-colomar.es>
Quoted 7 lines · Marc Branchaud
Given this documented connection between %d/%D and --decorate, it seems reasonable for a reader to assume that --decorate=auto would do the same thing regardless of whether or not a --format=...%d... was present.
...
I note that currently --decorate has no effect at all if the --format doesn't contain %d or %D. To me this bolsters the argument for making --decorate=no suppress %d/%D.
OK, that's convincing enough.
I no longer mind cooking such a change a bit longer than usual in 'next' to see if anybody screams, and the have it graduate to a released version to further see what happens.
Thanks.