Richard Peterson <richard@xxxxxxxxxxxxxx> writes: > On Tue, May 10, 2011 at 7:26 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> >> Devils lie in the details. For example, should squash/fixup come before >> or after the squashed commit when --reverse is in effect, and why? >> >> Should "rebase --reverse --continue" work after it gets interrupted, if >> not why not? > > Yes, it should work,... Of course, if you start with --reverse, it is clear and obvious that 'continue' should continue with the reversed instruction sheet, and it probabaly should take --reverse as a no-op when given with --continue. The original question should have been written more carefully to avoid soliciting the response that addresses that uninteresting case. 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? That would make it inconsistent for the same "--reverse --continue" not to error out when the entire process was started with --reverse, but erroring it out in that case would be awkward. 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? -- 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