{"thread":{"id":"27305","subject":"git rebase --interactive commits order","startedAt":"2011-05-09T09:30:14Z","lastAt":"2011-05-14T10:58:26Z","messageCount":14,"participants":["Philippe Vaucher","David","Steven E. Harris","Sverre Rabbelier","Junio C Hamano","Richard Peterson","Nicolas Sebrecht"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"167479","messageId":"BANLkTimX2tupqV464+Re8u06TT+qRmqPuw@mail.gmail.com","threadId":"27305","inReplyTo":null,"subject":"git rebase --interactive commits order","fromName":"Philippe Vaucher","fromEmail":"philippe.vaucher@gmail.com","sentAt":"2011-05-09T09:30:14Z","receivedAt":"2011-05-09T09:30:14Z","isPatch":false,"sender":{"key":"philippe.vaucher@gmail.com","avatar":null},"body":"Hello,\n\nI did try to find a similar topic in the archive, but couldn't so here I ask.\n\nIs there an option or would it be possible to make it so that `git\nrebase -i` lists commits in reverse chronological order, like it does\nfor `git log` ?\n\nAlmost every git commands I use lists events in reverse chronological\norder (reflog, log, gitk) and then you do an interactive rebase and it\nalways takes me a second or two to switch mindsets and start reading\nthem in chronological order. I asked around and I'm far from being the\nonly one who think this is counter-intuitive. I understand there's an\nimplementation simplicity reason for it to be that way, and also that\nit is somewhat logical to show the commits to be applied in order, but\nas your mind is trained to read them in reverse chronological order\nwith the other commands I'd find it more consistant if rebase also\nfollowed that.\n\nPhilippe\n"},{"id":"167481","messageId":"BANLkTi=PyBfMxCbWNfJEXEP6-MphdeE+_Q@mail.gmail.com","threadId":"27305","inReplyTo":"BANLkTimX2tupqV464+Re8u06TT+qRmqPuw@mail.gmail.com","subject":"Re: git rebase --interactive commits order","fromName":"David","fromEmail":"bouncingcats@gmail.com","sentAt":"2011-05-09T10:10:23Z","receivedAt":"2011-05-09T10:10:23Z","isPatch":false,"sender":{"key":"bouncingcats@gmail.com","avatar":null},"body":"On 9 May 2011 19:30, Philippe Vaucher wrote:\n>\n> Is there an option or would it be possible to make it so that `git\n> rebase -i` lists commits in reverse chronological order, like it does\n> for `git log` ?\n>\n> Almost every git commands I use lists events in reverse chronological\n> order (reflog, log, gitk) and then you do an interactive rebase and it\n> always takes me a second or two to switch mindsets and start reading\n> them in chronological order. I asked around and I'm far from being the\n> only one who think this is counter-intuitive. I understand there's an\n> implementation simplicity reason for it to be that way, and also that\n> it is somewhat logical to show the commits to be applied in order, but\n> as your mind is trained to read them in reverse chronological order\n> with the other commands I'd find it more consistant if rebase also\n> followed that.\n\nI agree. I use \"rebase -i\" a lot, often simultaneously viewing with\ngitk, and I find my work rate is reduced because it is anti-intuitive\nto have different tools showing the same information in the opposite\norder, especially when squashing commits. I find I have to do a mental\ndouble check before every such operation. Like the OP, I would like to\nsee \"rebase -i\" gain the capability to display commits in the same\nonscreen-ordering as the other command tools.\n"},{"id":"167555","messageId":"m2d3jr1mev.fsf@Spindle.sehlabs.com","threadId":"27305","inReplyTo":"BANLkTi=PyBfMxCbWNfJEXEP6-MphdeE+_Q@mail.gmail.com","subject":"Re: git rebase --interactive commits order","fromName":"Steven E. Harris","fromEmail":"seh@panix.com","sentAt":"2011-05-09T23:31:20Z","receivedAt":"2011-05-09T23:31:20Z","isPatch":false,"sender":{"key":"seh@panix.com","avatar":"https://gravatar.com/avatar/d59ec0f7c010ee73cd67db381a5b865206fed17fd4278f12cdb6277db30033fc?d=mp&s=160"},"body":"David writes:\n\n> I find I have to do a mental double check before every such operation.\n\nI don't think I've /ever/ run \"rebase -i\" and gotten the order correct\non the first try. I have to note the oldest commit I expect to see, hunt\naround for it in the list, orient myself to the sequence, then try to\nrearrange things. Usually the rearrangement still winds up being in the\nwrong order.\n\n-- \nSteven E. Harris\n"},{"id":"167638","messageId":"BANLkTim1e=+yoyxd1AAThVYMZ_X3nfz=7Q@mail.gmail.com","threadId":"27305","inReplyTo":"m2d3jr1mev.fsf@Spindle.sehlabs.com","subject":"Re: git rebase --interactive commits order","fromName":"Philippe Vaucher","fromEmail":"philippe.vaucher@gmail.com","sentAt":"2011-05-10T22:20:22Z","receivedAt":"2011-05-10T22:20:22Z","isPatch":false,"sender":{"key":"philippe.vaucher@gmail.com","avatar":null},"body":"So, sounds like most people agree with me. What should we do for this\nto happen? propose a patch?\n\nPhilippe\n"},{"id":"167640","messageId":"BANLkTinRcigdQv2GJN6L+nF3X2+F-5Lf5w@mail.gmail.com","threadId":"27305","inReplyTo":"BANLkTim1e=+yoyxd1AAThVYMZ_X3nfz=7Q@mail.gmail.com","subject":"Re: git rebase --interactive commits order","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-05-10T22:30:47Z","receivedAt":"2011-05-10T22:30:47Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Wed, May 11, 2011 at 00:20, Philippe Vaucher\n wrote:\n> So, sounds like most people agree with me. What should we do for this\n> to happen? propose a patch?\n\nYes, write a patch that adds a --reverse flag, off by default, (or\nsomething like that), possibly with a config flag.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"167643","messageId":"7vbozai2qe.fsf@alter.siamese.dyndns.org","threadId":"27305","inReplyTo":"BANLkTim1e=+yoyxd1AAThVYMZ_X3nfz=7Q@mail.gmail.com","subject":"Re: git rebase --interactive commits order","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-10T22:56:41Z","receivedAt":"2011-05-10T22:56:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philippe Vaucher writes:\n\n> So, sounds like most people agree with me.\n\nNo. You have to realize that happy majority are usually silent.\n\nIt is just most people including me know better than reading your thread\nand filling the thread with the same \"I have been completely content with\nthe current order to read from top to bottom when reading text at the\nbeginning of the screen (i.e. in the editor); do not change it\".\n"},{"id":"167644","messageId":"BANLkTik6ZYVFP=2TnYiZ4iVZhOzSdizTEg@mail.gmail.com","threadId":"27305","inReplyTo":"7vbozai2qe.fsf@alter.siamese.dyndns.org","subject":"Re: git rebase --interactive commits order","fromName":"Philippe Vaucher","fromEmail":"philippe.vaucher@gmail.com","sentAt":"2011-05-10T23:05:09Z","receivedAt":"2011-05-10T23:05:09Z","isPatch":false,"sender":{"key":"philippe.vaucher@gmail.com","avatar":null},"body":">> So, sounds like most people agree with me.\n>\n> No. You have to realize that happy majority are usually silent.\n>\n> It is just most people including me know better than reading your thread\n> and filling the thread with the same \"I have been completely content with\n> the current order to read from top to bottom when reading text at the\n> beginning of the screen (i.e. in the editor); do not change it\".\n\nWell if people really don't want it to change they'd speak up (like\nyou did), otherwise things will change and as you seem to suggest the\nmajority will be pissed off.\n\nIMHO it's more like the majority don't really care.\nAnyway, offering a \"--reverse\" patch off by default would please\neveryone, I'll see what I can do.\n\nPhilippe\n"},{"id":"167646","messageId":"7vwrhygmrp.fsf@alter.siamese.dyndns.org","threadId":"27305","inReplyTo":"BANLkTinRcigdQv2GJN6L+nF3X2+F-5Lf5w@mail.gmail.com","subject":"Re: git rebase --interactive commits order","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-10T23:26:50Z","receivedAt":"2011-05-10T23:26:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sverre Rabbelier writes:\n\n> Yes, write a patch that adds a --reverse flag, off by default, (or\n> something like that), possibly with a config flag.\n\nWhat do you mean by \"something like that\" exactly?\n\nDevils lie in the details. For example, should squash/fixup come before\nor after the squashed commit when --reverse is in effect, and why?\n\nShould \"rebase --reverse --continue\" work after it gets interrupted, if\nnot why not?\n\nAfter all the insn sheet used by \"rebase -i\" is not like reading logs at\nall. It is a specification of the steps in the order they should be\ncarried out. If you are to pick A and then pick B and squash C into the\nresult and then reword D on top of the base commit, do you really think it\nis sane to list them like this?\n\n\treword D\n squash C\n pick B\n pick A\n\t# you can reorder and update commands above\n # p is for pick, r is for reword, ...\n\nI don't exactly remember what the help text said, but to me the above\nlooks totally backwards (and that is understandable because it is\nbackwards ;-).\n"},{"id":"167657","messageId":"BANLkTikV_TSEE1cgr=EOhuD0f8KP2vh-tA@mail.gmail.com","threadId":"27305","inReplyTo":"7vwrhygmrp.fsf@alter.siamese.dyndns.org","subject":"Re: git rebase --interactive commits order","fromName":"Richard Peterson","fromEmail":"richard@rcpeterson.com","sentAt":"2011-05-11T15:43:28Z","receivedAt":"2011-05-11T15:43:28Z","isPatch":false,"sender":{"key":"richard@rcpeterson.com","avatar":"https://gravatar.com/avatar/cc6d791c99e8302288a850cd4477a28bb7782b1133b03a45f7b7e0f93624390f?d=mp&s=160"},"body":"On Tue, May 10, 2011 at 7:26 PM, Junio C Hamano wrote:\n>\n> Devils lie in the details. For example, should squash/fixup come before\n> or after the squashed commit when --reverse is in effect, and why?\n>\n> Should \"rebase --reverse --continue\" work after it gets interrupted, if\n> not why not?\n\nYes, it should work, and in that case, \"rebase --continue\" should\nbe synonymous, because you are going to continue the current\nrebase operation, however the instructions happened to have\nbeen provided.\n\n>\n> After all the insn sheet used by \"rebase -i\" is not like reading logs at\n> all. It is a specification of the steps in the order they should be\n> carried out. If you are to pick A and then pick B and squash C into the\n> result and then reword D on top of the base commit, do you really think it\n> is sane to list them like this?\n>\n> reword D\n> squash C\n> pick B\n> pick A\n> # you can reorder and update commands above\n> # p is for pick, r is for reword, ...\n\nYes. It's still an instruction sheet - the only difference is the\norder in which the notation should be read.\n\nI may be arguing for something other than what Philippe is\nadvocating, but here's my take nonetheless.\n\nIt's simply a matter of parsing and presentation - not at all a\nmatter of changing what interactive rebase does.\n\nFor instance, I'll paste some output from\n\n$ git log --graph --decorate --oneline --all master..\n\n>From my current project. Then alongside the lines from that log\noutput, I'll write instructions to a coworker who will do a\nrebase.\n\n* 156c6be (HEAD, cor... # Please fixup into previous\n* b82955f Map Networ...\n* 1d6708a Add equals... # Reword (need more info)\n* e936162 NPLC objec...\n* 7fbb581 Create new... # Please squash into previous\n* 89d57a4 Add a \"Tot... # Please squash into previous\n* 24849ef Remove \"co...\n* 98d0840 Change ref...\n* 18886bf Uncomment...\n* 4a5844e (master)\n\nThis is just annotated log output. In the context of the log, I\ncan easily imagine the rebase proceeding to rebuild the tree from\nthe bottom up, and it is clear what I want to happen to each\ncommit.\n\nI want git to understand this same kind of thing.\n\nI think the problem is that some people are used to seeing the\noutput of git-log and understanding it as a representation of a\ntree. The instruction set of interactive rebase *looks* like such\na tree representation, but it isn't. It's a set of instructions.\n\nHowever, I think it is valid to want to view it as a sort of\nannotated tree. Although it may be interpreted under the hood as\na set of instructions, I believe it is synonymous with the tree\nview for any practical purpose. So I'd like to view interactive\nrebase much like the output of git-log, only annotated with the\nkinds of things that I want done to the tree. That seems to me a\nharmless abstraction that would help me do what I mean to do more\noften.\n\nSo for my purposes, simply reversing the lines before displaying\nthem, and then again before parsing them would do the\ntrick. Everything else would remain the same. For\ninstance \"squash\" would still mean \"squash this commit into the\nprevious commit\", where \"previous\" does not mean \"above\", but\nreally \"previous\".\n\n--continue would work just the same, since you're not really\ntelling git to do anything different with --reverse - just telling\nit what to do in a superficially different way.\n\nMy only concern is that the list of commits would look\nessentially the same except for the order. As a small mental aid,\nI would suggest adding \"(HEAD)\", like from --decorate. This\nwould help lend some clarity. So:\n\nreword D (HEAD)\nsquash C\npick B\npick A\n\nRichard Peterson\n"},{"id":"167678","messageId":"7v39klgng7.fsf@alter.siamese.dyndns.org","threadId":"27305","inReplyTo":"BANLkTikV_TSEE1cgr=EOhuD0f8KP2vh-tA@mail.gmail.com","subject":"Re: git rebase --interactive commits order","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-11T17:24:24Z","receivedAt":"2011-05-11T17:24:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Richard Peterson writes:\n\n> On Tue, May 10, 2011 at 7:26 PM, Junio C Hamano wrote:\n>>\n>> Devils lie in the details. For example, should squash/fixup come before\n>> or after the squashed commit when --reverse is in effect, and why?\n>>\n>> Should \"rebase --reverse --continue\" work after it gets interrupted, if\n>> not why not?\n>\n> Yes, it should work,...\n\nOf course, if you start with --reverse, it is clear and obvious that\n'continue' should continue with the reversed instruction sheet, and it\nprobabaly should take --reverse as a no-op when given with --continue.\nThe original question should have been written more carefully to avoid\nsoliciting the response that addresses that uninteresting case.\n\nYou start 'rebase' (without --reverse); it stops with conflict. Now what\nshould happen when you say 'rebase --reverse --continue' now? Does it\nerror out because you are not allowed to change your mind once you\nstarted?\n\nThat would make it inconsistent for the same \"--reverse --continue\" not to\nerror out when the entire process was started with --reverse, but erroring\nit out in that case would be awkward.\n\nI am not saying that these small details cannot be worked out. I am saying\nthat you would need to spend a lot of effort to take care of the details\nto avoid making it confusing to the users. And I am also saying that it\nis not even worth wasting the brainpower spent discussing these in this\nthread, if the only \"benefit\" resulting from it is to add an option that\nallows some people to have an ordered list of things to do \"First I do\nthis and then I do that\" that has to be read backwards. Why spend extra\neffort only to introduce something confusing?\n"},{"id":"167683","messageId":"BANLkTik3i8rcgDSo4A9nQjnvr-gWmnkpmQ@mail.gmail.com","threadId":"27305","inReplyTo":"7v39klgng7.fsf@alter.siamese.dyndns.org","subject":"Re: git rebase --interactive commits order","fromName":"Richard Peterson","fromEmail":"richard@rcpeterson.com","sentAt":"2011-05-11T18:39:34Z","receivedAt":"2011-05-11T18:39:34Z","isPatch":false,"sender":{"key":"richard@rcpeterson.com","avatar":"https://gravatar.com/avatar/cc6d791c99e8302288a850cd4477a28bb7782b1133b03a45f7b7e0f93624390f?d=mp&s=160"},"body":"On Wed, May 11, 2011 at 1:24 PM, Junio C Hamano wrote:\n> Richard Peterson writes:\n>\n>> On Tue, May 10, 2011 at 7:26 PM, Junio C Hamano wrote:\n>>>\n>>> Devils lie in the details.  For example, should squash/fixup come before\n>>> or after the squashed commit when --reverse is in effect, and why?\n>>>\n>>> Should \"rebase --reverse --continue\" work after it gets interrupted, if\n>>> not why not?\n>>\n>> Yes, it should work,...\n>\n[...]\n>\n> You start 'rebase' (without --reverse); it stops with conflict.  Now what\n> should happen when you say 'rebase --reverse --continue' now?  Does it\n> error out because you are not allowed to change your mind once you\n> started?\n\nIt just continues. \"--reverse\" is noise here. \"--reverse\" would only matter\nin the display of the initial list. It's just as much noise here as\n'--interactive'\nwould be noise here, like 'rebase --interactive --continue'.\n\n> [...] Why spend extra effort only to introduce something confusing?\n\nBecause for some group of people, you are introducing something less\nconfusing. I have a hunch that some people see the *process* as the primary\nartifact, and thus things make sense just as they are. Others see the *tree*\nas the primary artifact, and want too see the transformation that will be\nattempted on the tree - but interactive rebase has the tree upside down.\n\nI have absolutely no support for this theory other than that I find myself in\nthe second group of people however small or large that group may be. I\nconceive of a rebase as a transformation of the tree, rather than a set of\ndiscrete steps. Tools that help me work with that abstraction are going to\nbe easier for me and others like me.\n\n-Richard\n"},{"id":"167684","messageId":"BANLkTikMo_VLMc2zxezgX_mjCaB8C2LgBw@mail.gmail.com","threadId":"27305","inReplyTo":"7v39klgng7.fsf@alter.siamese.dyndns.org","subject":"Re: git rebase --interactive commits order","fromName":"Philippe Vaucher","fromEmail":"philippe.vaucher@gmail.com","sentAt":"2011-05-11T18:45:56Z","receivedAt":"2011-05-11T18:45:56Z","isPatch":false,"sender":{"key":"philippe.vaucher@gmail.com","avatar":null},"body":"> You start 'rebase' (without --reverse); it stops with conflict.  Now what\n> should happen when you say 'rebase --reverse --continue' now?  Does it\n> error out because you are not allowed to change your mind once you\n> started?\n\nI had a long answer explaining it all but Richard beat me to it, and\nhis answer is pretty much exactly what I meant. Rebase wouldn't even\nchange, only the order of which stuffs are displayed in the editor.\n\n> I am not saying that these small details cannot be worked out. I am saying\n> that you would need to spend a lot of effort to take care of the details\n> to avoid making it confusing to the users.  And I am also saying that it\n> is not even worth wasting the brainpower spent discussing these in this\n> thread, if the only \"benefit\" resulting from it is to add an option that\n> allows some people to have an ordered list of things to do \"First I do\n> this and then I do that\" that has to be read backwards. Why spend extra\n> effort only to introduce something confusing?\n\nWell for us it's the current way that is confusing (and probably for a\nlot of other users too, especially new ones). It's what we suggest\nthat would (imho) make it non-confusing... I'd very much like the\n\"benefit\" from this discussion to be a change of default in how rebase\n-i display commits, but as for some people having it reversed seems to\nbe a strong no-go, it seems the only rational thing we can do is offer\na --reverse option so the people used to the current way are happy.\n\nIf even adding an option is asking for too much, then we might resort\nto EDITOR tricks and whatnot. You made me realise I could write a vim\nscript that offers the fonctionality I need without even touching git,\nbut it'd work for me only. I fail to see the problem with adding an\noption which would simplify the life of many people and isn't invasive\nfor the others.\n\nPhilippe\n"},{"id":"167818","messageId":"20110513175112.GA14079@vidovic","threadId":"27305","inReplyTo":"7v39klgng7.fsf@alter.siamese.dyndns.org","subject":"Re: git rebase --interactive commits order","fromName":"Nicolas Sebrecht","fromEmail":"nicolas.s.dev@gmx.fr","sentAt":"2011-05-13T17:51:12Z","receivedAt":"2011-05-13T17:51:12Z","isPatch":false,"sender":{"key":"nicolas.s.dev@gmx.fr","avatar":null},"body":"The 11/05/11, Junio C Hamano wrote:\n> Richard Peterson writes:\n> \n> > On Tue, May 10, 2011 at 7:26 PM, Junio C Hamano wrote:\n> >>\n> >> Devils lie in the details. For example, should squash/fixup come before\n> >> or after the squashed commit when --reverse is in effect, and why?\n> >>\n> >> Should \"rebase --reverse --continue\" work after it gets interrupted, if\n> >> not why not?\n> >\n> > Yes, it should work,...\n> \n> Of course, if you start with --reverse, it is clear and obvious that\n> 'continue' should continue with the reversed instruction sheet, and it\n> probabaly should take --reverse as a no-op when given with --continue.\n> The original question should have been written more carefully to avoid\n> soliciting the response that addresses that uninteresting case.\n\nI don't understand. Why not just _display_ the commit in reverse order?\n\nThen, from the user POV commands like squash, fixup, etc would apply in\nreverse order too (from up to down); keeping the mental model for \"apply\nagainst ancestor\".\n\n-- \nNicolas Sebrecht\n"},{"id":"167839","messageId":"BANLkTinbHOD9AXycM1gXYab+P-PMwOxK6Q@mail.gmail.com","threadId":"27305","inReplyTo":"20110513175112.GA14079@vidovic","subject":"Re: git rebase --interactive commits order","fromName":"Philippe Vaucher","fromEmail":"philippe.vaucher@gmail.com","sentAt":"2011-05-14T10:58:26Z","receivedAt":"2011-05-14T10:58:26Z","isPatch":false,"sender":{"key":"philippe.vaucher@gmail.com","avatar":null},"body":"> I don't understand. Why not just _display_ the commit in reverse order?\n> Then, from the user POV commands like squash, fixup, etc would apply in\n> reverse order too (from up to down); keeping the mental model for \"apply\n> against ancestor\".\n\nYes, this is what has been suggested. Just display in reverse in the\neditor, and on save read the tasks to be done in a reverse manner or\nsimply reverse the tasks to be done before processing normally.\n\nIn fact I can already implement it in my editor by reversing the\ncommits (vim, some command), doing my stuffs, then reversing it back\nbefore saving. It's pretty error prone because if I forget to reverse\nthem back then bad things happen, so it'd be nice if rebase handled\nthis for me.\n\nPhilippe\n"}]}