Re: git rebase --interactive commits order

On Wed, May 11, 2011 at 1:24 PM, Junio C Hamano [off-list ref] wrote:

Richard Peterson [off-list ref] writes:

quoted

On Tue, May 10, 2011 at 7:26 PM, Junio C Hamano [off-list ref] wrote:

quoted

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