--no-decorate and %d in git-log(1)

--no-decorate and %d in git-log(1)

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 813 bytes --]

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

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: --no-decorate and %d in git-log(1)

[Junio C Hamano]

Alejandro Colomar <alx@kernel.org> writes:

> 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?

Re: --no-decorate and %d in git-log(1)

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 996 bytes --]

Hi Junio,

On 2026-02-25T10:29:12-0800, Junio C Hamano wrote:
> Alejandro Colomar <alx@kernel.org> writes:
> 
> > 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.

> 
> 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

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: --no-decorate and %d in git-log(1)

[Junio C Hamano]

Alejandro Colomar <alx@kernel.org> writes:

> 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.

Re: --no-decorate and %d in git-log(1)

[Marc Branchaud]

On 2026-02-25 11:36, Alejandro Colomar wrote:
> Hi Junio,
> 
> On 2026-02-25T10:29:12-0800, Junio C Hamano wrote:
>> Alejandro Colomar <alx@kernel.org> writes:
>>
>>> 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.
> 
>>
>> 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.

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.

Re: --no-decorate and %d in git-log(1)

[Junio C Hamano]

Marc Branchaud <marcnarc@xiplink.com> writes:

> 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?

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.

> (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.

Re: --no-decorate and %d in git-log(1)

[Marc Branchaud]

On 2026-02-25 13:08, Junio C Hamano wrote:
> Marc Branchaud <marcnarc@xiplink.com> writes:
> 
>> 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?
> 
> 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'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.

> I think --decorate=auto is the default so the above
> without --decorate=auto would behave similarly.
> 
>> (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.

Re: --no-decorate and %d in git-log(1)

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 3146 bytes --]

Hi Junio, Marc,

On 2026-02-25T14:46:10-0700, Marc Branchaud wrote:
> 
> On 2026-02-25 13:08, Junio C Hamano wrote:
> > Marc Branchaud <marcnarc@xiplink.com> writes:
> > 
> > > 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?
> > 
> > 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'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.
> 
> > I think --decorate=auto is the default so the above
> > without --decorate=auto would behave similarly.
> > 
> > > (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).

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

> 
> 		M.
> 

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: --no-decorate and %d in git-log(1)

[Junio C Hamano]

Marc Branchaud <marcnarc@xiplink.com> writes:

> 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.