Re: git rebase --interactive commits order

Sverre Rabbelier [off-list ref] 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 ;-).