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

[Dan Nicolaescu]

Miles Bader <address@hidden> writes:

> Dan Nicolaescu <address@hidden> writes:
>> Given that you don't really plan to do anything about it, and I am
>> convinced that it's the wrong solution for the problem based on my
>> personal experience both with this particular feature and from using
>> perforce. 
>
> I kinda like Stefan's method better too.
>
> It ("Stefan's method") seems much more flexible, albeit maybe a little
> more open to risk from the user fiddles where he shouldn't have.
>
> I also agree with Stefan that it's somewhat more "emacsy", as it
> leverages ordinary text in a buffer instead of hidden magic.  Like other
> such cases I think it will thus tend to appeal more to experienced users
> and maybe scare off noobs a bit; but since I am an experienced user, I'd
> prefer flexibility and transparency.  As for the noobs, I think they win
> in the long run, even if they're a bit put off in the short run, because
> the relative transparency of such a mechanism makes it easier for them
> to do more advanced things without getting tripped up by some hidden
> behind-the-scenes mechanism.
>
> A dedicated "vc-append" (or whatever) command which sets up the log
> buffer appropriately with a pre-stuffed message and appropriate
> meta-data seems a reasonable thing to me, but I really like the use of
> the log buffer itself to hold all meta-data.

Are you interested in implementing that version and asking users which
one they prefer?
My version exists, it's functional, it's probably less than 25 lines
of code (hard to count exactly, I have many other indepenedent
changes).

This discussion does not seem to go anywhere, all the arguments have
been made already.   And it's quite a trivial issue to start with...

So I'd like to request a resolution.

I have provided a working implementation and motivation why it's the
right thing to do, and why the other proposal is not a good idea.

It seems that there are 3 possible courses of action.

1. check in my code
2. reject my code and do nothing
3. someone else volunteers to provide an alternative and check that in

[To be fair, it would be nice if 3 was chosen to ask at least a few
users if the prefer 1 or 3]