{"thread":{"id":"56174","subject":"Using two-dot range notation in `git rebase`?","startedAt":"2021-07-28T15:38:09Z","lastAt":"2021-07-29T19:34:02Z","messageCount":10,"participants":["Philip Oakley","Daniel Knittl-Frank","Jeff King","Junio C Hamano","Sergey Organov"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"431401","messageId":"b3b5f044-8c76-ec71-45d6-1c7fea93c519@iee.email","threadId":"56174","inReplyTo":null,"subject":"Using two-dot range notation in `git rebase`?","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-07-28T15:38:04Z","receivedAt":"2021-07-28T15:38:09Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Is there a reasonable way to use the two-dot range notation in git\nrebase, particularly in an  --onto situation?\n\nIn my case I have a short series that depends on both some existing Git\nfor Windows (GfW) patches (`main` branch), and some patches now in\n`git/master`. I'm now able to rebase it onto the GfW `shears/master`\nbranch which contains both sets of patches (and one that was in the last\ngit release).\n\nIt felt that it ought to be possible to use a simple two dot range to\nextract my series, rather than identifying the individual end points in\na similar manner to that used in the description\"set of commits .. shown\nby `git log ..HEAD`\".\n\nOr is this something that could be a project?\n--\n\nPhilip\n\n\n"},{"id":"431402","messageId":"CACx-yZ1Je+tnZdJ21gDPeuQa-QTuY2t9mDujNr7wqJWFMwwzxA@mail.gmail.com","threadId":"56174","inReplyTo":"b3b5f044-8c76-ec71-45d6-1c7fea93c519@iee.email","subject":"Re: Using two-dot range notation in `git rebase`?","fromName":"Daniel Knittl-Frank","fromEmail":"knittl89@googlemail.com","sentAt":"2021-07-28T16:33:54Z","receivedAt":"2021-07-28T16:34:09Z","isPatch":false,"sender":{"key":"knittl89@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/2149217?v=4"},"body":"Hi Philip,\n\n git log upstream..HEAD\n\ngives you all commits reachable from \"HEAD\", but not reachable from\n\"upstream\". If you want to rebase this range and copy it onto newbase,\nyou'd run\n\n git rebase --onto newbase upstream\n\nThis will take the commits upstream..HEAD (the HEAD argument is\nimplicit), and you end up with\n\n newbase-.....-HEAD\n\ncontaining all commits from (the previous) \"HEAD\" up to (but\nexcluding) \"upstream\". If \"newbase\" and \"upstream\" are identical, the\ncommand can be simplified to `git rebase newbase`.\n\nMaybe I'm misunderstanding the problem? Can you give an example of\n`git rebase --onto newbase upstream branch` not working as expected?\n\nRegards\nDaniel\n\nOn Wed, Jul 28, 2021 at 5:38 PM Philip Oakley wrote:\n>\n> Is there a reasonable way to use the two-dot range notation in git\n> rebase, particularly in an --onto situation?\n>\n> In my case I have a short series that depends on both some existing Git\n> for Windows (GfW) patches (`main` branch), and some patches now in\n> `git/master`. I'm now able to rebase it onto the GfW `shears/master`\n> branch which contains both sets of patches (and one that was in the last\n> git release).\n>\n> It felt that it ought to be possible to use a simple two dot range to\n> extract my series, rather than identifying the individual end points in\n> a similar manner to that used in the description\"set of commits .. shown\n> by `git log ..HEAD`\".\n>\n> Or is this something that could be a project?\n> --\n>\n> Philip\n>\n>\n\n\n-- \ntyped with http://neo-layout.org\n"},{"id":"431473","messageId":"dc7668ff-37ad-1d9e-fc92-df432549b4e2@iee.email","threadId":"56174","inReplyTo":"CACx-yZ1Je+tnZdJ21gDPeuQa-QTuY2t9mDujNr7wqJWFMwwzxA@mail.gmail.com","subject":"Re: Using two-dot range notation in `git rebase`?","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-07-29T09:58:15Z","receivedAt":"2021-07-29T09:58:20Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 28/07/2021 17:33, Daniel Knittl-Frank wrote:\n> Hi Philip,\n>\n> git log upstream..HEAD\n>\n> gives you all commits reachable from \"HEAD\", but not reachable from\n> \"upstream\". \n\nMy comment was: why do we need this convenient explanation in the\ndescription, yet 'disallow' it as a method of actually indicating that\nvery range?\n\nAlso log will list all those commits, while the command just wants the\n`^start end` commits (equiv: `start..end`), even if rebase (as I'd\nunderstand it) wouldn't want the (^)not notation.\n\n> If you want to rebase this range and copy it onto newbase,\n> you'd run\n>\n> git rebase --onto newbase upstream\n\nHere `newbase` would be my 'upstream', while `upstream` is the\n'oldstream' (much hilarity and confusion...). I already have an\n`upstream` set for the branch, but it's not where it needs transplanting\nto in this case [That's because the Git for Windows branches are moving\ntargets as Git itself moves beneath it and dependent patches could be\nanywhere! I have a choice of about 5 'onto' locations depending on where\nthe precursor patches are located..] .\n\n>\n> This will take the commits upstream..HEAD (the HEAD argument is\n> implicit), and you end up with\n>\n> newbase-.....-HEAD\n>\n> containing all commits from (the previous) \"HEAD\" up to (but\n> excluding) \"upstream\". If \"newbase\" and \"upstream\" are identical, the\n> command can be simplified to `git rebase newbase`.\n>\n> Maybe I'm misunderstanding the problem? Can you give an example of\n> `git rebase --onto newbase upstream branch` not working as expected?\n\nIn summary, there are two aspect:\n- first, being able to use a common short-form within the command, and\n- second, that the documentation's description includes rather too many\ntricky concepts to properly understand all the ramifications, leaving me\nto think \"why can't I just say `git rebase --onto here old..end` or `git\nrebase --onto here start^..end` ? \"\n\nIn some-ways it feels the same as the current `git pull` discussion\nwhere historical workflow practices are baked in to the otherwise\nworkflow-agnostic git command structure.\n\nregards\n\nPhilip\n>\n> Regards\n> Daniel\n>\n> On Wed, Jul 28, 2021 at 5:38 PM Philip Oakley wrote:\n>> Is there a reasonable way to use the two-dot range notation in git\n>> rebase, particularly in an --onto situation?\n>>\n>> In my case I have a short series that depends on both some existing Git\n>> for Windows (GfW) patches (`main` branch), and some patches now in\n>> `git/master`. I'm now able to rebase it onto the GfW `shears/master`\n>> branch which contains both sets of patches (and one that was in the last\n>> git release).\n>>\n>> It felt that it ought to be possible to use a simple two dot range to\n>> extract my series, rather than identifying the individual end points in\n>> a similar manner to that used in the description\"set of commits .. shown\n>> by `git log ..HEAD`\".\n>>\n>> Or is this something that could be a project?\n>> --\n>>\n>> Philip\n>>\n>>\n>\n\n"},{"id":"431474","messageId":"YQKBNXsMdroX3DfY@coredump.intra.peff.net","threadId":"56174","inReplyTo":"dc7668ff-37ad-1d9e-fc92-df432549b4e2@iee.email","subject":"Re: Using two-dot range notation in `git rebase`?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-07-29T10:21:41Z","receivedAt":"2021-07-29T10:21:49Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jul 29, 2021 at 10:58:15AM +0100, Philip Oakley wrote:\n\n> In summary, there are two aspect:\n> - first, being able to use a common short-form within the command, and\n> - second, that the documentation's description includes rather too many\n> tricky concepts to properly understand all the ramifications, leaving me\n> to think \"why can't I just say `git rebase --onto here old..end` or `git\n> rebase --onto here start^..end` ? \"\n\nI do think \"git rebase --onto here old..end\" is a sensible thing to ask\nfor. If we were designing it today, I'd probably suggest that rebase\ntake arbitrary revision sets (and either require \"--onto\", or perhaps as\nlong as there is only one negative tip given, that becomes the \"--onto\"\npoint).\n\nIt might be possible to migrate to such a syntax, but we'd have to be\ncareful of ambiguities with the current syntax. It might be possible to\ninfer the intended use based on the presence or absence of negative tips\n(so \"git rebase foo bar\" must be \"foo is the upstream, and therefore\nbase branch\", whereas \"git rebase foo..bar\" is a range, though the two\nwould do the same thing).\n\nI think we did something similar with cherry-pick, which originally took\nonly a series of single commits.\n\nI admit that I haven't thought carefully through the details, though.\nThere may be some gotchas in how \"rebase\" treats the base branch.\n\n-Peff\n"},{"id":"431483","messageId":"1d730e32-a41e-73a6-5f20-70a652a9f6a2@iee.email","threadId":"56174","inReplyTo":"YQKBNXsMdroX3DfY@coredump.intra.peff.net","subject":"Re: Using two-dot range notation in `git rebase`?","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-07-29T14:11:43Z","receivedAt":"2021-07-29T14:13:16Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 29/07/2021 11:21, Jeff King wrote:\n> On Thu, Jul 29, 2021 at 10:58:15AM +0100, Philip Oakley wrote:\n>\n>> In summary, there are two aspect:\n>> - first, being able to use a common short-form within the command, and\n>> - second, that the documentation's description includes rather too many\n>> tricky concepts to properly understand all the ramifications, leaving me\n>> to think \"why can't I just say `git rebase --onto here old..end` or `git\n>> rebase --onto here start^..end` ? \"\n> I do think \"git rebase --onto here old..end\" is a sensible thing to ask\n> for. If we were designing it today, I'd probably suggest that rebase\n> take arbitrary revision sets (and either require \"--onto\", or perhaps as\n> long as there is only one negative tip given, that becomes the \"--onto\"\n> point).\n\nSensible.\n>\n> It might be possible to migrate to such a syntax, but we'd have to be\n> careful of ambiguities with the current syntax. It might be possible to\n> infer the intended use based on the presence or absence of negative tips\n\nMy first though was to limit it to just the double-dot itself (rather\nthan waiting for it's conversion to using the negative ref notation),\nbut that may be at the wrong part of the command line decoding.\n\n> (so \"git rebase foo bar\" must be \"foo is the upstream, and therefore\n> base branch\", whereas \"git rebase foo..bar\" is a range, though the two\n> would do the same thing).\n>\n> I think we did something similar with cherry-pick, which originally took\n> only a series of single commits.\n>\n> I admit that I haven't thought carefully through the details, though.\n> There may be some gotchas in how \"rebase\" treats the base branch.\n\nMy main issue (beyond the nice to have) is simply decoding all of the\ndocumentation's terminology, which starts complex, and stays pretty\ncomplicated... It is rather easy to mess up.\n\nPhilip\n"},{"id":"431497","messageId":"xmqqv94t59oq.fsf@gitster.g","threadId":"56174","inReplyTo":"YQKBNXsMdroX3DfY@coredump.intra.peff.net","subject":"Re: Using two-dot range notation in `git rebase`?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-07-29T17:09:09Z","receivedAt":"2021-07-29T17:09:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I do think \"git rebase --onto here old..end\" is a sensible thing to ask\n> for. If we were designing it today, I'd probably suggest that rebase\n> take arbitrary revision sets (and either require \"--onto\", or perhaps as\n> long as there is only one negative tip given, that becomes the \"--onto\"\n> point).\n\nThe unfortunate origin of \"rebase\" makes this a bit awkward. If it\nwere a tool to cherry-pick multiple commits on top of the current\ncommit (\"on arbitrary point\" is trivially implemented by first\nchecking that point out and make it cuttent), the range notation\nwould have made a lot more sense, and I think it indeed is what the\nmulti-pick kind of \"git cherry-pick\" today does.\n\nBut \"rebase\" is a tool to \"rebase a branch\", and it is done by\nreplaying the history leading to the tip of a given branch (the one\nthat is currently checked out being the default) on top of another\ncommit. So its parameters serve dual purpose---which part of the\ncommit DAG to take commits to be replayed from *and* which branch\nwill be used to point at the tip of the resulting rewritten history.\n\nIf you can forget the latter, then multi-pick cherry-pick is already\nthere [*1*].\n\nBefore revision.c API was extended to learn rev_cmdline_info, taking\nan \"extended SHA-1\" expression (e.g. A..B~2) from the user, and\nensuring there is only one positive tip and it is given as a branch\nname was simply too cumbersome and error prone. I do not offhand\nknow the current rev_cmdline_info is sufficiently rich to allow us\ndo so.\n\nFor the simplest \"git rebase [--onto newbase] oldbase..tip\", I do\nnot think it is such a big deal to type it with .. replaced with a\nsingle SP, so I do not necessarily agree with you that it is a\nsensible thing to ask for.\n\n[Footnote]\n\n*1* There is an issue in multi-pick \"git cherry-pick\" that I cannot\n replace my daily use of \"git rebase\" with it. It does not honor\n notes rewriting and I lose the notes/amlog records. This is\n unfortunately by design (for the same reason why the \"-x\" option\n lost its default status from cherry-pick, the tool tries to\n dissociate the resulting commit as much from the original commit\n as possible, and carrying forward notes attached to the original\n to the rewritten goes against that spirit).\n\n"},{"id":"431498","messageId":"xmqqr1fh59go.fsf@gitster.g","threadId":"56174","inReplyTo":"YQKBNXsMdroX3DfY@coredump.intra.peff.net","subject":"Re: Using two-dot range notation in `git rebase`?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-07-29T17:13:59Z","receivedAt":"2021-07-29T17:14:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> long as there is only one negative tip given, that becomes the \"--onto\"\n> point).\n\nSo \"git newbase [--options] A..B\" would\n\n - checks if B names an existing branch or just a commit\n\n - detaches HEAD at commit A\n\n - replays commits in DAG A..B on top of it; the exact way the\n history is replayed is affected by the options given (e.g. \"-m\"\n and \"-p\" may try to preserve history shapes)\n\n - if B was determined to be a branch name, \"git branch -f\" to it;\n otherwise leave the HEAD detached.\n\nwhich all sounds OK, but I do not see a huge improvement over the\ncurrent \"git rebase [--options] A B\" (other than that you can type\ndouble dot instead of a single space).\n"},{"id":"431502","messageId":"YQLldzh5OEY+mPLY@coredump.intra.peff.net","threadId":"56174","inReplyTo":"xmqqr1fh59go.fsf@gitster.g","subject":"Re: Using two-dot range notation in `git rebase`?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-07-29T17:29:27Z","receivedAt":"2021-07-29T17:29:30Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jul 29, 2021 at 10:13:59AM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > long as there is only one negative tip given, that becomes the \"--onto\"\n> > point).\n> \n> So \"git newbase [--options] A..B\" would\n> \n> - checks if B names an existing branch or just a commit\n> \n> - detaches HEAD at commit A\n> \n> - replays commits in DAG A..B on top of it; the exact way the\n> history is replayed is affected by the options given (e.g. \"-m\"\n> and \"-p\" may try to preserve history shapes)\n> \n> - if B was determined to be a branch name, \"git branch -f\" to it;\n> otherwise leave the HEAD detached.\n> \n> which all sounds OK, but I do not see a huge improvement over the\n> current \"git rebase [--options] A B\" (other than that you can type\n> double dot instead of a single space).\n\nYeah, I don't see it as a huge benefit either.\n\nPotentially it opens the door for stuff like:\n\n git rebase ^A B C D\n\nbut I am not sure if that is helpful or horrifying. ;)\n\n(To be clear, I am not necessarily advocating any of this, but just\nthinking aloud of possibilities. And I'm definitely not planning to work\non it myself.)\n\n-Peff\n"},{"id":"431504","messageId":"87fsvxx7n8.fsf@osv.gnss.ru","threadId":"56174","inReplyTo":"xmqqv94t59oq.fsf@gitster.g","subject":"Re: Using two-dot range notation in `git rebase`?","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2021-07-29T19:05:47Z","receivedAt":"2021-07-29T19:05:54Z","isPatch":false,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"Junio C Hamano writes:\n\n> Jeff King writes:\n>\n>> I do think \"git rebase --onto here old..end\" is a sensible thing to ask\n>> for. If we were designing it today, I'd probably suggest that rebase\n>> take arbitrary revision sets (and either require \"--onto\", or perhaps as\n>> long as there is only one negative tip given, that becomes the \"--onto\"\n>> point).\n>\n> The unfortunate origin of \"rebase\" makes this a bit awkward. If it\n> were a tool to cherry-pick multiple commits on top of the current\n> commit (\"on arbitrary point\" is trivially implemented by first\n> checking that point out and make it cuttent), the range notation\n> would have made a lot more sense, and I think it indeed is what the\n> multi-pick kind of \"git cherry-pick\" today does.\n>\n> But \"rebase\" is a tool to \"rebase a branch\", and it is done by\n> replaying the history leading to the tip of a given branch (the one\n> that is currently checked out being the default) on top of another\n> commit. So its parameters serve dual purpose---which part of the\n> commit DAG to take commits to be replayed from *and* which branch\n> will be used to point at the tip of the resulting rewritten history.\n>\n> If you can forget the latter, then multi-pick cherry-pick is already\n> there [*1*].\n\nTo me it seems like the long-term way to go is to obsolete cherry-pick\nas end-user interface in favor of something like \"git rebase --pick\", to\nstop repeating the same functionality in both \"rebase\" and\n\"cherry-pick\". Besides, the two-dot notation would fit nicely then.\n\n\"Take these commits and put them there\" (= current rebase) and \"take\nthose commits and put them here\" (= current cherry-pick) are similar\nenough to be handled by the same command with the same set of features.\n\nThanks,\n-- \nSergey Organov\n"},{"id":"431513","messageId":"xmqq5yws6hjv.fsf@gitster.g","threadId":"56174","inReplyTo":"YQLldzh5OEY+mPLY@coredump.intra.peff.net","subject":"Re: Using two-dot range notation in `git rebase`?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-07-29T19:33:56Z","receivedAt":"2021-07-29T19:34:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Potentially it opens the door for stuff like:\n>\n> git rebase ^A B C D\n>\n> but I am not sure if that is helpful or horrifying. ;)\n\nIt is the \"you might be forgetting that 'rebase' is a tool to rebase\na single branch, and is not a tool to replay a history on a commit\"\nexample.\n\nThe \"multi-pick\" variant of \"git cherry-pick\" probably has a lot\nmore affinity with the idea of specifying general sub-graph of\nhistory to be replayed, expressed in the \"externded SHA-1\" syntax, I\nwould think.\n\nThanks.\n"}]}