On Wed, May 11, 2011 at 1:24 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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,... > [...] > > 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? It just continues. "--reverse" is noise here. "--reverse" would only matter in the display of the initial list. It's just as much noise here as '--interactive' would be noise here, like 'rebase --interactive --continue'. > [...] Why spend extra effort only to introduce something confusing? Because for some group of people, you are introducing something less confusing. I have a hunch that some people see the *process* as the primary artifact, and thus things make sense just as they are. Others see the *tree* as the primary artifact, and want too see the transformation that will be attempted on the tree - but interactive rebase has the tree upside down. I have absolutely no support for this theory other than that I find myself in the second group of people however small or large that group may be. I conceive of a rebase as a transformation of the tree, rather than a set of discrete steps. Tools that help me work with that abstraction are going to be easier for me and others like me. -Richard -- 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