Re: interactive rebase not rebasing

[Stephen Haberman <stephen@exigencecorp.com>]

> >> 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