Re: interactive rebase not rebasing

From: Stephen Haberman <stephen@exigencecorp.com>
Date: Oct 1, 2008, 14:52 UTC
Message-ID: <20081001095225.d28de16a.stephen@exigencecorp.com>
In-Reply-To: <48E32BD4.1050107@op5.se>

Show 11 quoted lines

> >> I don't think you can have a single command that does all the
> >> things you want, because the possible differences in input makes it
> >> very nearly impossible to always do "the right thing".
> > 
> > Ah, you are too pessimistic. :-)
> > 
> 
> Perhaps, although I think you're being overly optimistic if you think
> rebase can do all of this intelligently while still retaining clear
> semantics. I'd start with writing a separate tool for it, probably
> based on git sequencer.

I would agree with this, except that --preserve-merges is already in the codebase and does what we want. I'm not fundamentally changing how it works (e.g. how it decides what commits to keep/rewrite/etc.), I just found and patched a bug in it.

> When that works out ok, get it to do what rebase does today and then
> incorporate the new tool as an option to rebase and get ready to
> answer complex questions for the cases where it doesn't do what the
> user wanted it to do.

Yeah, I'm sorry, I did not mean my "pessimistic" comment that seriously. I understand `git rebase` can never do what everyone wants in all scenarios.

But given /this/ scenario (hehe), with the implementation's existing explicit usage of "--left-right --cherry-pick" to drop no-op commits, but then it's forgetting of this information later, leading to `git rebase` not performing a rebase at all, I think it is an obvious bug, and one that can be fixed without changing any of `git rebase`s existing semantics.

> Merely that you should think hard about it and then make sure it
> doesn't break anything people are already doing today with the current
> toolset.

I've attempted to do that. Now that I sent in the patch, if you could review it, I would appreciate your feedback. I do need to rework the test case because I realized including the origin/pull aspects (which is what caused us to find it) is just noise and the bug can be reproduced with just local branches.

Thanks, Stephen