Sverre Rabbelier <srabbelier@xxxxxxxxx> 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 ;-).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html