All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx@kernel.org>
To: Marc Branchaud <marcnarc@xiplink.com>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: --no-decorate and %d in git-log(1)
Date: Wed, 25 Feb 2026 22:54:21 +0100	[thread overview]
Message-ID: <aZ9vBfhiaR7gO9hs@devuan> (raw)
In-Reply-To: <cf3d274e-7363-4557-809a-a649b1d304ad@xiplink.com>

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

  reply	other threads:[~2026-02-25 21:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-25 17:55 --no-decorate and %d in git-log(1) Alejandro Colomar
2026-02-25 18:29 ` Junio C Hamano
2026-02-25 18:36   ` Alejandro Colomar
2026-02-25 18:56     ` Junio C Hamano
2026-02-25 19:46     ` Marc Branchaud
2026-02-25 20:08       ` Junio C Hamano
2026-02-25 21:46         ` Marc Branchaud
2026-02-25 21:54           ` Alejandro Colomar [this message]
2026-03-01  5:59           ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aZ9vBfhiaR7gO9hs@devuan \
    --to=alx@kernel.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=marcnarc@xiplink.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.