threads / discuss / 65075

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

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

## tl;dr

9 messages between Feb 25, 2026 and Mar 1, 2026.

replies: 8people: 3as markdown or json

Alejandro Colomar· Feb 25, 2026, 17:55 UTC · lore
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>
Junio C Hamano· Feb 25, 2026, 18:29 UTC · re: Alejandro Colomar · lore

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

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?
Alejandro Colomar· Feb 25, 2026, 18:36 UTC · re: Junio C Hamano · lore

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

Hi Junio,
On 2026-02-25T10:29:12-0800, Junio C Hamano wrote:
Show 7 quoted lines
> 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.
Show 8 quoted 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

-- 
<https://www.alejandro-colomar.es>
Junio C Hamano· Feb 25, 2026, 18:56 UTC · re: Alejandro Colomar · lore

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

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.
Marc Branchaud· Feb 25, 2026, 19:46 UTC · re: Alejandro Colomar · lore

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

On 2026-02-25 11:36, Alejandro Colomar wrote:
Show 27 quoted lines
> 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.

Junio C Hamano· Feb 25, 2026, 20:08 UTC · re: Marc Branchaud · lore

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

Marc Branchaud <marcnarc@xiplink.com> writes:
Show 5 quoted lines
> 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.

Marc Branchaud· Feb 25, 2026, 21:46 UTC · re: Junio C Hamano · lore

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

On 2026-02-25 13:08, Junio C Hamano wrote:
Show 17 quoted lines
> 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.

Show 9 quoted lines
> 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.
Alejandro Colomar· Feb 25, 2026, 21:54 UTC · re: Marc Branchaud · lore

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

Hi Junio, Marc,
On 2026-02-25T14:46:10-0700, Marc Branchaud wrote:
Show 60 quoted lines
> 
> 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>
Junio C Hamano· Mar 1, 2026, 05:59 UTC · re: Marc Branchaud · lore

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

Marc Branchaud <marcnarc@xiplink.com> writes:
Show 7 quoted lines
> 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.

← back to recent threads