git rebase --interactive commits order

git rebase --interactive commits order

[Philippe Vaucher]

Hello,

I did try to find a similar topic in the archive, but couldn't so here I ask.

Is there an option or would it be possible to make it so that `git
rebase -i` lists commits in reverse chronological order, like it does
for `git log` ?

Almost every git commands I use lists events in reverse chronological
order (reflog, log, gitk) and then you do an interactive rebase and it
always takes me a second or two to switch mindsets and start reading
them in chronological order. I asked around and I'm far from being the
only one who think this is counter-intuitive. I understand there's an
implementation simplicity reason for it to be that way, and also that
it is somewhat logical to show the commits to be applied in order, but
as your mind is trained to read them in reverse chronological order
with the other commands I'd find it more consistant if rebase also
followed that.

Philippe

Re: git rebase --interactive commits order

[David]

On 9 May 2011 19:30, Philippe Vaucher <philippe.vaucher@gmail.com> wrote:
>
> Is there an option or would it be possible to make it so that `git
> rebase -i` lists commits in reverse chronological order, like it does
> for `git log` ?
>
> Almost every git commands I use lists events in reverse chronological
> order (reflog, log, gitk) and then you do an interactive rebase and it
> always takes me a second or two to switch mindsets and start reading
> them in chronological order. I asked around and I'm far from being the
> only one who think this is counter-intuitive. I understand there's an
> implementation simplicity reason for it to be that way, and also that
> it is somewhat logical to show the commits to be applied in order, but
> as your mind is trained to read them in reverse chronological order
> with the other commands I'd find it more consistant if rebase also
> followed that.

I agree. I use "rebase -i" a lot, often simultaneously viewing with
gitk, and  I find my work rate is reduced because it is anti-intuitive
to have different tools showing the same information in the opposite
order, especially when squashing commits. I find I have to do a mental
double check before every such operation. Like the OP, I would like to
see "rebase -i" gain the capability to display commits in the same
onscreen-ordering as the other command tools.

Re: git rebase --interactive commits order

[Steven E. Harris]

David <bouncingcats@gmail.com> writes:

> I find I have to do a mental double check before every such operation.

I don't think I've /ever/ run "rebase -i" and gotten the order correct
on the first try. I have to note the oldest commit I expect to see, hunt
around for it in the list, orient myself to the sequence, then try to
rearrange things. Usually the rearrangement still winds up being in the
wrong order.

-- 
Steven E. Harris

Re: git rebase --interactive commits order

[Philippe Vaucher]

So, sounds like most people agree with me. What should we do for this
to happen? propose a patch?

Philippe

Re: git rebase --interactive commits order

[Sverre Rabbelier]

Heya,

On Wed, May 11, 2011 at 00:20, Philippe Vaucher
<philippe.vaucher@gmail.com> wrote:
> So, sounds like most people agree with me. What should we do for this
> to happen? propose a patch?

Yes, write a patch that adds a --reverse flag, off by default, (or
something like that), possibly with a config flag.

-- 
Cheers,

Sverre Rabbelier

Re: git rebase --interactive commits order

[Junio C Hamano]

Philippe Vaucher <philippe.vaucher@gmail.com> writes:

> So, sounds like most people agree with me.

No. You have to realize that happy majority are usually silent.

It is just most people including me know better than reading your thread
and filling the thread with the same "I have been completely content with
the current order to read from top to bottom when reading text at the
beginning of the screen (i.e. in the editor); do not change it".

Re: git rebase --interactive commits order

[Philippe Vaucher]

>> So, sounds like most people agree with me.
>
> No. You have to realize that happy majority are usually silent.
>
> It is just most people including me know better than reading your thread
> and filling the thread with the same "I have been completely content with
> the current order to read from top to bottom when reading text at the
> beginning of the screen (i.e. in the editor); do not change it".

Well if people really don't want it to change they'd speak up (like
you did), otherwise things will change and as you seem to suggest the
majority will be pissed off.

IMHO it's more like the majority don't really care.
Anyway, offering a "--reverse" patch off by default would please
everyone, I'll see what I can do.

Philippe

Re: git rebase --interactive commits order

[Junio C Hamano]

Sverre Rabbelier <srabbelier@gmail.com> writes:

> Yes, write a patch that adds a --reverse flag, off by default, (or
> something like that), possibly with a config flag.

What do you mean by "something like that" exactly?

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?

After all the insn sheet used by "rebase -i" is not like reading logs at
all.  It is a specification of the steps in the order they should be
carried out.  If you are to pick A and then pick B and squash C into the
result and then reword D on top of the base commit, do you really think it
is sane to list them like this?

	reword D
        squash C
        pick B
        pick A
	# you can reorder and update commands above
        # p is for pick, r is for reword, ...

I don't exactly remember what the help text said, but to me the above
looks totally backwards (and that is understandable because it is
backwards ;-).

Re: git rebase --interactive commits order

[Richard Peterson]

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, and in that case, "rebase --continue" should
be synonymous, because you are going to continue the current
rebase operation, however the instructions happened to have
been provided.

>
> After all the insn sheet used by "rebase -i" is not like reading logs at
> all.  It is a specification of the steps in the order they should be
> carried out.  If you are to pick A and then pick B and squash C into the
> result and then reword D on top of the base commit, do you really think it
> is sane to list them like this?
>
>        reword D
>        squash C
>        pick B
>        pick A
>        # you can reorder and update commands above
>        # p is for pick, r is for reword, ...

Yes. It's still an instruction sheet - the only difference is the
order in which the notation should be read.

I may be arguing for something other than what Philippe is
advocating, but here's my take nonetheless.

It's simply a matter of parsing and presentation - not at all a
matter of changing what interactive rebase does.

For instance, I'll paste some output from

$ git log --graph --decorate --oneline --all master..

>From my current project. Then alongside the lines from that log
output, I'll write instructions to a coworker who will do a
rebase.

* 156c6be (HEAD, cor...  # Please fixup into previous
* b82955f Map Networ...
* 1d6708a Add equals...  # Reword (need more info)
* e936162 NPLC objec...
* 7fbb581 Create new...  # Please squash into previous
* 89d57a4 Add a "Tot...  # Please squash into previous
* 24849ef Remove "co...
* 98d0840 Change ref...
* 18886bf Uncomment...
*  4a5844e (master)

This is just annotated log output. In the context of the log, I
can easily imagine the rebase proceeding to rebuild the tree from
the bottom up, and it is clear what I want to happen to each
commit.

I want git to understand this same kind of thing.

I think the problem is that some people are used to seeing the
output of git-log and understanding it as a representation of a
tree. The instruction set of interactive rebase *looks* like such
a tree representation, but it isn't. It's a set of instructions.

However, I think it is valid to want to view it as a sort of
annotated tree. Although it may be interpreted under the hood as
a set of instructions, I believe it is synonymous with the tree
view for any practical purpose. So I'd like to view interactive
rebase much like the output of git-log, only annotated with the
kinds of things that I want done to the tree. That seems to me a
harmless abstraction that would help me do what I mean to do more
often.

So for my purposes, simply reversing the lines before displaying
them, and then again before parsing them would do the
trick. Everything else would remain the same. For
instance "squash" would still mean "squash this commit into the
previous commit", where "previous" does not mean "above", but
really "previous".

--continue would work just the same, since you're not really
telling git to do anything different with --reverse - just telling
it what to do in a superficially different way.

My only concern is that the list of commits would look
essentially the same except for the order. As a small mental aid,
I would suggest adding "(HEAD)", like from --decorate.  This
would help lend some clarity. So:

reword D (HEAD)
squash C
pick B
pick A

Richard Peterson

Re: git rebase --interactive commits order

[Junio C Hamano]

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

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?

Re: git rebase --interactive commits order

[Richard Peterson]

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

Re: git rebase --interactive commits order

[Philippe Vaucher]

> 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

Re: git rebase --interactive commits order

[Nicolas Sebrecht]

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

Re: git rebase --interactive commits order

[Philippe Vaucher]

> 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