From: Richard Peterson Date: Wed, 11 May 2011 18:39:34 GMT Subject: Re: git rebase --interactive commits order Message-ID: In-Reply-To: <7v39klgng7.fsf@alter.siamese.dyndns.org> On Wed, May 11, 2011 at 1:24 PM, Junio C Hamano wrote: > Richard Peterson writes: > >> On Tue, May 10, 2011 at 7:26 PM, Junio C Hamano 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