Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
