Re: [BUG?] rebase -i: edit versus unmerged changes

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Mar 22, 2013, 08:23 UTC
Message-ID: <CALkWK0kHFHtsy1Eh+jnY-JNSDUYd2xtiavhPNjaT8H3mJvYZkA@mail.gmail.com>
In-Reply-To: <7vsj3pdcm5.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:

Show 14 quoted lines

> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
>> Andrew Wong wrote:
>>> On 3/19/13, Ramkumar Ramachandra <artagnon@gmail.com> wrote:
>>>> I know that this is expected behavior, but is there an easy way to get
>>>> rid of this inconsistency?
>>>
>>> You can actually rely on "rebase" to run the appropriate command.
>>
>> Didn't Junio explicitly mention that this is undesirable earlier (from
>> the point of view of `rebase -i` design)?
>
> I am sure it is my fault but my memory fails me.  As Andrew
> mentioned, "rebase --continue" seemed to get this right.

After digging through the list, I did manage to find Junio's original message I was referring to [1]. This, along with other discussions has resulted in a sequencer with the Right (TM) design. I know I've brought this up several times before and that it has gone nowhere, but I'd really to have that final 'git continue' in Git 2.0. Can someone attempt to break up the migration path into manageable logical steps that we can start working on?

[1]: http://thread.gmane.org/gmane.comp.version-control.git/179304/focus=179383