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