Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

quoted text
> On Tue, 29 Apr 2008, Johannes Sixt wrote:
>
>> Junio C Hamano schrieb:
>> > This is just a minor syntax issue and I am not sure why we got into 
>> > this misunderstanding, but let's try again.  Suppose you want to 
>> > recreate this history on top of a different O'.  For merges, upper 
>> > parents are earlier ones:
>> > 
>> >      A         reset O'
>> >     / \        pick  B
>> >    /   X       reset O'
>> >   /   / \      pick A
>> >  O---B   Z     merge B -- recreate X
>> >   \   \ /      reset O'
>> >    \   Y       pick C
>> >     \ /        merge B? -- recreate Y
>> >      C         reset B -- go back to recreated X
>> >                merge B? -- recreate Z
>> > 
>> > The above sequence does not work.
>> 
>> Because it is hand-crafted. I'd expect rebase to suggest a series that 
>> works as long as the user doesn't modify it. Like this:
>> 
>> 	reset O'
>> 	pick C
>> 	reset O'
>> 	pick B
>> 	merge C -- recreate Y
>> 	reset O'
>> 	pick A
>> 	merge B -- recreate X
>> 	merge Y -- recreate Z
>> 
>> Here all commit names are clearly the original in the first insn that 
>> references it, and the rewritten version in later references. No marks 
>> needed.
>> 
>> If the user modifies the insns, he better knows what he's doing, in 
>> particular, when it's necessary to rebuild such complex histories.
>
> I fully agree.  rebase -i is _not_ about the same goal as git-sequencer.  
> rebase -i is about user interaction.  sequencer is about having a common 
> plumbing for the different porcelains.

The problem is that both of you stopped reading after the part you quoted.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html