{"thread":{"id":"38948","subject":"RFC: Renaming \"git rebase --onto\"","startedAt":"2015-03-30T20:49:34Z","lastAt":"2015-04-02T16:40:26Z","messageCount":5,"participants":["Jonathon Mah","Jonathan Nieder","Junio C Hamano","Max Kirillov","Michael J Gruber"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"258692","messageId":"05D9209E-FAA2-44C8-9B98-B00997AF5779@JonathonMah.com","threadId":"38948","inReplyTo":null,"subject":"RFC: Renaming \"git rebase --onto\"","fromName":"Jonathon Mah","fromEmail":"me@jonathonmah.com","sentAt":"2015-03-30T20:49:34Z","receivedAt":"2015-03-30T20:49:34Z","isPatch":false,"sender":{"key":"me@jonathonmah.com","avatar":"https://avatars.githubusercontent.com/u/2748?v=4"},"body":"During a few years of discussing git operations with colleagues, I’ve found the “git rebase --onto” operation particularly ambiguous. The reason is that I always describe a rebase operation as “onto” something else (because of the English phrase “A is based on B”). For example: \n\n$ git rebase new-base # “Rebase HEAD onto new-base (from merge-base of HEAD and new-base)\"\n$ git rebase new-base my-branch # “Rebase my-branch onto new-base (from merge-base of my-branch and new-base)”\n\nPersonally, I understand “git-rebase --onto new-base old-base” as meaning “rebase from old-base to new-base”. Some prepositions that might make this clearer:\n\n$ git rebase --from old-base new-base # “Rebase HEAD onto new-base, from old-base\"\n$ git rebase --after old-base new-base # “Rebase commits on HEAD after old-base HEAD onto new-base\"\n$ git rebase --excluding old-base new-base # “Rebase HEAD onto new-base, excluding commit old-base (and its parents)\"\n\nIn all cases this would change the order of the arguments compared to --onto, making it more consistent with the no-option rebase.\n\nWhat do others think? Is my view of “onto” common or unusual?\n\n\n\nJonathon Mah\nme@JonathonMah.com\n"},{"id":"258693","messageId":"20150330210319.GC22844@google.com","threadId":"38948","inReplyTo":"05D9209E-FAA2-44C8-9B98-B00997AF5779@JonathonMah.com","subject":"Re: RFC: Renaming \"git rebase --onto\"","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2015-03-30T21:03:19Z","receivedAt":"2015-03-30T21:03:19Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jonathon Mah wrote:\n\n> Personally, I understand “git-rebase --onto new-base old-base” as\n> meaning “rebase from old-base to new-base”. Some prepositions that\n> might make this clearer:\n>\n> $ git rebase --from old-base new-base # “Rebase HEAD onto new-base, from old-base\"\n\nWould having an option name for the old-base argument help?\n\nFor example:\n\n\tgit rebase --old-base= --onto= \n\n?\n\nThanks,\nJonathan\n"},{"id":"258695","messageId":"xmqqk2xyw5p3.fsf@gitster.dls.corp.google.com","threadId":"38948","inReplyTo":"05D9209E-FAA2-44C8-9B98-B00997AF5779@JonathonMah.com","subject":"Re: RFC: Renaming \"git rebase --onto\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-30T21:12:08Z","receivedAt":"2015-03-30T21:12:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathon Mah writes:\n\n> During a few years of discussing git operations with colleagues, I’ve\n> found the “git rebase --onto” operation particularly ambiguous. The\n> reason is that I always describe a rebase operation as “onto”\n> something else (because of the English phrase “A is based on\n> B”). For example:\n>\n> $ git rebase new-base # “Rebase HEAD onto new-base (from merge-base of HEAD and new-base)\"\n> $ git rebase new-base my-branch # “Rebase my-branch onto new-base\n> (from merge-base of my-branch and new-base)”\n>\n> Personally, I understand “git-rebase --onto new-base old-base” as\n> meaning “rebase from old-base to new-base”. Some prepositions that\n> might make this clearer:\n>\n> $ git rebase --from old-base new-base # “Rebase HEAD onto new-base, from old-base\"\n> $ git rebase --after old-base new-base # “Rebase commits on HEAD\n> after old-base HEAD onto new-base\"\n> $ git rebase --excluding old-base new-base # “Rebase HEAD onto\n> new-base, excluding commit old-base (and its parents)\"\n>\n> In all cases this would change the order of the arguments compared to\n> --onto, making it more consistent with the no-option rebase.\n\nThe bog-standard rebase is\n\n git rebase U\n\nwhich rebases the current history that has diverged from the history\nleading to U on to U.\n\nOr\n\n git rebase U BRANCH\n\nwhich rebases BRANCH that has diverged from the history leading to U\non to U. In both of these invocations, these arguments define which\npart of the local history is replayed.\n\nNow,\n\n git rebase [--onto O] $other_args\n\nis just a way to say $other_args still define which part of the\nlocal history is replayed, but you are replaying on something that\nis different from the usual default case (which is U).\n\nWhich feels very consistent between the cases with and without the\nextra --onto parameter, at least to me. Hence, if you change order\nin any way, I would think you would break the existing consistency.\n\nI suspect that this thread is a symptom of something unrelated,\nthough. There might be something wrong in your workflow if you find\nyourself using --onto too often, for example, and that may be the\nissue we should be focusing on, not on how \"rebase --onto\" is\nspelled.\n\n> What do others think? Is my view of “onto” common or unusual?\n\n\"common or unusual\" is a question we cannot answer, I would say.\nPeople who are used to \"rebase\" may be so used to it that it might\nfeel natural to them but cannot tell if that is only because they\nalready know how \"rebase\" spells its arguments, or they would still\nfind it natural if they did not know anything about \"rebase\".\n"},{"id":"258697","messageId":"20150330215354.GB8771@wheezy.local","threadId":"38948","inReplyTo":"05D9209E-FAA2-44C8-9B98-B00997AF5779@JonathonMah.com","subject":"Re: RFC: Renaming \"git rebase --onto\"","fromName":"Max Kirillov","fromEmail":"max@max630.net","sentAt":"2015-03-30T21:53:54Z","receivedAt":"2015-03-30T21:53:54Z","isPatch":false,"sender":{"key":"max@max630.net","avatar":"https://avatars.githubusercontent.com/u/381560?v=4"},"body":"On Mon, Mar 30, 2015 at 01:49:34PM -0700, Jonathon Mah wrote:\n> During a few years of discussing git operations with colleagues, I’ve found the “git rebase --onto” operation particularly ambiguous. The reason is that I always describe a rebase operation as “onto” something else (because of the English phrase “A is based on B”). For example: \n> \n> $ git rebase new-base # “Rebase HEAD onto new-base (from merge-base of HEAD and new-base)\"\n> $ git rebase new-base my-branch # “Rebase my-branch onto new-base (from merge-base of my-branch and new-base)”\n> \n> Personally, I understand “git-rebase --onto new-base old-base” as meaning “rebase from old-base to new-base”. Some prepositions that might make this clearer:\n> \n> $ git rebase --from old-base new-base # “Rebase HEAD onto new-base, from old-base\"\n> $ git rebase --after old-base new-base # “Rebase commits on HEAD after old-base HEAD onto new-base\"\n> $ git rebase --excluding old-base new-base # “Rebase HEAD onto new-base, excluding commit old-base (and its parents)\"\n> \n> In all cases this would change the order of the arguments compared to --onto, making it more consistent with the no-option rebase.\n> \n> What do others think? Is my view of “onto” common or unusual?\n\nI have never liked the --onto syntax also. It's not only\nugly but still fails to cover some needs. So in my, you know,\nclone of rebase I have made completely different syntax.\nYou can take a look at it here:\nhttps://github.com/max630/git-rebase2/#usage\n\nI just copy the line here, without descriptions:\ngit rebase2 [options] [[]..[..]..[]] []\n\n-- \nMax\n"},{"id":"258865","messageId":"551D70FA.7010708@drmicha.warpmail.net","threadId":"38948","inReplyTo":"xmqqk2xyw5p3.fsf@gitster.dls.corp.google.com","subject":"Re: RFC: Renaming \"git rebase --onto\"","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2015-04-02T16:40:26Z","receivedAt":"2015-04-02T16:40:26Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 30.03.2015 23:12:\n> Jonathon Mah writes:\n> \n>> During a few years of discussing git operations with colleagues, I’ve\n>> found the “git rebase --onto” operation particularly ambiguous. The\n>> reason is that I always describe a rebase operation as “onto”\n>> something else (because of the English phrase “A is based on\n>> B”). For example:\n>>\n>> $ git rebase new-base # “Rebase HEAD onto new-base (from merge-base of HEAD and new-base)\"\n>> $ git rebase new-base my-branch # “Rebase my-branch onto new-base\n>> (from merge-base of my-branch and new-base)”\n>>\n>> Personally, I understand “git-rebase --onto new-base old-base” as\n>> meaning “rebase from old-base to new-base”. Some prepositions that\n>> might make this clearer:\n>>\n>> $ git rebase --from old-base new-base # “Rebase HEAD onto new-base, from old-base\"\n>> $ git rebase --after old-base new-base # “Rebase commits on HEAD\n>> after old-base HEAD onto new-base\"\n>> $ git rebase --excluding old-base new-base # “Rebase HEAD onto\n>> new-base, excluding commit old-base (and its parents)\"\n>>\n>> In all cases this would change the order of the arguments compared to\n>> --onto, making it more consistent with the no-option rebase.\n> \n> The bog-standard rebase is\n> \n> git rebase U\n> \n> which rebases the current history that has diverged from the history\n> leading to U on to U.\n> \n> Or\n> \n> git rebase U BRANCH\n> \n> which rebases BRANCH that has diverged from the history leading to U\n> on to U. In both of these invocations, these arguments define which\n> part of the local history is replayed.\n> \n> Now,\n> \n> git rebase [--onto O] $other_args\n> \n> is just a way to say $other_args still define which part of the\n> local history is replayed, but you are replaying on something that\n> is different from the usual default case (which is U).\n> \n> Which feels very consistent between the cases with and without the\n> extra --onto parameter, at least to me. Hence, if you change order\n> in any way, I would think you would break the existing consistency.\n> \n> I suspect that this thread is a symptom of something unrelated,\n> though. There might be something wrong in your workflow if you find\n> yourself using --onto too often, for example, and that may be the\n> issue we should be focusing on, not on how \"rebase --onto\" is\n> spelled.\n> \n>> What do others think? Is my view of “onto” common or unusual?\n> \n> \"common or unusual\" is a question we cannot answer, I would say.\n> People who are used to \"rebase\" may be so used to it that it might\n> feel natural to them but cannot tell if that is only because they\n> already know how \"rebase\" spells its arguments, or they would still\n> find it natural if they did not know anything about \"rebase\".\n> \n\nThe basic confusion comes from the natural desire to read a command as a\nsentence, and the lack of the rebase UI in that respect:\n\n\"git rebase foo\" does not \"rebase foo\"!\n\n\"git rebase foo bar\" does not \"rebase foo\" either!\n\nI think it's a UI design mistake that comes from making the common\nuse-case as short as possible.\n\nIn the invocations above, \"foo\" is neither the ref that is being rebased\nnor a rev notation for the affected commits. That would have been foo..\nor ^foo.\n\nI seem to recall that we've talked about range notations for rebase.\nMaybe we can start accepting them, and once we start teaching \"git\nrebase ^foo\" or \"git rebase foo..\" it will become clearer that that\nargument is not the ref being rebased, but a description of the commits\nbeing rebased. And then it would be natural to talk about \"onto foo\" for\nthese cases, as well as leave the \"--onto\" argument named the way it is\n(since it defaults to foo, or rather the fork-point).\n\nMichael\n"}]}