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

[Dan Nicolaescu]

Stefan Monnier <address@hidden> writes:

>> For --amend I think we should have a different mechanism that does not
>> involve editing the text in the *VC-log* buffer, it's a more
>> destructive operation and it's not a good idea to allow the user to do
>> it by mistake by just placing an Amend: line in the buffer.
>
> You might be right, but I don't think it would be terribly bad to have it
> be editable in the buffer (after all it's also just an "--amend" away when
> committing on the command line).
>
> I'm not sure what UI you're considering to use and what users would
> want, because I've never used Git's amend feature.  But I think it
> should be considered in the light of similar functionality in other VCS,
> such as maybe "cvs admin -m" and DaRCS's "amend-record".
>
> For PCL-CVS what I offered was a way to edit a log-message (typically
> called from the log-view buffer).  But admittedly, "cvs admin -m" is
> a fairly different beast from Git's amend.

We already have a UI for that in VC: from the log buffer you can use
"e" to edit the commit log.

git commit --amend is different, it can be used to add more files to
the same commit, and it can only affect the last commit.

> If we only consider Git's and DaRCS's forms of amend, I'd say that the
> "Amend:" header might be a good approach, and that it should specify the
> revision/patch that's amended.  So for Git, you could have a command
> that inserts "Amend: <SHA-1>" and then the backend could check that the
> SHA-1 is the right one (which would avoid accidental use).

That looks like a bad UI: the user sees information that is
unnecessary, and might feel compelled to verify if the sha1 is indeed
to correct one (i.e. time wasted for no good reason).

Other VCs have commands that we might want to support in a similar manner, for 
example:
hg has --close-branch

So besides the markup in the VC-log buffer, we need another way to
pass arguments to the commit command.