Re: [PATCH] commit: provide option to add Fixes tags to log

[Junio C Hamano <gitster@pobox.com>]

Edwin Peer <espeer@gmail.com> 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
trackers).

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:

	--trailer=<trailer>:<arg>

while (optionally) allowing any unrecognized command line option

	--<trailer>=<arg>

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

	--trailer=fixes:foo
	--fixes=foo

(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.

Thanks.