From: Marc Branchaud <marcnarc@xiplink.com>
Date: Wed, 25 Feb 2026 19:46:40 GMT
Subject: Re: --no-decorate and %d in git-log(1)
Message-ID: <8f6441ab-5c9a-4b42-ab2e-a670d462569d@xiplink.com>
In-Reply-To: <aZ9AuD3dYzCKtI0s@devuan>


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.