Re: git rebase --interactive commits order

[Richard Peterson <richard@rcpeterson.com>]

On Wed, May 11, 2011 at 1:24 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Richard Peterson <richard@rcpeterson.com> writes:
>
>> On Tue, May 10, 2011 at 7:26 PM, Junio C Hamano <gitster@pobox.com> 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