On Mon, Mar 3, 2014 at 5:10 PM, Michael Haggerty <mhag...@alum.mit.edu> wrote:
> On 03/02/2014 10:09 AM, Eric Sunshine wrote:
>> On Sun, Mar 2, 2014 at 4:04 AM, Eric Sunshine <sunsh...@sunshineco.com> 
>> wrote:
>>> On Sat, Mar 1, 2014 at 9:53 PM, Nguyễn Thái Ngọc Duy <pclo...@gmail.com> 
>>> wrote:
>>>> "git rebase -e XYZ" is basically the same as
>>>> EDITOR="sed -i '1s/pick XYZ/edit XYZ/' $@" \
>>>> git rebase -i XYZ^
>>>> In English, it prepares the todo list for you to edit only commit XYZ
>>>> to save your time. The time saving is only significant when you edit a
>>>> lot of commits separately.
>>> Should this accept multiple -e arguments? Based upon the above
>>> justification, it sounds like it should, and I think that would be the
>>> intuitive expectation (at least for me).
>>> The current implementation, however, is broken with multiple -e arguments. 
>>> With:
>>>     git rebase -i -e older -e newer
>>> 'newer' is ignored entirely. However, with:
>>>     git rebase -i -e newer -e older
>>> it errors out when rewriting the todo list:
>>>     "expected to find 'edit older' line but did not"
>>> An implementation supporting multiple -e arguments would need to
>>> ensure that the todo list extends to the "oldest" rev specified by any
>>> -e argument.
>> Of course, I'm misreading and abusing the intention of -e as if it is
>> "-e <arg>".
> I think that your misreading is more consistent than the feature as
> implemented.
>     git rebase -e OLDER
> does not mean "do 'git rebase -i OLDER' and oh, by the way, also set up
> commit OLDER to be edited".  It means "do 'git rebase -i OLDER^' ..."
> (note: "OLDER^" and not "OLDER").  So it is confusing to think as "-e"
> as a modifier on an otherwise normal "git rebase -i" invocation.
> Rather, it seems to me that "-e" and "-i" should be mutually exclusive
> (and consider it an implementation detail that the former is implemented
> using the latter).
> And if that is our point of view, then is perfectly logical to allow it
> to be specified multiple times.

Logically, yes. Practically, no. If you have to put multiple -e and
some hashes in one line, wouldn't editing to-do list in your favorite
editor be faster?

> OTOH there is no reason that v1 has to
> allow multiple "-e", as long as it properly rejects that usage.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to