Hi, 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. And of course, if you want to play games with rebase -i, you can _always_ use the "edit" command (even if you do not plan to edit) to get the commit name of the new commit. And you can _always_ use the _full_ commit name to reference the original commit (at least that is how I planned it: the original _short_ name would be replaced by the rewritten commit name, but not the _long_ name). Ciao, Dscho -- 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
