Re: git rebase --interactive commits order

Richard Peterson [off-list ref] writes:

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,...

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?

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

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?

I had a long answer explaining it all but Richard beat me to it, and
his answer is pretty much exactly what I meant. Rebase wouldn't even
change, only the order of which stuffs are displayed in the editor.

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?

Well for us it's the current way that is confusing (and probably for a
lot of other users too, especially new ones). It's what we suggest
that would (imho) make it non-confusing... I'd very much like the
"benefit" from this discussion to be a change of default in how rebase
-i display commits, but as for some people having it reversed seems to
be a strong no-go, it seems the only rational thing we can do is offer
a --reverse option so the people used to the current way are happy.

If even adding an option is asking for too much, then we might resort
to EDITOR tricks and whatnot. You made me realise I could write a vim
script that offers the fonctionality I need without even touching git,
but it'd work for me only. I fail to see the problem with adding an
option which would simplify the life of many people and isn't invasive
for the others.

Philippe

The 11/05/11, Junio C Hamano 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,...

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.

I don't understand. Why not just _display_ the commit in reverse order?

Then, from the user POV commands like squash, fixup, etc would apply in
reverse order too (from up to down); keeping the mental model for "apply
against ancestor".

-- 
Nicolas Sebrecht

I don't understand. Why not just _display_ the commit in reverse order?
Then, from the user POV commands like squash, fixup, etc would apply in
reverse order too (from up to down); keeping the mental model for "apply
against ancestor".

Yes, this is what has been suggested. Just display in reverse in the
editor, and on save read the tasks to be done in a reverse manner or
simply reverse the tasks to be done before processing normally.

In fact I can already implement it in my editor by reversing the
commits (vim, some command), doing my stuffs, then reversing it back
before saving. It's pretty error prone because if I forget to reverse
them back then bad things happen, so it'd be nice if rebase handled
this for me.

Philippe