emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dan Nicolaescu
Subject: Re: support for git commit --amend/--signoff
Date: Wed, 23 Jun 2010 19:23:07 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)

Stefan Monnier <address@hidden> writes:

>> Also --amend it's still a property of commit, it's not a different
>> command, why make it a different command in emacs?
>
> Yes, that's the main argument in favor of keeping it within the
> "vc-commit" command (currently misnamed vc-next-action).
>
>>>> and given the reluctance of some other VCs to change history, it does
>>>> not seem that it will be generalized.
>>> DaRCS already supports a more general form of Git's amend.  Bazaar is
>> No idea, we don't support DaRCS at all...
>
> We do want to support DaRCS, tho.
>
>>>> More, it does not solve the problem of --signoff (which might be
>>>> adopted by other VCs).
>>> What's the problem with sign-off?  It seems this one fits perfectly well
>>> inside a "Signed-Off-By:" header.
>> Signed-Off-By: as an empty header does not work.  --signoff does not
>> have any arguments.
>
> 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.  Which is confusing and wrong.
More
Sign-off: address@hidden
gives the impression that it will use address@hidden to sign off, but that's 
not the case.
--signoff does not have an argument, adding one artificially just
creates unneeded confusion.

> I was thinking of (re)using the Signed-Off-By thingy used by Linux kernel
> developers, but I'm not exactly sure of how it's intended to be used, so
> I'm not completely clear if and how it could be cleanly integrated with
> VC's need to support --signoff.

I've already presented a solution that works, and it does not create
any confusion.

>>> Why add a var "log-edit-get-extra-flags-function" that's never used by
>>> log-edit?
>> It's used by vc-checkin, the main user of log-edit and by the modes
>> derived from log-edit.  Do you have a better proposal?
>
> Yes: use a name that starts with "vc-" since it's a variable added for
> VC, and used exclusively by VC.

OK.

>>> Also as a user I'd *really* like to have a clear visual feedback about
>>> the fact that I'm amending something, which is another reason why having
>>> it inside the headers is an attractive direction.
>> For that in my local tree I have a minor mode instead of
>> vc-git-log-edit-toggle-amend, it shows "amend" in the modeline.
>
> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]