From: Junio C Hamano Date: Tue, 10 May 2011 23:26:50 GMT Subject: Re: git rebase --interactive commits order Message-ID: <7vwrhygmrp.fsf@alter.siamese.dyndns.org> In-Reply-To: Sverre Rabbelier 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 ;-).