Re: support for git commit --amend/--signoff

[Dan Nicolaescu <dann@gnu.org>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Oh, that's why you tend to treat it like --amend.  I see it's a problem,
>>> indeed, but I don't think that storing it into a buffer-local variable
>>> is a good answer.  I'd rather have a "Sign-Off: yes" (you can still
>
>> But that means that 
>> Sign-off: no | off
>> will still add --signoff.
>
> Not at all.  The code gets to decide which values mean "add a --signoff
> argument".  I'd start with only accepting "yes".
>
>> Which is confusing and wrong.
>
> It would be indeed, but that's not what I'm suggesting we do.
>
>> More
>> Sign-off: foo@bar.com
>> gives the impression that it will use foo@bar.com to sign off, but that's not the case.
>
> For the values other than "yes" we can highlight them with
> font-lock-warning-face and the backend can prompt the user when faced
> with such unclear values.  We should also do something similar for
> unknown values of the "Fixed:" field, BTW.

So now let's go back to the origin of this: there's a lot of code that
needs to be added just to deal with the various possibilities for just
the Signoff header, and even more for Ammend.

Can you please show how this is better than adding a single argument
to the vc-checkin method?  (For which the code already exists).

>>> Why not show it inside the buffer (e.g. in the header ;-) instead?
>> Because we want to insert the previous log when using --amend, so it's
>> better to use a command instead of a header.
>
> The question is not "a command vs a header" but "a variable vs
> a header".  In both cases we will want to provide a command (which will
> fetch the previous log, etc...).

So what happens if one deletes the Ammend: header?   Accidentally or not?

--amend and --signoff simply do not fit the header paradigm.  
Can we please admit that and move on?