{"thread":{"id":"65075","subject":"--no-decorate and %d in git-log(1)","startedAt":"2026-02-25T17:55:29Z","lastAt":"2026-03-01T05:59:12Z","messageCount":9,"participants":["Alejandro Colomar","Junio C Hamano","Marc Branchaud"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"537109","messageId":"aZ81X6ERyx5fcm6L@devuan","threadId":"65075","inReplyTo":null,"subject":"--no-decorate and %d in git-log(1)","fromName":"Alejandro Colomar","fromEmail":"alx@kernel.org","sentAt":"2026-02-25T17:55:26Z","receivedAt":"2026-02-25T17:55:29Z","isPatch":false,"sender":{"key":"alx@kernel.org","avatar":null},"body":"Hi!\n\nI use a custom alias that is very similar to\n\tgit log --oneline\n\nThe reason is that the command above doesn't show the signatures on\ncommits, and if I were to show it (--show-signature) that would take too\nmuch space (I really want --oneline).  So I use the following format:\n\t--format=tformat:'%C(magenta)%G?%C(reset) %C(auto)%h%d%C(reset) %C(auto)%s%C(reset)'\n\nwhich imitates --oneline, except for the %G? at the beginning of the\nformat.\n\nA problem with it is that '%d' is unconditional.  I'd like to be able to\nuse --no-decorate to turn it off.  This would be consistent with %h\nbeing affected by core.abbrev, and %cd and %ad being affected by\nlog.date.\n\nWould you mind changing %d to be affected by --decorate=?\n\n\nHave a lovely day!\nAlex\n\n-- \n<https://www.alejandro-colomar.es>\n"},{"id":"537110","messageId":"xmqq4in4brt3.fsf@gitster.g","threadId":"65075","inReplyTo":"aZ81X6ERyx5fcm6L@devuan","subject":"Re: --no-decorate and %d in git-log(1)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-02-25T18:29:12Z","receivedAt":"2026-02-25T18:29:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alejandro Colomar <alx@kernel.org> writes:\n\n> Would you mind changing %d to be affected by --decorate=?\n\nI would imagine everybody would strongly mind as the scripts they\nhave already written and have been using for years will be broken by\nsuch a change.  So changing how %d works is a non-starter.\n\nBut that does not mean we cannot add a different placeholder that\nbehaves that way.  I wonder if it is the cleanest to extend the\n%(decoreate:<option>,...) notation, perhaps like\n\n    $ git log --format=\"%(decorate:optional=yes)\"\n\nwith and without --decorate/--no-decorate may be a way forward?\n\n"},{"id":"537111","messageId":"aZ9AuD3dYzCKtI0s@devuan","threadId":"65075","inReplyTo":"xmqq4in4brt3.fsf@gitster.g","subject":"Re: --no-decorate and %d in git-log(1)","fromName":"Alejandro Colomar","fromEmail":"alx@kernel.org","sentAt":"2026-02-25T18:36:24Z","receivedAt":"2026-02-25T18:36:27Z","isPatch":false,"sender":{"key":"alx@kernel.org","avatar":null},"body":"Hi Junio,\n\nOn 2026-02-25T10:29:12-0800, Junio C Hamano wrote:\n> Alejandro Colomar <alx@kernel.org> writes:\n> \n> > Would you mind changing %d to be affected by --decorate=?\n> \n> I would imagine everybody would strongly mind as the scripts they\n> have already written and have been using for years will be broken by\n> such a change.  So changing how %d works is a non-starter.\n\nMakes sense.\n\n> \n> But that does not mean we cannot add a different placeholder that\n> behaves that way.  I wonder if it is the cleanest to extend the\n> %(decoreate:<option>,...) notation, perhaps like\n> \n>     $ git log --format=\"%(decorate:optional=yes)\"\n> \n> with and without --decorate/--no-decorate may be a way forward?\n\nThat could work for me.\n\nAlternatively, we could add another level to --decorate=.  Currently,\nthere are --decorate[=(short|full|auto|no)].  We could add 'never' to\nalso exclude %d.\n\nWhat do you think?\n\n\nCheers,\nAlex\n\n-- \n<https://www.alejandro-colomar.es>\n"},{"id":"537125","messageId":"xmqqqzq8abyl.fsf@gitster.g","threadId":"65075","inReplyTo":"aZ9AuD3dYzCKtI0s@devuan","subject":"Re: --no-decorate and %d in git-log(1)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-02-25T18:56:50Z","receivedAt":"2026-02-25T18:56:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alejandro Colomar <alx@kernel.org> writes:\n\n> Alternatively, we could add another level to --decorate=.  Currently,\n> there are --decorate[=(short|full|auto|no)].  We could add 'never' to\n> also exclude %d.\n\nI like that better, actually.  Nice.\n"},{"id":"537129","messageId":"8f6441ab-5c9a-4b42-ab2e-a670d462569d@xiplink.com","threadId":"65075","inReplyTo":"aZ9AuD3dYzCKtI0s@devuan","subject":"Re: --no-decorate and %d in git-log(1)","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2026-02-25T19:46:40Z","receivedAt":"2026-02-25T19:46:47Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"\nOn 2026-02-25 11:36, Alejandro Colomar wrote:\n> Hi Junio,\n> \n> On 2026-02-25T10:29:12-0800, Junio C Hamano wrote:\n>> Alejandro Colomar <alx@kernel.org> writes:\n>>\n>>> Would you mind changing %d to be affected by --decorate=?\n>>\n>> I would imagine everybody would strongly mind as the scripts they\n>> have already written and have been using for years will be broken by\n>> such a change.  So changing how %d works is a non-starter.\n> \n> Makes sense.\n> \n>>\n>> But that does not mean we cannot add a different placeholder that\n>> behaves that way.  I wonder if it is the cleanest to extend the\n>> %(decoreate:<option>,...) notation, perhaps like\n>>\n>>      $ git log --format=\"%(decorate:optional=yes)\"\n>>\n>> with and without --decorate/--no-decorate may be a way forward?\n> \n> That could work for me.\n> \n> Alternatively, we could add another level to --decorate=.  Currently,\n> there are --decorate[=(short|full|auto|no)].  We could add 'never' to\n> also exclude %d.\n\nHaving both \"no\" and \"never\" is a bit confusing...\n\nI disagree that having --decorate=no disable %d placeholders is an evil \nchange.  %d is, after all, \"ref names, like the --decorate option\" so \ncontrolling it with --decorate seems reasonable.\n\nIndeed, some quick experiments with \"git log --format=%h:%d\" show that, \nas documented, using --decorate=short or --decorate=long changes whether \nor not the %d refs are prefixed.  (The same holds for %D, too.)  Also, \n--decorate=no has the same effect as --decorate=short, so if you look at \nit a certain way, one could argue that it's a bug that --decorate=no \ndoesn't disable %d/%D placeholders.\n\nBTW, --decorate=auto is documented as \"if the output is going to a \nterminal, the ref names are shown as if `short` were given, otherwise no \nref names are shown.\"  But in my experiments %d still shows refs even \nwhen the output is piped to a file.  Seems like another symptom of the \nsame bug?\n\n(Do people who use `--format` (with or without %d) *also* use \n`--decorate`?  It seems like the two are naturally exclusive, even if \nthe code allows them both.)\n\nBut if people really want %d/%D to be unaffected by --decorate=no, then \ninstead of Junio's suggested %(decorate:optional=yes), maybe just make \n--decorate=no turn off all %(decorate) placeholders?  That seems natural \nto me, since the word \"decorate\" hints at a connection.\n\n\t\tM.\n\nps. \"--decorate=no\" doesn't seem to be explicitly documented like the \nother possible --decorate values.\n\n"},{"id":"537131","messageId":"xmqqcy1sa8mx.fsf@gitster.g","threadId":"65075","inReplyTo":"8f6441ab-5c9a-4b42-ab2e-a670d462569d@xiplink.com","subject":"Re: --no-decorate and %d in git-log(1)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-02-25T20:08:38Z","receivedAt":"2026-02-25T20:08:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marc Branchaud <marcnarc@xiplink.com> writes:\n\n> BTW, --decorate=auto is documented as \"if the output is going to a \n> terminal, the ref names are shown as if `short` were given, otherwise no \n> ref names are shown.\"  But in my experiments %d still shows refs even \n> when the output is piped to a file.  Seems like another symptom of the \n> same bug?\n\nIsn't that documentation merely referring to \"git log\" without\n\"--format=... %d ...\" and not about the case where you explicitly\nask for \"%d\"?  That is, the description is there to explain the\ndifferences between\n\n\tgit log --oneline --decorate=auto -1\n\tgit log --oneline --decorate=auto -1 | cat\n\nisn't it?  I think --decorate=auto is the default so the above\nwithout --decorate=auto would behave similarly.\n\n> (Do people who use `--format` (with or without %d) *also* use \n> `--decorate`?  It seems like the two are naturally exclusive, even if \n> the code allows them both.)\n\nThat is an interesting question, but I am not sure if it affects how\nwe decide to resolve this discussion.\n"},{"id":"537150","messageId":"cf3d274e-7363-4557-809a-a649b1d304ad@xiplink.com","threadId":"65075","inReplyTo":"xmqqcy1sa8mx.fsf@gitster.g","subject":"Re: --no-decorate and %d in git-log(1)","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2026-02-25T21:46:10Z","receivedAt":"2026-02-25T21:46:16Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"\nOn 2026-02-25 13:08, Junio C Hamano wrote:\n> Marc Branchaud <marcnarc@xiplink.com> writes:\n> \n>> BTW, --decorate=auto is documented as \"if the output is going to a\n>> terminal, the ref names are shown as if `short` were given, otherwise no\n>> ref names are shown.\"  But in my experiments %d still shows refs even\n>> when the output is piped to a file.  Seems like another symptom of the\n>> same bug?\n> \n> Isn't that documentation merely referring to \"git log\" without\n> \"--format=... %d ...\" and not about the case where you explicitly\n> ask for \"%d\"?  That is, the description is there to explain the\n> differences between\n> \n> \tgit log --oneline --decorate=auto -1\n> \tgit log --oneline --decorate=auto -1 | cat\n> \n> isn't it?\n\nI'm sure that's how the code works, but I don't see any indication in \nthe documentation that this is for when --format isn't used or when the \nformat doesn't contain %d.  The descriptions of --decorate and --format \nmostly just ignore each other.\n\nWe do have this at the end of the --format section:\n\n\tThe %d and %D placeholders will use the \"short\"\n\tdecoration format if --decorate was not already\n\tprovided on the command line.\n\nGiven this documented connection between %d/%D and --decorate, it seems \nreasonable for a reader to assume that --decorate=auto would do the same \nthing regardless of whether or not a --format=...%d... was present.\n\n> I think --decorate=auto is the default so the above\n> without --decorate=auto would behave similarly.\n> \n>> (Do people who use `--format` (with or without %d) *also* use\n>> `--decorate`?  It seems like the two are naturally exclusive, even if\n>> the code allows them both.)\n> \n> That is an interesting question, but I am not sure if it affects how\n> we decide to resolve this discussion.\n\nYeah, it's more philosophical, though if we did know the answer was \"the \ntwo are almost never used together\" we'd be more comfortable changing \nhow --decorate=no and --format=%d interact.\n\nI note that currently --decorate has no effect at all if the --format \ndoesn't contain %d or %D.  To me this bolsters the argument for making \n--decorate=no suppress %d/%D.\n\n\nTo expand on my earlier point: --decorate=no currently has the same \neffect on %d/%D as --decorate=short, so it seems to me that we can \nchange what --decorate=no does because if anyone needs to preserve the \nexisting behavior for their favorite --format they can just use \n--decorate=short.  (I'd be surprised if anyone is using --decorate=no to \nensure that they get the short ref names).\n\n\t\tM.\n\n"},{"id":"537155","messageId":"aZ9vBfhiaR7gO9hs@devuan","threadId":"65075","inReplyTo":"cf3d274e-7363-4557-809a-a649b1d304ad@xiplink.com","subject":"Re: --no-decorate and %d in git-log(1)","fromName":"Alejandro Colomar","fromEmail":"alx@kernel.org","sentAt":"2026-02-25T21:54:21Z","receivedAt":"2026-02-25T21:54:25Z","isPatch":false,"sender":{"key":"alx@kernel.org","avatar":null},"body":"Hi Junio, Marc,\n\nOn 2026-02-25T14:46:10-0700, Marc Branchaud wrote:\n> \n> On 2026-02-25 13:08, Junio C Hamano wrote:\n> > Marc Branchaud <marcnarc@xiplink.com> writes:\n> > \n> > > BTW, --decorate=auto is documented as \"if the output is going to a\n> > > terminal, the ref names are shown as if `short` were given, otherwise no\n> > > ref names are shown.\"  But in my experiments %d still shows refs even\n> > > when the output is piped to a file.  Seems like another symptom of the\n> > > same bug?\n> > \n> > Isn't that documentation merely referring to \"git log\" without\n> > \"--format=... %d ...\" and not about the case where you explicitly\n> > ask for \"%d\"?  That is, the description is there to explain the\n> > differences between\n> > \n> > \tgit log --oneline --decorate=auto -1\n> > \tgit log --oneline --decorate=auto -1 | cat\n> > \n> > isn't it?\n> \n> I'm sure that's how the code works, but I don't see any indication in the\n> documentation that this is for when --format isn't used or when the format\n> doesn't contain %d.  The descriptions of --decorate and --format mostly just\n> ignore each other.\n> \n> We do have this at the end of the --format section:\n> \n> \tThe %d and %D placeholders will use the \"short\"\n> \tdecoration format if --decorate was not already\n> \tprovided on the command line.\n> \n> Given this documented connection between %d/%D and --decorate, it seems\n> reasonable for a reader to assume that --decorate=auto would do the same\n> thing regardless of whether or not a --format=...%d... was present.\n> \n> > I think --decorate=auto is the default so the above\n> > without --decorate=auto would behave similarly.\n> > \n> > > (Do people who use `--format` (with or without %d) *also* use\n> > > `--decorate`?  It seems like the two are naturally exclusive, even if\n> > > the code allows them both.)\n> > \n> > That is an interesting question, but I am not sure if it affects how\n> > we decide to resolve this discussion.\n> \n> Yeah, it's more philosophical, though if we did know the answer was \"the two\n> are almost never used together\" we'd be more comfortable changing how\n> --decorate=no and --format=%d interact.\n> \n> I note that currently --decorate has no effect at all if the --format\n> doesn't contain %d or %D.  To me this bolsters the argument for making\n> --decorate=no suppress %d/%D.\n> \n> \n> To expand on my earlier point: --decorate=no currently has the same effect\n> on %d/%D as --decorate=short, so it seems to me that we can change what\n> --decorate=no does because if anyone needs to preserve the existing behavior\n> for their favorite --format they can just use --decorate=short.  (I'd be\n> surprised if anyone is using --decorate=no to ensure that they get the short\n> ref names).\n\nI agree with this.  If anyone has a script, I expect it won't use both\n--decorate=no and %d together, because it makes no sense (at least with\nthe current behavior).  And if there's some case where they do it for\nsome reason, they're able to change =no to =short to keep the old\nbehavior.\n\n\nCheers,\nAlex\n\n> \n> \t\tM.\n> \n\n-- \n<https://www.alejandro-colomar.es>\n"},{"id":"537427","messageId":"xmqqwlzw5bv6.fsf@gitster.g","threadId":"65075","inReplyTo":"cf3d274e-7363-4557-809a-a649b1d304ad@xiplink.com","subject":"Re: --no-decorate and %d in git-log(1)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-03-01T05:59:09Z","receivedAt":"2026-03-01T05:59:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marc Branchaud <marcnarc@xiplink.com> writes:\n\n> Given this documented connection between %d/%D and --decorate, it seems \n> reasonable for a reader to assume that --decorate=auto would do the same \n> thing regardless of whether or not a --format=...%d... was present.\n> ...\n> I note that currently --decorate has no effect at all if the --format \n> doesn't contain %d or %D.  To me this bolsters the argument for making \n> --decorate=no suppress %d/%D.\n\nOK, that's convincing enough.  \n\nI no longer mind cooking such a change a bit longer than usual in\n'next' to see if anybody screams, and the have it graduate to a\nreleased version to further see what happens.\n\nThanks.\n"}]}