On Tue, May 10, 2011 at 7:26 PM, Junio C Hamano <gitster@xxxxxxxxx> 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 -- 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