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

From: Marc Branchaud <marcnarc@xiplink.com>
Date: Feb 25, 2026, 19:46 UTC
Message-ID: <8f6441ab-5c9a-4b42-ab2e-a670d462569d@xiplink.com>
In-Reply-To: <aZ9AuD3dYzCKtI0s@devuan>

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.