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: Thu, 24 Jun 2010 22:27:23 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)

Stefan Monnier <address@hidden> writes:

>>>> Can you please show how this is better than adding a single argument
>>>> to the vc-checkin method?  (For which the code already exists).
>>> It makes more of the state plainly visible to the user, editable with
>>> Emacs's usual commands, rather than hidden in variables that are much
>>> more difficult for the user to control.
>> How is it more difficult to control something that has an explicit
>> command attached to it?  (that you've stated that we need to have
>> anyway)
>
> It's more difficult because you're limited to what the command lets
> you do, whereas with plain text, you can do anything you like
> (including running the provided command).

As a general principle this sounds fine, but in this particular case
it does not hold too much water.  Your general case includes the
particular case, but it adds unneeded convulutions due to having to
deal with random editing.

Also, a lot of times specific solutions are much better than generic ones.

BTW, what you propose is the perforce model, you might want to talk to
some perforce users about how good it is to have to edit for various
commands instead of providing an imperative interface.

>>> It means the commit doesn't amend.  Same thing if you set your vars
>>> accidentally or if you call the toggle command accidentally, ...
>>> 
>>> I really don't see it as a problem.  Even if it's done accidentally,
>>> it's obvious for the user what the behavior will be, since it's written
>>> in plain text.
>
>> Why deal with any potential complications that are not needed at all?
>
> What complications are you referring to?

Having to educate the users what they can and cannot do with the
markup and the code to deal with it that has ZERO end-user value.

>>>> --amend and --signoff simply do not fit the header paradigm.  
>>>> Can we please admit that and move on?
>>> I really don't see it.
>> Are willing to implement your version and ask users if they prefer it?
>
> Don't know.  But I don't want the implementation you propose.  I want
> the information to be shallow and readily available for the user to
> manipulate as she sees fit.

It seems that this is your personal preference and it's not actually
technically justified.

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. 
How about you yield here to the person that has done the vast majority
of work in the VC area in the last few years, both in terms of new
features and in terms of bug fixing?
If users come back and ask for markup for amend and commit we can add
them later, but at this particular point this is just delaying giving
end users access to some very useful features.




reply via email to

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