mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <>
To: Edwin Peer <>,
	Christian Couder <>
Cc:, "Denton Liu" <>,
	"David A . Wheeler" <>,
	"Jameson Miller" <>,
	"Derrick Stolee" <>,
	"Jonathan Tan" <>,
	"Nguyễn Thái Ngọc Duy" <>,
	"Alexandr Miloslavskiy" <>,
Subject: Re: [PATCH] commit: provide option to add Fixes tags to log
Date: Mon, 24 Aug 2020 11:19:37 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Edwin Peer's message of "Sun, 23 Aug 2020 23:11:56 -0700")

Edwin Peer <> writes:

> The Linux style Fixes tag has been adopted by many projects and represents
> best practice for referring to previous commits which introduce a bug that
> has been fixed by the present commit. Creating these tags manually can be
> error prone and doing so using git log -1 --format='Fixes: %h ("%s")' is
> cumbersome. It's time the commit command learn to perform this popular
> pattern natively.

Sorry, but not in this form.

It is not a reasonable way forward to add a new "--<trailer>" option
to each and every conceivable "Trailer:" a random person wants to
add to the command line.  The presence of "-s" (signoff) option was
an early "mistake" we made, not something we would want to mimic and
make things worse (besides, "Fixes" is not necessarily used with any
object name---projects can use an identifier used in their bug

The "interpret-trailers" (Christian CC'ed) subsystem was an attempt
to create a foundation to consistently treat these lines in the
trailer block and the hope back when it was invented was to
eventually integrate it to these subcommands that want to process
commit log messages (like "rebase", "commit", etc.), but it hasn't
happened yet.  And that may be the approach we would want to take.

For example, imagine that "git commit", "git am", etc. learns to
take a new option whose canonical form is to spell it like so:


while (optionally) allowing any unrecognized command line option


to be internally rewritten into the canonical form, as long as <trailer>
is what the interpret-trailers subsystem recognises as configured.  That
would extend the command line option for "git commit" etc. with new


(the latter is available only if there is no "--fixes" option used
by the implementation of subcommands for other purposes, but the
former is always available) without having to add any new code. 

That kind of future I'd be happy to see.  Not with individual option
with fixed semantics tailored to a single project's convention.


      reply	other threads:[~2020-08-24 18:19 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-24  6:11 [PATCH] commit: provide option to add Fixes tags to log Edwin Peer
2020-08-24 18:19 ` Junio C Hamano [this message]

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:

  List information:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).