> You start 'rebase' (without --reverse); it stops with conflict. Now what > should happen when you say 'rebase --reverse --continue' now? Does it > error out because you are not allowed to change your mind once you > started? I had a long answer explaining it all but Richard beat me to it, and his answer is pretty much exactly what I meant. Rebase wouldn't even change, only the order of which stuffs are displayed in the editor. > I am not saying that these small details cannot be worked out. I am saying > that you would need to spend a lot of effort to take care of the details > to avoid making it confusing to the users. And I am also saying that it > is not even worth wasting the brainpower spent discussing these in this > thread, if the only "benefit" resulting from it is to add an option that > allows some people to have an ordered list of things to do "First I do > this and then I do that" that has to be read backwards. Why spend extra > effort only to introduce something confusing? Well for us it's the current way that is confusing (and probably for a lot of other users too, especially new ones). It's what we suggest that would (imho) make it non-confusing... I'd very much like the "benefit" from this discussion to be a change of default in how rebase -i display commits, but as for some people having it reversed seems to be a strong no-go, it seems the only rational thing we can do is offer a --reverse option so the people used to the current way are happy. If even adding an option is asking for too much, then we might resort to EDITOR tricks and whatnot. You made me realise I could write a vim script that offers the fonctionality I need without even touching git, but it'd work for me only. I fail to see the problem with adding an option which would simplify the life of many people and isn't invasive for the others. Philippe -- 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