Re: [PATCH] commit: Add -f, --fixes <commit> option to add Fixes: line

> On Sun, Oct 27, 2013 at 2:30 PM, Johan Herland <johan@herland.net> wrote:
>> On Sun, Oct 27, 2013 at 1:30 PM, Christian Couder <christian.couder@gmail.com> wrote:
>>>
>>> Your suggestion is very good, and it is not incompatible with command
>>> line options.
>>> So both could be implemented and even work together.
>>>
>>> For example if "-f ack:Peff" was passed to the command line, "git commit" could
>>> lookup in the commit message template and see if there is one
>>> RFC822-style header
>>> that starts with or contains "ack" (discarding case) and it could look
>>> in some previous commits if
>>> there is an author whose name contains "Peff" (discarding case)
>>
>> ...may be cheaper to (first) look at the .mailmap?
>
> Ok. I haven't really had a look at how it could best be done.
>
>>> and if it is the case
>>> it could append the following to the bottom of the commit message:
>>>
>>> Fixes:
>>> Reported-by:
>>> Suggested-by:
>>> Improved-by:
>>> Acked-by: Jeff King <peff@peff.net>
>>> Reviewed-by:
>>> Tested-by:
>>> Signed-off-by: Myself <myself@example.com>
>>>
>>> (I suppose that the sob is automatically added.)
>>>
>>> It would work also with "-f fix:security-bug" and would put something
>>> like what you suggested:
>>>
>>> Fixes: 1234beef56 (Commit message summmary)
>>
>> Even better: Imagine "-f" (or whatever is decided) as a general
>> mechanism for forwarding parameters to the prepare-commit-msg hook.
>> When you run "git commit -f ack:Peff -f fix:security-bug", the -f
>> arguments will be forwarded to prepare-commit-msg (as additional
>> command-line args, or on stdin), and then the prepare-commit-msg hook
>> can do whatever it wants with them (e.g. the things you describe
>> above).
>
> If "git commit" processes these arguments and puts the result in the
> commit message file that is passed to the
> prepare-commit-msg hook, then this hook can still get them from the
> file and process them however it wants.
>
> And in most cases the processing could be the same as what is done by
> the commit-msg hook when the user changes the "Fixes: xxx" and
> "Stuffed-by: yyy" lines in the editor.
>
> So it would probably be easier for people customizing the
> prepare-commit-msg and commit-msg if "git commit" processes the
> arguments instead of just passing them to the prepare-commit-msg hook.
>
> And it will be better for people who don't set up any *commit-msg hook.
> Even if there is no commit template, "-f Acked-by:Peff" and "-f
> Fixes:security-bug" could still work.
> I suspect most users don't setup any hook or commit template.

>> The reason I like this, is that we can now support project-specific
>> conventions/rules without having to encode those directly in "git
>> commit" itself. The only thing "git commit" needs to know, is how to
>> forward the appropriate information to the project-specific hook.
>
> Supporting project specific conventions/rules would still be possible
> by processing lines in the commit message file without changing "git
> commit".
>
> If "git commit" is already able to do some processing, it only adds
> power to what can be done by people writing hooks.
>
> We could even have git plumbing commands used by git commit to process
> the -f (or whatever option) arguments and they could be reused by the
> *commit-msg hooks if they find them useful.

>> One such project-specific convention/rule is the Signed-off-by line
>> (although it has certainly spread to quite a lot of projects). I am
>> not 100% comfortable with encoding this convention directly into "git
>> commit", because it serves as a "slippery slope" to encode even more
>> project-specific conventions/rules directly into "git commit" (the
>> proposals to add command-line options for the "Change-Id" and "Fixes"
>> headers are the two most recent examples), and the more we add, the
>> more we bloat the "git commit" command-line interface.
>
> I don't think we would bloat the "git commit" command line interface.
> We just add one option that could help a lot of people, even those who
> want something very special.
>
>>>>  2. No need to add any command-line options to Git.
>>>
>>> This is not a good reason. If many users prefer a command line option,
>>> why not let them use that?
>>
>> True. As explained above, what I don't want is to add another
>> command-line option _every_time_ there is a useful project-specific
>> convention. Adding _one_ option to rule them all is much more
>> acceptable to me. :)
>
> Great!
>
>>>>  3. The whole mechanism is controlled by the project. The kernel folks
>>>> can do whatever they want in their templates/hooks without needing
>>>> changes to the Git project.
>>>
>>> The Git project already manages sob lines. It would be a good thing if
>>> it could manage
>>> more of this stuff to help users in a generic way while taking care of
>>> user preferences.
>>
>> Yes, but the key word here is _generic_. It's impossible to make "git
>> commit" able to solve all problems for all projects, but we can make a
>> generic mechanism that helps projects solve their own problems more
>> easily.
>
> Yeah, but as you said in your initial message, the generic mechanism
> already exists with commit templates and *commit-msg hooks. The only
> question left is how an additional command line option can best help.
> And if this option does nearly nothing, it will not help much.