Re: git rebase --interactive commits order

[Richard Peterson <richard@rcpeterson.com>]

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