Re: git rebase --interactive commits order

From: Junio C Hamano <gitster@pobox.com>
Date: May 10, 2011, 23:26 UTC
Message-ID: <7vwrhygmrp.fsf@alter.siamese.dyndns.org>
In-Reply-To: <BANLkTinRcigdQv2GJN6L+nF3X2+F-5Lf5w@mail.gmail.com>

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 ;-).