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

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

 



Junio C Hamano wrote:
> Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes:
>
>> Andrew Wong wrote:
>>> On 3/19/13, Ramkumar Ramachandra <artagnon@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]