{"thread":{"id":"21903","subject":"[PATCH RFC] rebase: add --revisions flag","startedAt":"2009-12-08T14:47:42Z","lastAt":"2009-12-13T22:47:04Z","messageCount":43,"participants":["Michael S. Tsirkin","Björn Steinbrink","Junio C Hamano","Sverre Rabbelier","Miles Bader","Christian Couder","Peter Krefting","Matthieu Moy","Andreas Schwab","David Kågedal"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"129547","messageId":"20091208144740.GA30830@redhat.com","threadId":"21903","inReplyTo":null,"subject":"[PATCH RFC] rebase: add --revisions flag","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2009-12-08T14:47:42Z","receivedAt":"2009-12-08T14:47:42Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"Add --revisions flag to rebase, so that it can be used\nto apply an arbitrary range of commits on top\nof a current branch.\n\nSigned-off-by: Michael S. Tsirkin \n---\n\nI've been wishing for this functionality for a while now,\nso here goes. This isn't yet properly documented and I didn't\nwrite a test, but the patch seems to work fine for me.\nAny early flames/feedback?\n\n\n git-rebase.sh | 36 ++++++++++++++++++++++++------------\n 1 files changed, 24 insertions(+), 12 deletions(-)\n\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex b121f45..d99d04b 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -3,12 +3,13 @@\n # Copyright (c) 2005 Junio C Hamano.\n #\n \n-USAGE='[--interactive | -i] [-v] [--force-rebase | -f] [--onto ] [|--root] [] [--quiet | -q]'\n+USAGE='[--interactive | -i] [-v] [--force-rebase | -f] [--onto ] [--revisions ] [|--root] [] [--quiet | -q]'\n LONG_USAGE='git-rebase replaces with a new branch of the\n same name. When the --onto option is provided the new branch starts\n out with a HEAD equal to , otherwise it is equal to \n It then attempts to create a new commit for each commit from the original\n- that does not exist in the branch.\n+ that does not exist in the branch, or for\n+each commit matching when the --revisions options is provided.\n \n It is possible that a merge failure will prevent this process from being\n completely automatic. You will have to resolve any such merge failure\n@@ -41,6 +42,7 @@ If you would prefer to skip this patch, instead run \\\"git rebase --skip\\\".\n To restore the original branch and stop rebasing run \\\"git rebase --abort\\\".\n \"\n unset newbase\n+unset revisions\n strategy=recursive\n do_merge=\n dotest=\"$GIT_DIR\"/rebase-merge\n@@ -291,6 +293,11 @@ do\n \t\tnewbase=\"$2\"\n \t\tshift\n \t\t;;\n+\t--revisions)\n+\t\ttest 2 -le \"$#\" || usage\n+\t\trevisions=\"$2\"\n+\t\tshift\n+\t\t;;\n \t-M|-m|--m|--me|--mer|--merg|--merge)\n \t\tdo_merge=t\n \t\t;;\n@@ -459,12 +466,24 @@ case \"$#\" in\n esac\n orig_head=$branch\n \n+if test -z \"$revisions\"\n+then\n+\tif test -n \"$rebase_root\"\n+\tthen\n+\t\trevisions=\"$onto..$orig_head\"\n+\telse\n+\t\trevisions=\"$upstream..$orig_head\"\n+\tfi\n+\tmb=$(git merge-base \"$onto\" \"$branch\")\n+else\n+\tmb=\"\"\n+fi\n+\n # Now we are rebasing commits $upstream..$branch (or with --root,\n # everything leading up to $branch) on top of $onto\n \n # Check if we are already based on $onto with linear history,\n # but this should be done only when upstream and onto are the same.\n-mb=$(git merge-base \"$onto\" \"$branch\")\n if test \"$upstream\" = \"$onto\" && test \"$mb\" = \"$onto\" &&\n \t# linear history?\n \t! (git rev-list --parents \"$onto\"..\"$branch\" | sane_grep \" .* \") > /dev/null\n@@ -489,10 +508,10 @@ if test -n \"$diffstat\"\n then\n \tif test -n \"$verbose\"\n \tthen\n-\t\techo \"Changes from $mb to $onto:\"\n+\t\techo \"Changes $revisions:\"\n \tfi\n \t# We want color (if set), but no pager\n-\tGIT_PAGER='' git diff --stat --summary \"$mb\" \"$onto\"\n+\tGIT_PAGER='' git diff --stat --summary \"$revisions\"\n fi\n \n # If the $onto is a proper descendant of the tip of the branch, then\n@@ -504,13 +523,6 @@ then\n \texit 0\n fi\n \n-if test -n \"$rebase_root\"\n-then\n-\trevisions=\"$onto..$orig_head\"\n-else\n-\trevisions=\"$upstream..$orig_head\"\n-fi\n-\n if test -z \"$do_merge\"\n then\n \tgit format-patch -k --stdout --full-index --ignore-if-in-upstream \\\n-- \n1.6.6.rc1.43.gf55cc\n"},{"id":"129554","messageId":"20091208160822.GA1299@atjola.homenet","threadId":"21903","inReplyTo":"20091208144740.GA30830@redhat.com","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-12-08T16:08:22Z","receivedAt":"2009-12-08T16:08:22Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.12.08 16:47:42 +0200, Michael S. Tsirkin wrote:\n> Add --revisions flag to rebase, so that it can be used\n> to apply an arbitrary range of commits on top\n> of a current branch.\n> \n> Signed-off-by: Michael S. Tsirkin \n> ---\n> \n> I've been wishing for this functionality for a while now,\n> so here goes. This isn't yet properly documented and I didn't\n> write a test, but the patch seems to work fine for me.\n> Any early flames/feedback?\n\nThis pretty much reverses what rebase normally does. Instead of \"rebase\nthis onto that\" it's \"'rebase' that onto this\". And instead of updating\nthe branch head that got rebased, the, uhm, \"upstream\" gets updated.\n\nAlso, AFAICT this needs to be called like this:\ngit rebase --revisions foo..bar HEAD\n\nChanging the meaning of the argument and relying on the fact\nthat defaults to . If such a thing gets added, it\nshould rather work like --root, not using at all, but --onto\n only. Maybe defaulting to HEAD for and making --onto\noptional, as it's reversed WRT what it does compared to the usual\nrebase.\n\nBut generally, I'd say it would be better to add such a range feature to\ncherry-pick than abusing rebase for that.\n\nBjörn\n"},{"id":"129555","messageId":"20091208161142.GA32045@redhat.com","threadId":"21903","inReplyTo":"20091208160822.GA1299@atjola.homenet","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2009-12-08T16:11:44Z","receivedAt":"2009-12-08T16:11:44Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Tue, Dec 08, 2009 at 05:08:22PM +0100, Björn Steinbrink wrote:\n> On 2009.12.08 16:47:42 +0200, Michael S. Tsirkin wrote:\n> > Add --revisions flag to rebase, so that it can be used\n> > to apply an arbitrary range of commits on top\n> > of a current branch.\n> > \n> > Signed-off-by: Michael S. Tsirkin \n> > ---\n> > \n> > I've been wishing for this functionality for a while now,\n> > so here goes. This isn't yet properly documented and I didn't\n> > write a test, but the patch seems to work fine for me.\n> > Any early flames/feedback?\n> \n> This pretty much reverses what rebase normally does. Instead of \"rebase\n> this onto that\" it's \"'rebase' that onto this\". And instead of updating\n> the branch head that got rebased, the, uhm, \"upstream\" gets updated.\n> \n> Also, AFAICT this needs to be called like this:\n> git rebase --revisions foo..bar HEAD\n> \n> Changing the meaning of the argument and relying on the fact\n> that defaults to . If such a thing gets added, it\n> should rather work like --root, not using at all, but --onto\n> only. Maybe defaulting to HEAD for and making --onto\n> optional, as it's reversed WRT what it does compared to the usual\n> rebase.\n\nSorry, I had trouble parsing the above. Could you suggest e.g. how the\nhelp line should look?\n\n> But generally, I'd say it would be better to add such a range feature to\n> cherry-pick than abusing rebase for that.\n> \n> Björn\n\nThe reason to use rebase is that I often want to combine\nthis with -i flag, editing patches as they are applied.\n\n-- \nMST\n"},{"id":"129556","messageId":"20091208161406.GB32045@redhat.com","threadId":"21903","inReplyTo":"20091208160822.GA1299@atjola.homenet","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2009-12-08T16:14:07Z","receivedAt":"2009-12-08T16:14:07Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Tue, Dec 08, 2009 at 05:08:22PM +0100, Björn Steinbrink wrote:\n> On 2009.12.08 16:47:42 +0200, Michael S. Tsirkin wrote:\n> > Add --revisions flag to rebase, so that it can be used\n> > to apply an arbitrary range of commits on top\n> > of a current branch.\n> > \n> > Signed-off-by: Michael S. Tsirkin \n> > ---\n> > \n> > I've been wishing for this functionality for a while now,\n> > so here goes. This isn't yet properly documented and I didn't\n> > write a test, but the patch seems to work fine for me.\n> > Any early flames/feedback?\n> \n> This pretty much reverses what rebase normally does. Instead of \"rebase\n> this onto that\" it's \"'rebase' that onto this\". And instead of updating\n> the branch head that got rebased, the, uhm, \"upstream\" gets updated.\n\nThe last sentence is wrong I think - it is still the branch head that\nis updated.\n"},{"id":"129563","messageId":"20091208163737.GA2005@atjola.homenet","threadId":"21903","inReplyTo":"20091208161406.GB32045@redhat.com","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-12-08T16:37:37Z","receivedAt":"2009-12-08T16:37:37Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.12.08 18:14:07 +0200, Michael S. Tsirkin wrote:\n> On Tue, Dec 08, 2009 at 05:08:22PM +0100, Björn Steinbrink wrote:\n> > On 2009.12.08 16:47:42 +0200, Michael S. Tsirkin wrote:\n> > > Add --revisions flag to rebase, so that it can be used\n> > > to apply an arbitrary range of commits on top\n> > > of a current branch.\n> > > \n> > > Signed-off-by: Michael S. Tsirkin \n> > > ---\n> > > \n> > > I've been wishing for this functionality for a while now,\n> > > so here goes. This isn't yet properly documented and I didn't\n> > > write a test, but the patch seems to work fine for me.\n> > > Any early flames/feedback?\n> > \n> > This pretty much reverses what rebase normally does. Instead of \"rebase\n> > this onto that\" it's \"'rebase' that onto this\". And instead of updating\n> > the branch head that got rebased, the, uhm, \"upstream\" gets updated.\n> \n> The last sentence is wrong I think - it is still the branch head that\n> is updated.\n\nBut you don't rebase the branch head. Before the rebase, the branch head\ndoesn't reference the commits that get rebased. For example:\n\ngit checkout bar\ngit rebase --revisions foo bar\n\nYou \"rebase\" the commits in foo's history, but you update bar.\n\nWRT the result, the above command should be equivalent to:\ngit checkout bar\ngit reset --hard foo\ngit rebase --root --onto ORIG_HEAD;\n\nAnd here, the commits currently reachable through \"bar\" are rebased, and\n\"bar\" also gets updated.\n\nBjörn\n"},{"id":"129558","messageId":"20091208164113.GB2005@atjola.homenet","threadId":"21903","inReplyTo":"20091208161142.GA32045@redhat.com","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-12-08T16:41:13Z","receivedAt":"2009-12-08T16:41:13Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.12.08 18:11:44 +0200, Michael S. Tsirkin wrote:\n> On Tue, Dec 08, 2009 at 05:08:22PM +0100, Björn Steinbrink wrote:\n> > On 2009.12.08 16:47:42 +0200, Michael S. Tsirkin wrote:\n> > > Add --revisions flag to rebase, so that it can be used\n> > > to apply an arbitrary range of commits on top\n> > > of a current branch.\n> > > \n> > > Signed-off-by: Michael S. Tsirkin \n> > > ---\n> > > \n> > > I've been wishing for this functionality for a while now,\n> > > so here goes. This isn't yet properly documented and I didn't\n> > > write a test, but the patch seems to work fine for me.\n> > > Any early flames/feedback?\n> > \n> > This pretty much reverses what rebase normally does. Instead of \"rebase\n> > this onto that\" it's \"'rebase' that onto this\". And instead of updating\n> > the branch head that got rebased, the, uhm, \"upstream\" gets updated.\n> > \n> > Also, AFAICT this needs to be called like this:\n> > git rebase --revisions foo..bar HEAD\n> > \n> > Changing the meaning of the argument and relying on the fact\n> > that defaults to . If such a thing gets added, it\n> > should rather work like --root, not using at all, but --onto\n> > only. Maybe defaulting to HEAD for and making --onto\n> > optional, as it's reversed WRT what it does compared to the usual\n> > rebase.\n> \n> Sorry, I had trouble parsing the above. Could you suggest e.g. how the\n> help line should look?\n\nCurrent:\ngit rebase [-i | --interactive] [options] [--onto ]\n\t []\ngit rebase [-i | --interactive] [options] --onto \n\t--root []\n\nAdd:\ngit rebase [-i | --interactive] [options] --revisions []\n\n(Thinking about it, I guess an explicit --onto makes no sense with the\n--revisions flag)\n\n> > But generally, I'd say it would be better to add such a range feature to\n> > cherry-pick than abusing rebase for that.\n> \n> The reason to use rebase is that I often want to combine\n> this with -i flag, editing patches as they are applied.\n\nHm, well, your patch didn't touch git-rebase--interactive.sh ;-)\n\nBjörn\n"},{"id":"129559","messageId":"20091208164449.GA32204@redhat.com","threadId":"21903","inReplyTo":"20091208163737.GA2005@atjola.homenet","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2009-12-08T16:44:49Z","receivedAt":"2009-12-08T16:44:49Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Tue, Dec 08, 2009 at 05:37:37PM +0100, Björn Steinbrink wrote:\n> On 2009.12.08 18:14:07 +0200, Michael S. Tsirkin wrote:\n> > On Tue, Dec 08, 2009 at 05:08:22PM +0100, Björn Steinbrink wrote:\n> > > On 2009.12.08 16:47:42 +0200, Michael S. Tsirkin wrote:\n> > > > Add --revisions flag to rebase, so that it can be used\n> > > > to apply an arbitrary range of commits on top\n> > > > of a current branch.\n> > > > \n> > > > Signed-off-by: Michael S. Tsirkin \n> > > > ---\n> > > > \n> > > > I've been wishing for this functionality for a while now,\n> > > > so here goes. This isn't yet properly documented and I didn't\n> > > > write a test, but the patch seems to work fine for me.\n> > > > Any early flames/feedback?\n> > > \n> > > This pretty much reverses what rebase normally does. Instead of \"rebase\n> > > this onto that\" it's \"'rebase' that onto this\". And instead of updating\n> > > the branch head that got rebased, the, uhm, \"upstream\" gets updated.\n> > \n> > The last sentence is wrong I think - it is still the branch head that\n> > is updated.\n> \n> But you don't rebase the branch head. Before the rebase, the branch head\n> doesn't reference the commits that get rebased. For example:\n> \n> git checkout bar\n> git rebase --revisions foo bar\n> \n> You \"rebase\" the commits in foo's history, but you update bar.\n\nYes, that's the who point of the patch. The above applies a single\ncommit, foo, on top of current branch bar.\n\n> WRT the result, the above command should be equivalent to:\n> git checkout bar\n> git reset --hard foo\n> git rebase --root --onto ORIG_HEAD;\n> \n> And here, the commits currently reachable through \"bar\" are rebased, and\n> \"bar\" also gets updated.\n> \n> Björn\n\nSo this \n1. won't be very useful, as you show it is easy\n to achieve with existing commands.\n2. interprets \"foo\" as branch name as opposed to\n revision range.\n\nOTOH, rebase --revisions as I implemented is a \"smarter cherry-pick\" which\ncan't easily be achieved with existing commands, especially if you add\n\"-i\".\n\n\n-- \nMST\n"},{"id":"129560","messageId":"20091208164904.GB32204@redhat.com","threadId":"21903","inReplyTo":"20091208164113.GB2005@atjola.homenet","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2009-12-08T16:49:04Z","receivedAt":"2009-12-08T16:49:04Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Tue, Dec 08, 2009 at 05:41:13PM +0100, Björn Steinbrink wrote:\n> On 2009.12.08 18:11:44 +0200, Michael S. Tsirkin wrote:\n> > On Tue, Dec 08, 2009 at 05:08:22PM +0100, Björn Steinbrink wrote:\n> > > On 2009.12.08 16:47:42 +0200, Michael S. Tsirkin wrote:\n> > > > Add --revisions flag to rebase, so that it can be used\n> > > > to apply an arbitrary range of commits on top\n> > > > of a current branch.\n> > > > \n> > > > Signed-off-by: Michael S. Tsirkin \n> > > > ---\n> > > > \n> > > > I've been wishing for this functionality for a while now,\n> > > > so here goes. This isn't yet properly documented and I didn't\n> > > > write a test, but the patch seems to work fine for me.\n> > > > Any early flames/feedback?\n> > > \n> > > This pretty much reverses what rebase normally does. Instead of \"rebase\n> > > this onto that\" it's \"'rebase' that onto this\". And instead of updating\n> > > the branch head that got rebased, the, uhm, \"upstream\" gets updated.\n> > > \n> > > Also, AFAICT this needs to be called like this:\n> > > git rebase --revisions foo..bar HEAD\n> > > \n> > > Changing the meaning of the argument and relying on the fact\n> > > that defaults to . If such a thing gets added, it\n> > > should rather work like --root, not using at all, but --onto\n> > > only. Maybe defaulting to HEAD for and making --onto\n> > > optional, as it's reversed WRT what it does compared to the usual\n> > > rebase.\n> > \n> > Sorry, I had trouble parsing the above. Could you suggest e.g. how the\n> > help line should look?\n> \n> Current:\n> git rebase [-i | --interactive] [options] [--onto ]\n> \t []\n> git rebase [-i | --interactive] [options] --onto \n> \t--root []\n> \n> Add:\n> git rebase [-i | --interactive] [options] --revisions []\n> \n> (Thinking about it, I guess an explicit --onto makes no sense with the\n> --revisions flag)\n\nI agree.\nSo this is different from what I implemented basically only in that\nwe should disallow combining --onto with --revisions. Right?\n\n> > > But generally, I'd say it would be better to add such a range feature to\n> > > cherry-pick than abusing rebase for that.\n> > \n> > The reason to use rebase is that I often want to combine\n> > this with -i flag, editing patches as they are applied.\n> \n> Hm, well, your patch didn't touch git-rebase--interactive.sh ;-)\n> \n> Björn\n\nAh, I was wondering why it doesn't work :)\n"},{"id":"129567","messageId":"20091208191107.GA4103@atjola.homenet","threadId":"21903","inReplyTo":"20091208164449.GA32204@redhat.com","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-12-08T19:11:07Z","receivedAt":"2009-12-08T19:11:07Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.12.08 18:44:49 +0200, Michael S. Tsirkin wrote:\n> On Tue, Dec 08, 2009 at 05:37:37PM +0100, Björn Steinbrink wrote:\n> > On 2009.12.08 18:14:07 +0200, Michael S. Tsirkin wrote:\n> > > On Tue, Dec 08, 2009 at 05:08:22PM +0100, Björn Steinbrink wrote:\n> > > > On 2009.12.08 16:47:42 +0200, Michael S. Tsirkin wrote:\n> > > > > Add --revisions flag to rebase, so that it can be used\n> > > > > to apply an arbitrary range of commits on top\n> > > > > of a current branch.\n> > > > > \n> > > > > Signed-off-by: Michael S. Tsirkin \n> > > > > ---\n> > > > > \n> > > > > I've been wishing for this functionality for a while now,\n> > > > > so here goes. This isn't yet properly documented and I didn't\n> > > > > write a test, but the patch seems to work fine for me.\n> > > > > Any early flames/feedback?\n> > > > \n> > > > This pretty much reverses what rebase normally does. Instead of \"rebase\n> > > > this onto that\" it's \"'rebase' that onto this\". And instead of updating\n> > > > the branch head that got rebased, the, uhm, \"upstream\" gets updated.\n> > > \n> > > The last sentence is wrong I think - it is still the branch head that\n> > > is updated.\n> > \n> > But you don't rebase the branch head. Before the rebase, the branch head\n> > doesn't reference the commits that get rebased. For example:\n> > \n> > git checkout bar\n> > git rebase --revisions foo bar\n> > \n> > You \"rebase\" the commits in foo's history, but you update bar.\n> \n> Yes, that's the who point of the patch.\n\nYes, and it's \"backwards\" compared to the existing \"rebase\" modes, but\nmore like \"cherry-pick\".\n\n> The above applies a single commit, foo, on top of current branch bar.\n\nHm, no. I expected it to turn all commits reachable from foo into\npatches and applying them to bar. But actually, that should hit the\nspecial mode of format-patch. So\ngit rebase --revisions foo bar\nis (with your patch) actually the same as\ngit rebase foo bar\n\nSo actually the example should have been:\ngit rebase --root --revisions foo bar\n\nBoth invocations probably mess up the diff-stat as that becomes:\ngit diff --stat --summary foo\nSo it creates a diffstat of the diff from the working tree to \"foo\",\nwhich can't be right.\n\n> \n> > WRT the result, the above command should be equivalent to:\n> > git checkout bar\n> > git reset --hard foo\n> > git rebase --root --onto ORIG_HEAD;\n> > \n> > And here, the commits currently reachable through \"bar\" are rebased, and\n> > \"bar\" also gets updated.\n> \n> So this \n> 1. won't be very useful, as you show it is easy\n> to achieve with existing commands.\n\nOne can \"almost\" achieve it.\ngit rebase --revision A..B foo\n\nis about the same as:\ngit checkout foo\ngit reset --hard B\ngit rebase --onto ORIG_HEAD A\n\nBut:\na) The \"reset --hard\" obviously lacks the safety checks for clean\nindex/working tree.\nb) \"git rebase --abort\" won't take you back to your initial state, but\nto B.\nc) It's not really obvious that you can do it and how to do it.\n\nAnother possibility would be:\n\ngit checkout B^0 # detach HEAD at B\ngit rebase foo # rebase onto foo\ngit checkout foo \ngit merge HEAD@{1} # Fast-forwards foo to the rebased stuff\n\nThat fixes a), avoid b) [because you don't mess up any branch head\nearly] but is still subject to c).\n\nAnd for both methods, the ORIG_HEAD and HEAD@{1} arguments are somewhat\n\"unstable\", e.g. checking out the wrong branch head first, and only then\nthe correct one, you'd have to use HEAD@{2} instead of HEAD@{1} (because\nthe reflog for HEAD got a new entry).\n\nSo you can already do what you want to do, but wrapping it in a single\nporcelain might still be useful because it's obviously a lot easier and\nsafer that way. That said, I wonder what kind of workflow you're using\nthough, and why you require that feature. I've never needed something\nlike that.\n\n> 2. interprets \"foo\" as branch name as opposed to\n> revision range.\n\nWell, a single committish is a \"range\" as far as the range-based\ncommands are concerned, e.g. \"git log master\" treats \"master\" to mean\nall commits reachable it. If \"rebase --revisions master\" would do the\nsame, that's at least consistent (and for single commit picks, there's\nalready cherry-pick). The problem with your patch is that it passes the\nrevision argument to format-patch as is, and:\ngit format-patch foo\nis the same as\ngit format-patch foo..HEAD\n\n\n> OTOH, rebase --revisions as I implemented is a \"smarter cherry-pick\"\n> which can't easily be achieved with existing commands, especially if\n> you add \"-i\".\n\nAnd that \"is a 'smarter cherry-pick'\" is why I think that rebase is\nactually the wrong command to get that feature. While rebase internally\ndoes just mass-cherry-picking, it does that with commits in the current\nbranch onto a specified branch. The --revisions flag makes it do things\nthe other way around.\n\nBjörn\n"},{"id":"129568","messageId":"20091208191324.GA4200@atjola.homenet","threadId":"21903","inReplyTo":"20091208164904.GB32204@redhat.com","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-12-08T19:13:24Z","receivedAt":"2009-12-08T19:13:24Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.12.08 18:49:04 +0200, Michael S. Tsirkin wrote:\n> On Tue, Dec 08, 2009 at 05:41:13PM +0100, Björn Steinbrink wrote:\n> > > > Also, AFAICT this needs to be called like this:\n> > > > git rebase --revisions foo..bar HEAD\n> > > > \n> > > > Changing the meaning of the argument and relying on the fact\n> > > > that defaults to . If such a thing gets added, it\n> > > > should rather work like --root, not using at all, but --onto\n> > > > only. Maybe defaulting to HEAD for and making --onto\n> > > > optional, as it's reversed WRT what it does compared to the usual\n> > > > rebase.\n> > > \n> > > Sorry, I had trouble parsing the above. Could you suggest e.g. how the\n> > > help line should look?\n> > \n> > Current:\n> > git rebase [-i | --interactive] [options] [--onto ]\n> > \t []\n> > git rebase [-i | --interactive] [options] --onto \n> > \t--root []\n> > \n> > Add:\n> > git rebase [-i | --interactive] [options] --revisions []\n> > \n> > (Thinking about it, I guess an explicit --onto makes no sense with the\n> > --revisions flag)\n> \n> I agree.\n> So this is different from what I implemented basically only in that\n> we should disallow combining --onto with --revisions. Right?\n\nIt also drops , because that makes no sense with --revisions.\nSo the only mandatory argument is the revision range.\n\nBjörn\n"},{"id":"129571","messageId":"20091208200017.GA827@redhat.com","threadId":"21903","inReplyTo":"20091208191107.GA4103@atjola.homenet","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2009-12-08T20:00:17Z","receivedAt":"2009-12-08T20:00:17Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Tue, Dec 08, 2009 at 08:11:07PM +0100, Björn Steinbrink wrote:\n> On 2009.12.08 18:44:49 +0200, Michael S. Tsirkin wrote:\n> > On Tue, Dec 08, 2009 at 05:37:37PM +0100, Björn Steinbrink wrote:\n> > > On 2009.12.08 18:14:07 +0200, Michael S. Tsirkin wrote:\n> > > > On Tue, Dec 08, 2009 at 05:08:22PM +0100, Björn Steinbrink wrote:\n> > > > > On 2009.12.08 16:47:42 +0200, Michael S. Tsirkin wrote:\n> > > > > > Add --revisions flag to rebase, so that it can be used\n> > > > > > to apply an arbitrary range of commits on top\n> > > > > > of a current branch.\n> > > > > > \n> > > > > > Signed-off-by: Michael S. Tsirkin \n> > > > > > ---\n> > > > > > \n> > > > > > I've been wishing for this functionality for a while now,\n> > > > > > so here goes. This isn't yet properly documented and I didn't\n> > > > > > write a test, but the patch seems to work fine for me.\n> > > > > > Any early flames/feedback?\n> > > > > \n> > > > > This pretty much reverses what rebase normally does. Instead of \"rebase\n> > > > > this onto that\" it's \"'rebase' that onto this\". And instead of updating\n> > > > > the branch head that got rebased, the, uhm, \"upstream\" gets updated.\n> > > > \n> > > > The last sentence is wrong I think - it is still the branch head that\n> > > > is updated.\n> > > \n> > > But you don't rebase the branch head. Before the rebase, the branch head\n> > > doesn't reference the commits that get rebased. For example:\n> > > \n> > > git checkout bar\n> > > git rebase --revisions foo bar\n> > > \n> > > You \"rebase\" the commits in foo's history, but you update bar.\n> > \n> > Yes, that's the who point of the patch.\n> \n> Yes, and it's \"backwards\" compared to the existing \"rebase\" modes, but\n> more like \"cherry-pick\".\n> \n> > The above applies a single commit, foo, on top of current branch bar.\n> \n> Hm, no. I expected it to turn all commits reachable from foo into\n> patches and applying them to bar. But actually, that should hit the\n> special mode of format-patch. So\n> git rebase --revisions foo bar\n> is (with your patch) actually the same as\n> git rebase foo bar\n> \n> So actually the example should have been:\n> git rebase --root --revisions foo bar\n> \n> Both invocations probably mess up the diff-stat as that becomes:\n> git diff --stat --summary foo\n> So it creates a diffstat of the diff from the working tree to \"foo\",\n> which can't be right.\n> \n> > \n> > > WRT the result, the above command should be equivalent to:\n> > > git checkout bar\n> > > git reset --hard foo\n> > > git rebase --root --onto ORIG_HEAD;\n> > > \n> > > And here, the commits currently reachable through \"bar\" are rebased, and\n> > > \"bar\" also gets updated.\n> > \n> > So this \n> > 1. won't be very useful, as you show it is easy\n> > to achieve with existing commands.\n> \n> One can \"almost\" achieve it.\n> git rebase --revision A..B foo\n> \n> is about the same as:\n> git checkout foo\n> git reset --hard B\n> git rebase --onto ORIG_HEAD A\n> \n> But:\n> a) The \"reset --hard\" obviously lacks the safety checks for clean\n> index/working tree.\n> b) \"git rebase --abort\" won't take you back to your initial state, but\n> to B.\n> c) It's not really obvious that you can do it and how to do it.\n> \n> Another possibility would be:\n> \n> git checkout B^0 # detach HEAD at B\n> git rebase foo # rebase onto foo\n> git checkout foo \n> git merge HEAD@{1} # Fast-forwards foo to the rebased stuff\n> \n> That fixes a), avoid b) [because you don't mess up any branch head\n> early] but is still subject to c).\n> \n> And for both methods, the ORIG_HEAD and HEAD@{1} arguments are somewhat\n> \"unstable\", e.g. checking out the wrong branch head first, and only then\n> the correct one, you'd have to use HEAD@{2} instead of HEAD@{1} (because\n> the reflog for HEAD got a new entry).\n> \n> So you can already do what you want to do, but wrapping it in a single\n> porcelain might still be useful because it's obviously a lot easier and\n> safer that way. That said, I wonder what kind of workflow you're using\n> though, and why you require that feature. I've never needed something\n> like that.\n\nI need this often for many reasons:\n-\tImagine developing a patchset with a complex bugfix on master branch.\n\tThen I decide to also apply (backport) this patchset to stable branch.\n-\tImagine developing a bugfix/feature patchset on master branch.\n\tThen I decide the patchset is too large/unsafe and want to\n\tswitch it to staging branch.\n-\tI have a large queue of patches on staging branch, I decide that\n\ta range of patches is mature enough for master.\n\nAnd I often need -i to inspec/edit patches while doing this,\neven though I can rebase -i later, but that would mean\nfiguring which commit to pass to rebase -i.\n\n> > 2. interprets \"foo\" as branch name as opposed to\n> > revision range.\n> \n> Well, a single committish is a \"range\" as far as the range-based\n> commands are concerned, e.g. \"git log master\" treats \"master\" to mean\n> all commits reachable it. If \"rebase --revisions master\" would do the\n> same, that's at least consistent (and for single commit picks, there's\n> already cherry-pick). The problem with your patch is that it passes the\n> revision argument to format-patch as is, and:\n> git format-patch foo\n> is the same as\n> git format-patch foo..HEAD\n> \n> \n> > OTOH, rebase --revisions as I implemented is a \"smarter cherry-pick\"\n> > which can't easily be achieved with existing commands, especially if\n> > you add \"-i\".\n> \n> And that \"is a 'smarter cherry-pick'\" is why I think that rebase is\n> actually the wrong command to get that feature. While rebase internally\n> does just mass-cherry-picking, it does that with commits in the current\n> branch onto a specified branch. The --revisions flag makes it do things\n> the other way around.\n> \n> Björn\n\nWell, implemenation-wise, teaching cherry-pick about multiple\ncommits seems very hard to me. We would need to teach it about\nall the flags that rebase has to patch queue management.\nSo I can't implement it. Can you?\n\n-- \nMST\n"},{"id":"129572","messageId":"7vfx7lcj18.fsf@alter.siamese.dyndns.org","threadId":"21903","inReplyTo":"20091208144740.GA30830@redhat.com","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-12-08T20:22:59Z","receivedAt":"2009-12-08T20:22:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Michael S. Tsirkin\" writes:\n\n> Add --revisions flag to rebase, so that it can be used\n> to apply an arbitrary range of commits on top\n> of a current branch.\n\nMany people wanted to have \"pick many commits onto the current HEAD\" and I\nthink it would be a natural, uncontroversial and welcome addition to allow\n\"git cherry-pick A..B\". In fact, historically, people who wanted to have\n\"pick many commits\" complained that the \"rebase\" interface was backwards,\nbecause it works in the _wrong_ direction for _their_ usecase. Of course,\nwhen you _are_ rebasing a branch on top of some other branch, the way\n\"rebase\" currently works is the _right_ direction.\n\nBut I think it is a reasonable thing to _implement_ the feature to\nrange-pick commits reusing the sequencing logic already in \"rebase\" and\n\"rebase -i\". That essentially is what we wanted to do with \"git\nsequencer\" that would be a sequencing logic backend shared among rebase,\ncherry-pick, and perhaps am.\n\nSo perhaps a good way to move forward is to teach \"git cherry-pick A..B\"\nto be a thin wrapper that invokes a new hidden mode of operation added to\n\"rebase\" that is not advertised to the end user.\n\nI would suggest calling the option to invoke that hidden mode not\n\"--revisions\", but \"--reverse\" or \"--opposite\" or something of that\nnature, though. It makes \"rebase\" work in different direction.\n"},{"id":"129573","messageId":"fabb9a1e0912081229l7990a148j9cd2daa338662dd@mail.gmail.com","threadId":"21903","inReplyTo":"7vfx7lcj18.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-12-08T20:29:55Z","receivedAt":"2009-12-08T20:29:55Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Tue, Dec 8, 2009 at 21:22, Junio C Hamano wrote:\n> But I think it is a reasonable thing to _implement_ the feature to\n> range-pick commits reusing the sequencing logic already in \"rebase\" and\n> \"rebase -i\".  That essentially is what we wanted to do with \"git\n> sequencer\" that would be a sequencing logic backend shared among rebase,\n> cherry-pick, and perhaps am.\n\nSpeaking of which, what's the status of git sequencer? I seem to\nremember some activity recently to slowly rewrite git rebase in c, but\nI haven't seen anything since then. Is it still moving forward? Is\nanyone interested in doing so? Just curious...\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"129599","messageId":"buoy6lclpgi.fsf@dhlpc061.dev.necel.com","threadId":"21903","inReplyTo":"20091208164449.GA32204@redhat.com","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2009-12-09T04:51:41Z","receivedAt":"2009-12-09T04:51:41Z","isPatch":true,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"\"Michael S. Tsirkin\" writes:\n> OTOH, rebase --revisions as I implemented is a \"smarter cherry-pick\" which\n> can't easily be achieved with existing commands, especially if you add\n> \"-i\".\n\nIt also allows making use of rebase's rather extensive machinery for\ndealing with conflicts (e.g., rebase --continue / --skip / --abort).\n\nBut it would make more sense to have it in cherry-pick...\n(cherry-pick --continue / --skip / --abort...)\n\n-Miles\n\n-- \nConsult, v.i. To seek another's disapproval of a course already decided on.\n"},{"id":"129601","messageId":"200912090630.28506.chriscool@tuxfamily.org","threadId":"21903","inReplyTo":"fabb9a1e0912081229l7990a148j9cd2daa338662dd@mail.gmail.com","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2009-12-09T05:30:28Z","receivedAt":"2009-12-09T05:30:28Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nOn mardi 08 décembre 2009, Sverre Rabbelier wrote:\n> Heya,\n>\n> On Tue, Dec 8, 2009 at 21:22, Junio C Hamano wrote:\n> > But I think it is a reasonable thing to _implement_ the feature to\n> > range-pick commits reusing the sequencing logic already in \"rebase\" and\n> > \"rebase -i\".  That essentially is what we wanted to do with \"git\n> > sequencer\" that would be a sequencing logic backend shared among\n> > rebase, cherry-pick, and perhaps am.\n>\n> Speaking of which, what's the status of git sequencer? I seem to\n> remember some activity recently to slowly rewrite git rebase in c, but\n> I haven't seen anything since then. Is it still moving forward? Is\n> anyone interested in doing so? Just curious...\n\nLast June and July, I sent some patch series to port \"rebase -i\" to C using \ncode from the sequencer project. My goal was to save some interesting code \nfrom the sequencer GSoC 2008 project and at the same time to move \nforward \"rebase -i\" code toward a sequencer.\n\nBut Dscho and Junio didn't like the fact that the code from the sequencer I \nadded was duplicating existing code and was not properly refactored, though \nit also added things that would be needed later for the sequencer. My plan \nwas to refactor later, once I had a sequencer, but Junio and Dscho did not \nlike that plan. They said it would be a too big maintenance burden.\n\nSo I agreed to not duplicate any existing code and to properly refactor \neverything. And I have been trying to take interesting and useful code from \nthe sequencer project and to integrate it into existing commands. And this \nis why I sent yesterday the 4th version of my '\"git reset --merge\" related \nimprovements' patch series.\n\nBest regards,\nChristian.\n"},{"id":"129607","messageId":"200912090752.51609.chriscool@tuxfamily.org","threadId":"21903","inReplyTo":"200912090630.28506.chriscool@tuxfamily.org","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2009-12-09T06:52:51Z","receivedAt":"2009-12-09T06:52:51Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On mercredi 09 décembre 2009, Christian Couder wrote:\n> Hi,\n>\n> On mardi 08 décembre 2009, Sverre Rabbelier wrote:\n> > Heya,\n> >\n> > On Tue, Dec 8, 2009 at 21:22, Junio C Hamano wrote:\n> > > But I think it is a reasonable thing to _implement_ the feature to\n> > > range-pick commits reusing the sequencing logic already in \"rebase\"\n> > > and \"rebase -i\".  That essentially is what we wanted to do with \"git\n> > > sequencer\" that would be a sequencing logic backend shared among\n> > > rebase, cherry-pick, and perhaps am.\n> >\n> > Speaking of which, what's the status of git sequencer? I seem to\n> > remember some activity recently to slowly rewrite git rebase in c, but\n> > I haven't seen anything since then. Is it still moving forward? Is\n> > anyone interested in doing so? Just curious...\n>\n> Last June and July, I sent some patch series to port \"rebase -i\" to C\n> using code from the sequencer project. My goal was to save some\n> interesting code from the sequencer GSoC 2008 project and at the same\n> time to move forward \"rebase -i\" code toward a sequencer.\n>\n> But Dscho and Junio didn't like the fact that the code from the sequencer\n> I added was duplicating existing code and was not properly refactored,\n> though it also added things that would be needed later for the sequencer.\n> My plan was to refactor later, once I had a sequencer, but Junio and\n> Dscho did not like that plan. They said it would be a too big maintenance\n> burden.\n>\n> So I agreed to not duplicate any existing code and to properly refactor\n> everything. And I have been trying to take interesting and useful code\n> from the sequencer project and to integrate it into existing commands.\n> And this is why I sent yesterday the 4th version of my '\"git reset\n> --merge\" related improvements' patch series.\n\nAfter that I plan to work on cherry-pick and that could be useful to \nimplement something like \"git cherry-pick A..B\".\n\nSee patch 11/15 from Stephan Beyer in my last \"port rebase -i to C\" series: \n\nhttp://thread.gmane.org/gmane.comp.version-control.git/127256/focus=127259\n\nRegards,\nChristian.\n"},{"id":"129612","messageId":"alpine.DEB.2.00.0912090941420.470@ds9.cixit.se","threadId":"21903","inReplyTo":"7vfx7lcj18.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2009-12-09T08:47:56Z","receivedAt":"2009-12-09T08:47:56Z","isPatch":true,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Junio C Hamano:\n\n> Many people wanted to have \"pick many commits onto the current HEAD\" and I \n> think it would be a natural, uncontroversial and welcome addition to allow \n> \"git cherry-pick A..B\".\n\nOr even \"git cherry-pick branch\", as I naïvely tried doing before I \nunderstood what it did. This is definitely a feature that would help me.\n\nThe question of where it goes is actually a bit difficult, it is the same \nmode of operation as \"git rebase\", only the other way around. It is the same \nas \"git cherry-pick\", but called multiple times. And it is the same as \"git \nmerge --squash\", but without squashing the commits into one.\n\nSo does this new mode go into rebase, cherry-pick or merge, or into all \nthree? No matter which, proper documentation is needed.\n\n\nMaybe this could also be used to implement a \"git merge --squash A..B\", a.k.a \na \"partial merge\". (And if it could be implemented to allow a \"git merge A..B\" \nand later do a \"git merge B\" to merge the rest of the side-branch, that \nwould be interesting).\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"129614","messageId":"fabb9a1e0912090108k338baaacg3ce2889dcf937cf2@mail.gmail.com","threadId":"21903","inReplyTo":"200912090752.51609.chriscool@tuxfamily.org","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-12-09T09:08:26Z","receivedAt":"2009-12-09T09:08:26Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Wed, Dec 9, 2009 at 07:52, Christian Couder wrote:\n\n\n\n> After that I plan to work on cherry-pick and that could be useful to\n> implement something like \"git cherry-pick A..B\".\n\nAh, okay, thanks for the update!\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"129616","messageId":"20091209093758.GA2977@redhat.com","threadId":"21903","inReplyTo":"alpine.DEB.2.00.0912090941420.470@ds9.cixit.se","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2009-12-09T09:37:58Z","receivedAt":"2009-12-09T09:37:58Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Wed, Dec 09, 2009 at 09:47:56AM +0100, Peter Krefting wrote:\n> Junio C Hamano:\n>\n>> Many people wanted to have \"pick many commits onto the current HEAD\" \n>> and I think it would be a natural, uncontroversial and welcome addition \n>> to allow \"git cherry-pick A..B\".\n>\n> Or even \"git cherry-pick branch\", as I naïvely tried doing before I \n> understood what it did. This is definitely a feature that would help me.\n>\n> The question of where it goes is actually a bit difficult, it is the same \n> mode of operation as \"git rebase\", only the other way around. It is the \n> same as \"git cherry-pick\", but called multiple times. And it is the same \n> as \"git merge --squash\", but without squashing the commits into one.\n>\n> So does this new mode go into rebase, cherry-pick or merge, or into all \n> three? No matter which, proper documentation is needed.\n>\n>\n> Maybe this could also be used to implement a \"git merge --squash A..B\", \n> a.k.a a \"partial merge\".\n\nWhat exactly should it do?\n\n> (And if it could be implemented to allow a \"git \n> merge A..B\" and later do a \"git merge B\" to merge the rest of the \n> side-branch, that would be interesting).\n\nrebase already tries to detect previously applied commits.\nMaybe we can teach it to use more heuristics.\n\n> -- \n> \\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"129620","messageId":"20091209103850.GD2977@redhat.com","threadId":"21903","inReplyTo":"7vfx7lcj18.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2009-12-09T10:38:50Z","receivedAt":"2009-12-09T10:38:50Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Tue, Dec 08, 2009 at 12:22:59PM -0800, Junio C Hamano wrote:\n> \"Michael S. Tsirkin\" writes:\n> \n> > Add --revisions flag to rebase, so that it can be used\n> > to apply an arbitrary range of commits on top\n> > of a current branch.\n> \n> Many people wanted to have \"pick many commits onto the current HEAD\" and I\n> think it would be a natural, uncontroversial and welcome addition to allow\n> \"git cherry-pick A..B\". In fact, historically, people who wanted to have\n> \"pick many commits\" complained that the \"rebase\" interface was backwards,\n> because it works in the _wrong_ direction for _their_ usecase. Of course,\n> when you _are_ rebasing a branch on top of some other branch, the way\n> \"rebase\" currently works is the _right_ direction.\n> \n> But I think it is a reasonable thing to _implement_ the feature to\n> range-pick commits reusing the sequencing logic already in \"rebase\" and\n> \"rebase -i\". That essentially is what we wanted to do with \"git\n> sequencer\" that would be a sequencing logic backend shared among rebase,\n> cherry-pick, and perhaps am.\n> \n> So perhaps a good way to move forward is to teach \"git cherry-pick A..B\"\n> to be a thin wrapper that invokes a new hidden mode of operation added to\n> \"rebase\" that is not advertised to the end user.\n> \n> I would suggest calling the option to invoke that hidden mode not\n> \"--revisions\", but \"--reverse\" or \"--opposite\" or something of that\n> nature, though. It makes \"rebase\" work in different direction.\n\ncherry-pick is a binary though while rebase is a shell script.\nShould I just exec git rebase? git-rebase?\n\n-- \nMST\n"},{"id":"129621","messageId":"alpine.DEB.2.00.0912091150470.470@ds9.cixit.se","threadId":"21903","inReplyTo":"20091209093758.GA2977@redhat.com","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2009-12-09T10:52:41Z","receivedAt":"2009-12-09T10:52:41Z","isPatch":true,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Michael S. Tsirkin:\n\n>> Maybe this could also be used to implement a \"git merge --squash A..B\", \n>> a.k.a a \"partial merge\".\n> What exactly should it do?\n\nThe same thing, apply a set of changes on top of the current branch, just \nusing the \"merge\" name, and not \"rebase\" or \"cherry-pick\". \"merge --squash\" \nis just \"cherry-pick\" with a different name.\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"129622","messageId":"vpqaaxswh5b.fsf@bauges.imag.fr","threadId":"21903","inReplyTo":"20091209103850.GD2977@redhat.com","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2009-12-09T10:55:44Z","receivedAt":"2009-12-09T10:55:44Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"\"Michael S. Tsirkin\" writes:\n\n> cherry-pick is a binary though while rebase is a shell script.\n> Should I just exec git rebase? git-rebase?\n\nSee run-command.h :\n\n#define RUN_GIT_CMD\t 2\t/*If this is to be git sub-command */\nint run_command_v_opt(const char **argv, int opt);\n\nThat should do the trick (grep 'run_command_v_opt.*GIT_CMD' *.c for\nsome example of uses).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"129623","messageId":"20091209112237.GA27740@atjola.homenet","threadId":"21903","inReplyTo":"alpine.DEB.2.00.0912091150470.470@ds9.cixit.se","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-12-09T11:22:37Z","receivedAt":"2009-12-09T11:22:37Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.12.09 11:52:41 +0100, Peter Krefting wrote:\n> Michael S. Tsirkin:\n> \n> >>Maybe this could also be used to implement a \"git merge --squash\n> >>A..B\", a.k.a a \"partial merge\".\n> >What exactly should it do?\n> \n> The same thing, apply a set of changes on top of the current branch,\n> just using the \"merge\" name, and not \"rebase\" or \"cherry-pick\".\n> \"merge --squash\" is just \"cherry-pick\" with a different name.\n\nErr, no. \"git merge --squash foo\" merges all changes from the merge base\nof HEAD and foo up to foo. \"git cherry-pick foo\" takes just the changes\nfrom foo^ to foo. For example:\n\nA---B---C (master)\n \\\n D---E---F (foo)\n\ngit cherry-pick foo # Tries to create a new commit with the changes from\n # \"git diff D F\"\n\ngit merge --squash foo # Tries to create a new commit with the changes\n # from \"git diff A F\"\n\nBjörn\n"},{"id":"129624","messageId":"m2pr6ocqrb.fsf@igel.home","threadId":"21903","inReplyTo":"20091209112237.GA27740@atjola.homenet","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2009-12-09T11:48:24Z","receivedAt":"2009-12-09T11:48:24Z","isPatch":true,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Björn Steinbrink writes:\n\n> Err, no. \"git merge --squash foo\" merges all changes from the merge base\n> of HEAD and foo up to foo. \"git cherry-pick foo\" takes just the changes\n> from foo^ to foo. For example:\n>\n> A---B---C (master)\n> \\\n> D---E---F (foo)\n>\n> git cherry-pick foo # Tries to create a new commit with the changes from\n> # \"git diff D F\"\n\nDid you mean \"git diff E F\"?\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"129625","messageId":"20091209120610.GA29430@atjola.homenet","threadId":"21903","inReplyTo":"m2pr6ocqrb.fsf@igel.home","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-12-09T12:06:10Z","receivedAt":"2009-12-09T12:06:10Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.12.09 12:48:24 +0100, Andreas Schwab wrote:\n> Björn Steinbrink writes:\n> \n> > Err, no. \"git merge --squash foo\" merges all changes from the merge base\n> > of HEAD and foo up to foo. \"git cherry-pick foo\" takes just the changes\n> > from foo^ to foo. For example:\n> >\n> > A---B---C (master)\n> > \\\n> > D---E---F (foo)\n> >\n> > git cherry-pick foo # Tries to create a new commit with the changes from\n> > # \"git diff D F\"\n> \n> Did you mean \"git diff E F\"?\n\nUgh, yes, of course. Thanks.\n\nBjörn\n"},{"id":"129626","messageId":"20091209120748.GI2977@redhat.com","threadId":"21903","inReplyTo":"20091209120610.GA29430@atjola.homenet","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2009-12-09T12:07:48Z","receivedAt":"2009-12-09T12:07:48Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Wed, Dec 09, 2009 at 01:06:10PM +0100, Björn Steinbrink wrote:\n> On 2009.12.09 12:48:24 +0100, Andreas Schwab wrote:\n> > Björn Steinbrink writes:\n> > \n> > > Err, no. \"git merge --squash foo\" merges all changes from the merge base\n> > > of HEAD and foo up to foo. \"git cherry-pick foo\" takes just the changes\n> > > from foo^ to foo. For example:\n> > >\n> > > A---B---C (master)\n> > > \\\n> > > D---E---F (foo)\n> > >\n> > > git cherry-pick foo # Tries to create a new commit with the changes from\n> > > # \"git diff D F\"\n> > \n> > Did you mean \"git diff E F\"?\n> \n> Ugh, yes, of course. Thanks.\n> \n> Björn\n\nSo this will be best written as\ngit cherry-pick ..foo\n\n-- \nMST\n"},{"id":"129628","messageId":"20091209130653.GA30218@atjola.homenet","threadId":"21903","inReplyTo":"20091209120748.GI2977@redhat.com","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-12-09T13:06:53Z","receivedAt":"2009-12-09T13:06:53Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.12.09 14:07:48 +0200, Michael S. Tsirkin wrote:\n> On Wed, Dec 09, 2009 at 01:06:10PM +0100, Björn Steinbrink wrote:\n> > On 2009.12.09 12:48:24 +0100, Andreas Schwab wrote:\n> > > Björn Steinbrink writes:\n> > > \n> > > > Err, no. \"git merge --squash foo\" merges all changes from the merge base\n> > > > of HEAD and foo up to foo. \"git cherry-pick foo\" takes just the changes\n> > > > from foo^ to foo. For example:\n> > > >\n> > > > A---B---C (master)\n> > > > \\\n> > > > D---E---F (foo)\n> > > >\n> > > > git cherry-pick foo # Tries to create a new commit with the changes from\n> > > > # \"git diff D F\"\n> > > \n> > > Did you mean \"git diff E F\"?\n> > \n> > Ugh, yes, of course. Thanks.\n> \n> So this will be best written as\n> git cherry-pick ..foo\n\nNo, \"git cherry-pick ..foo\" should pick the individual commits, and not\ncreate a single big commit like \"git merge --squash\". So such a command\nshould make you end up with:\n\nA---B---C---D'--E'--F' (master)\n \\\n D---E---F\n\nNot:\nA---B---C---M (master)\n \\\n D---E---F (foo)\n\n[M being the \"sqash-merge\"]\n\n\"merge --squash\" is one of the things I really dislike, because it turns\noff the \"history\" part of the merge. You can say \"Merging in git is about\nhistories, merging in svn is about changes only\" to describe the major\ndifference for the merge commands in the two systems... \"But then\nthere's --squash which turns git into svn\".\n\nI think a \"cherry-pick --squash \" command would be nicer from a\nconceptual point of view, but it's way too late for merge --squash to be\ndropped. And I guess it wouldn't be trivial to add such a flag, and not\nworth the effort, as you could as well use the interactive mode and\nreplace \"pick\" with \"squash\" manually. (An el cheapo implementation that\nautomatically replaces it would likely confuse the user, because he\nasked for a single commit, but might get to fix conflicts for all the\nindividual commits).\n\nBjörn\n"},{"id":"129629","messageId":"20091209131945.GB30218@atjola.homenet","threadId":"21903","inReplyTo":"20091208200017.GA827@redhat.com","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-12-09T13:19:45Z","receivedAt":"2009-12-09T13:19:45Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.12.08 22:00:17 +0200, Michael S. Tsirkin wrote:\n> On Tue, Dec 08, 2009 at 08:11:07PM +0100, Björn Steinbrink wrote:\n> > So you can already do what you want to do, but wrapping it in a single\n> > porcelain might still be useful because it's obviously a lot easier and\n> > safer that way. That said, I wonder what kind of workflow you're using\n> > though, and why you require that feature. I've never needed something\n> > like that.\n> \n> I need this often for many reasons:\n> -\tImagine developing a patchset with a complex bugfix on master branch.\n> \tThen I decide to also apply (backport) this patchset to stable branch.\n\nHm, I'd also imagine that you want a separate branch then, and not\ndirectly mess up the stable branch, so I'd do:\ngit branch foo-stable foo # Create a branch for the backport\ngit rebase --onto stable master foo-stable # Backport\n\nNow you got your backported version and can merge it to \"stable\".\n\nCommon wisdom is do things the other way around though. Create the\nbugfix for the oldest branch that it applies to, then merge it forward,\neither doing:\n\n\"bugfix -> stable\" and \"stable -> master\" merges, or\n\"bugfix -> stable\" and \"bugfix -> master\" merges.\n\nThat approach has the advantage that you don't get multiple commits\ndoing the same thing, which you get with rebasing/cherry-picking.\n\nIIRC the gitworkflows manpage describe that in some more detail.\n\n> -\tImagine developing a bugfix/feature patchset on master branch.\n> \tThen I decide the patchset is too large/unsafe and want to\n> \tswitch it to staging branch.\n\nHm, so you have a topic branch \"foo\" based upon master, but it's too\nexperimental so you don't want to merge it to master, but \"staging\". I\ndon't see why you even have to rebase it then. \"staging\" is likely ahead\nof master, so the merge base of \"foo\" and \"master\" is also reachable\nthrough \"staging\", and simply merging \"foo\" to \"staging\" should work\nwithout any ill-effects.\n\n> -\tI have a large queue of patches on staging branch, I decide that\n> \ta range of patches is mature enough for master.\n\nBasically, same deal as with the first two cases. If the series is\ndirectly on \"staging\" (i.e. you didn't create a topic branch), you can\ncreate one now:\ngit branch foo $last_commit_for_foo\ngit rebase --onto master $first_commit_for_foo^ foo\n\nAnd you got your backported topic branch for \"foo\".\n\nOr you already have a topic branch \"foo-staging\", but it's based upon\nsome commit only in \"staging\" but not in \"master\", so a plain merge\nwould mess things up. Same deal as with backporting from \"master\" to\n\"stable\"\n\nAnd in this case it's also true that basing the topic branches on\n\"master\" instead of \"staging\" makes things easier. That way, you can\nmerge to either \"staging\" or \"master\" without any ill-effects.\n\nBjörn\n"},{"id":"129630","messageId":"alpine.DEB.2.00.0912091414460.470@ds9.cixit.se","threadId":"21903","inReplyTo":"20091209112237.GA27740@atjola.homenet","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2009-12-09T13:20:23Z","receivedAt":"2009-12-09T13:20:23Z","isPatch":true,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Björn Steinbrink:\n\n> Err, no. \"git merge --squash foo\" merges all changes from the merge base \n> of HEAD and foo up to foo. \"git cherry-pick foo\" takes just the changes\n> from foo^ to foo.\n\nExactly!\n\nWhat I meant to say in the original message was that conceptually, the \ndifference between a \"git rebase --reverse A..B\", a \"git cherry-pick A..B\" \nand a \"git merge --squash A..B\" is minute.\n\nAnd when continuing the thought experiment, the step from \"git merge \n--squash A..B\" to \"git merge A..B\" is not very large either, just (a \nlot) more difficult to implement.\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"129631","messageId":"vpqiqcgp95t.fsf@bauges.imag.fr","threadId":"21903","inReplyTo":"7vfx7lcj18.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2009-12-09T13:30:06Z","receivedAt":"2009-12-09T13:30:06Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> So perhaps a good way to move forward is to teach \"git cherry-pick A..B\"\n> to be a thin wrapper that invokes a new hidden mode of operation added to\n> \"rebase\" that is not advertised to the end user.\n>\n> I would suggest calling the option to invoke that hidden mode not\n> \"--revisions\", but \"--reverse\" or \"--opposite\" or something of that\n> nature, though. It makes \"rebase\" work in different direction.\n\nIntuitively,\n\n git rebase --reverse A..B\n\nwould mean \"take the range A..B, and start applying the patches from\nB, going in reverse order up to A\", like \"git log --reverse\". So, I'd\nfind it misleading.\n\nPerhaps \"git rebase --cherry-pick A..B\" would be a better name. No\nobjection for --opposite either.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"129632","messageId":"20091209134133.GA30596@atjola.homenet","threadId":"21903","inReplyTo":"alpine.DEB.2.00.0912091414460.470@ds9.cixit.se","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-12-09T13:41:33Z","receivedAt":"2009-12-09T13:41:33Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.12.09 14:20:23 +0100, Peter Krefting wrote:\n> Björn Steinbrink:\n> \n> >Err, no. \"git merge --squash foo\" merges all changes from the\n> >merge base of HEAD and foo up to foo. \"git cherry-pick foo\" takes\n> >just the changes\n> > from foo^ to foo.\n> \n> Exactly!\n> \n> What I meant to say in the original message was that conceptually,\n> the difference between a \"git rebase --reverse A..B\", a \"git\n> cherry-pick A..B\" and a \"git merge --squash A..B\" is minute.\n> \n> And when continuing the thought experiment, the step from \"git merge\n> --squash A..B\" to \"git merge A..B\" is not very large either, just (a\n> lot) more difficult to implement.\n\n\"git merge\" is about merging histories. --squash and the A..B you\nsuggest make it degenerate into merging changes (and you can't record\nthat using the commit DAG). So that messes things up conceptually.\n\nImplementing probably wouldn't be that hard, IIRC it should be a matter\nof messing with the fake merge base that cherry-pick uses to get its job\ndone. While \"git cherry-pick foo\" uses foo^ as the merge base, you'd\njust make \"git merge --squash A..B\" work like \"git cherry-pick B\" but\nuse A as the fake merge base. It's been a while since I looked at the\ncherry-pick code though, so I might be off here.\n\n(Kind of ironic though that I didn't think of that when I said that\n\"cherry-pick --squash\" would be hard to do...)\n\nAnyway, \"git merge\" with a range simply makes no sense at all given how\ngit's merge works (opposed to svn's idea of merging, which is about\nchanges, not about histories). If you want a squash flag, tell\ncherry-pick to handle ranges and teach such a flag to it.\n\nBjörn\n"},{"id":"129633","messageId":"20091209134535.GK2977@redhat.com","threadId":"21903","inReplyTo":"vpqiqcgp95t.fsf@bauges.imag.fr","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2009-12-09T13:45:36Z","receivedAt":"2009-12-09T13:45:36Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Wed, Dec 09, 2009 at 02:30:06PM +0100, Matthieu Moy wrote:\n> Junio C Hamano writes:\n> \n> > So perhaps a good way to move forward is to teach \"git cherry-pick A..B\"\n> > to be a thin wrapper that invokes a new hidden mode of operation added to\n> > \"rebase\" that is not advertised to the end user.\n> >\n> > I would suggest calling the option to invoke that hidden mode not\n> > \"--revisions\", but \"--reverse\" or \"--opposite\" or something of that\n> > nature, though. It makes \"rebase\" work in different direction.\n> \n> Intuitively,\n> \n> git rebase --reverse A..B\n> \n> would mean \"take the range A..B, and start applying the patches from\n> B, going in reverse order up to A\", like \"git log --reverse\". So, I'd\n> find it misleading.\n> \n> Perhaps \"git rebase --cherry-pick A..B\" would be a better name. No\n> objection for --opposite either.\n\nI relly like --cherry-pick. Junio, objections to that one?\n\n> -- \n> Matthieu Moy\n> http://www-verimag.imag.fr/~moy/\n"},{"id":"129634","messageId":"20091209140145.GA31130@atjola.homenet","threadId":"21903","inReplyTo":"20091209134535.GK2977@redhat.com","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-12-09T14:01:45Z","receivedAt":"2009-12-09T14:01:45Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.12.09 15:45:36 +0200, Michael S. Tsirkin wrote:\n> On Wed, Dec 09, 2009 at 02:30:06PM +0100, Matthieu Moy wrote:\n> > Junio C Hamano writes:\n> > \n> > > So perhaps a good way to move forward is to teach \"git cherry-pick A..B\"\n> > > to be a thin wrapper that invokes a new hidden mode of operation added to\n> > > \"rebase\" that is not advertised to the end user.\n> > >\n> > > I would suggest calling the option to invoke that hidden mode not\n> > > \"--revisions\", but \"--reverse\" or \"--opposite\" or something of that\n> > > nature, though. It makes \"rebase\" work in different direction.\n> > \n> > Intuitively,\n> > \n> > git rebase --reverse A..B\n> > \n> > would mean \"take the range A..B, and start applying the patches from\n> > B, going in reverse order up to A\", like \"git log --reverse\". So, I'd\n> > find it misleading.\n> > \n> > Perhaps \"git rebase --cherry-pick A..B\" would be a better name. No\n> > objection for --opposite either.\n> \n> I relly like --cherry-pick. Junio, objections to that one?\n\nHm, there's also (the probably not so well known)\n\"git rev-list --cherry-pick A...B\", which excludes commits that appear\non both A and B and have the same patch id. I'd rather call the rev-list\noption a misnomer than the suggested hidden option for rebase, but I'd\ncall it --cherry-pick-mode or --cherry-picking (like am's hidden \"git am\n--rebasing\"), just to make sure... Of course, it's not _that_ important,\nas it's going to be a hidden option, so user confusion is probably not\nthat much of a concern.\n\nBjörn\n"},{"id":"129635","messageId":"20091209140236.GL2977@redhat.com","threadId":"21903","inReplyTo":"20091209131945.GB30218@atjola.homenet","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2009-12-09T14:02:36Z","receivedAt":"2009-12-09T14:02:36Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Wed, Dec 09, 2009 at 02:19:45PM +0100, Björn Steinbrink wrote:\n> On 2009.12.08 22:00:17 +0200, Michael S. Tsirkin wrote:\n> > On Tue, Dec 08, 2009 at 08:11:07PM +0100, Björn Steinbrink wrote:\n> > > So you can already do what you want to do, but wrapping it in a single\n> > > porcelain might still be useful because it's obviously a lot easier and\n> > > safer that way. That said, I wonder what kind of workflow you're using\n> > > though, and why you require that feature. I've never needed something\n> > > like that.\n> > \n> > I need this often for many reasons:\n> > -\tImagine developing a patchset with a complex bugfix on master branch.\n> > \tThen I decide to also apply (backport) this patchset to stable branch.\n> \n> Hm, I'd also imagine that you want a separate branch then, and not\n> directly mess up the stable branch,\n\nWell, directly working with a stable branch is easier, so yes,\nI want to mess it up: this is just my local tree, if anything\ngoes wrong I just don't push or \"reset --hard origin/stable\".\n\n> so I'd do:\n> git branch foo-stable foo # Create a branch for the backport\n> git rebase --onto stable master foo-stable # Backport\n> \n> Now you got your backported version and can merge it to \"stable\".\n\nThe annoying thing is that merge step. I can create a merge\ncommit if I mistype things, and I do not want any\nmerge commits, I want to create linear history.\n\n> Common wisdom is do things the other way around though. Create the\n> bugfix for the oldest branch that it applies to, then merge it forward,\n> either doing:\n> \n> \"bugfix -> stable\" and \"stable -> master\" merges, or\n> \"bugfix -> stable\" and \"bugfix -> master\" merges.\n> \n> That approach has the advantage that you don't get multiple commits\n> doing the same thing, which you get with rebasing/cherry-picking.\n> \n> IIRC the gitworkflows manpage describe that in some more detail.\n\n\nI know. The advantage of making all changes to master first\nis that this way a change gets more review and testing before\nbeing applied to stable. Further, often different people\nmaintain master and stable branches.\n\n> > -\tImagine developing a bugfix/feature patchset on master branch.\n> > \tThen I decide the patchset is too large/unsafe and want to\n> > \tswitch it to staging branch.\n> \n> Hm, so you have a topic branch \"foo\" based upon master, but it's too\n> experimental so you don't want to merge it to master, but \"staging\". I\n> don't see why you even have to rebase it then. \"staging\" is likely ahead\n> of master, so the merge base of \"foo\" and \"master\" is also reachable\n> through \"staging\", and simply merging \"foo\" to \"staging\" should work\n> without any ill-effects.\n\nYes but I want my development history to be linear,\nso that format patch rebase -i etc work well.\n\n> > -\tI have a large queue of patches on staging branch, I decide that\n> > \ta range of patches is mature enough for master.\n> \n> Basically, same deal as with the first two cases. If the series is\n> directly on \"staging\" (i.e. you didn't create a topic branch), you can\n> create one now:\n> git branch foo $last_commit_for_foo\n> git rebase --onto master $first_commit_for_foo^ foo\n> \n> And you got your backported topic branch for \"foo\".\n> \n> Or you already have a topic branch \"foo-staging\", but it's based upon\n> some commit only in \"staging\" but not in \"master\", so a plain merge\n> would mess things up. Same deal as with backporting from \"master\" to\n> \"stable\"\n\nYes, I understand that creating a temporary branch and checking it out\nthen merging it will make rebase do what I want.\nThe only disadvantage is that I need to remember where I am in the\nprocess, while an \"atomic\" command does this for me.\n\n> And in this case it's also true that basing the topic branches on\n> \"master\" instead of \"staging\" makes things easier. That way, you can\n> merge to either \"staging\" or \"master\" without any ill-effects.\n> \n> Björn\n\nAs above, I do not want merges.\n"},{"id":"129636","messageId":"20091209141208.GM2977@redhat.com","threadId":"21903","inReplyTo":"20091209140145.GA31130@atjola.homenet","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2009-12-09T14:12:08Z","receivedAt":"2009-12-09T14:12:08Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Wed, Dec 09, 2009 at 03:01:45PM +0100, Björn Steinbrink wrote:\n> On 2009.12.09 15:45:36 +0200, Michael S. Tsirkin wrote:\n> > On Wed, Dec 09, 2009 at 02:30:06PM +0100, Matthieu Moy wrote:\n> > > Junio C Hamano writes:\n> > > \n> > > > So perhaps a good way to move forward is to teach \"git cherry-pick A..B\"\n> > > > to be a thin wrapper that invokes a new hidden mode of operation added to\n> > > > \"rebase\" that is not advertised to the end user.\n> > > >\n> > > > I would suggest calling the option to invoke that hidden mode not\n> > > > \"--revisions\", but \"--reverse\" or \"--opposite\" or something of that\n> > > > nature, though. It makes \"rebase\" work in different direction.\n> > > \n> > > Intuitively,\n> > > \n> > > git rebase --reverse A..B\n> > > \n> > > would mean \"take the range A..B, and start applying the patches from\n> > > B, going in reverse order up to A\", like \"git log --reverse\". So, I'd\n> > > find it misleading.\n> > > \n> > > Perhaps \"git rebase --cherry-pick A..B\" would be a better name. No\n> > > objection for --opposite either.\n> > \n> > I relly like --cherry-pick. Junio, objections to that one?\n> \n> Hm, there's also (the probably not so well known)\n> \"git rev-list --cherry-pick A...B\", which excludes commits that appear\n> on both A and B and have the same patch id. I'd rather call the rev-list\n> option a misnomer than the suggested hidden option for rebase, but I'd\n> call it --cherry-pick-mode or --cherry-picking (like am's hidden \"git am\n> --rebasing\"), just to make sure... Of course, it's not _that_ important,\n> as it's going to be a hidden option, so user confusion is probably not\n> that much of a concern.\n> \n> Björn\n\nOK, --cherry-picking looks fine as well.\n"},{"id":"129657","messageId":"7v1vj4orra.fsf@alter.siamese.dyndns.org","threadId":"21903","inReplyTo":"20091209130653.GA30218@atjola.homenet","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-12-09T19:46:01Z","receivedAt":"2009-12-09T19:46:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Björn Steinbrink writes:\n\n> \"merge --squash\" is one of the things I really dislike, because it turns\n> off the \"history\" part of the merge. You can say \"Merging in git is about\n> histories, merging in svn is about changes only\" to describe the major\n> difference for the merge commands in the two systems... \"But then\n> there's --squash which turns git into svn\".\n\nI agree with this to some degree, but I do not offhand think of a better\nalternative. \n\nAt the first sight, it looks as if what \"merge --squash\" does was\nimplemented as a new option \"--squash\" to the \"merge\" command merely\nbecause the way _how_ it internally needs to compute the result was\nalready available in the implementation of \"merge\" command, and not\nnecessarily because _what_ it does was conceptually consistent with the\nway \"merge\" works.\n\nBut at the conceptual level, \"merge --squash\" is a short-hand for this\ncommand sequence:\n\n git rebase -i HEAD that-branch\n ... make everything except the first one into \"squash\"\n git checkout - ;# come back to the original branch\n git merge that-branch ;# fast forward to it\n\nSo after all, it is \"merge it after squashing them\".\n"},{"id":"129660","messageId":"7vmy1roqm5.fsf@alter.siamese.dyndns.org","threadId":"21903","inReplyTo":"vpqiqcgp95t.fsf@bauges.imag.fr","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-12-09T20:10:42Z","receivedAt":"2009-12-09T20:10:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Perhaps \"git rebase --cherry-pick A..B\" would be a better name. No\n> objection for --opposite either.\n\nAs somebody mentioned, \"--cherry-picking\", similar to \"am --rebasing\" that\nis also an unadvertised internal implementation detail, is a good name.\n\nIn the very old days, the original \"rebase\" command was a command to\n\"set-up and run 'am -3' command in order to transplant the current branch\nonto somewhere else.\"\n\nThat was obviously too long for a command name and description, and I\nshorten it to \"rebase\", to name the command after what it is _for_ (not\n\"what it does\", nor \"how it does it\"). Because the command was to \"set up\nand run am-3\", it was natural at the conceptual level that the way to\ncontinue after a failed/conflicted patch application was \"am --resolved\".\n\nBut since then, the concept of \"rebasing\" got established more firmly and\nhow \"rebase\" can be done has become much less relevant. The original name\n\"rebase\" stopped being short for \"set up and run am-3 for rebasing\", but\nabout what it _does_ (i.e. \"it rebases\"). And \"rebase --continue\" has\nbecome a natural way to drive \"am --continue\" at that point, to accomodate\nfor the change in the end-user conception. These days, \"set up and run\nam-3 for rebasing\" is not even _how_ it does the \"rebase\", as \"rebase -i\"\ndoes not even use am-3. So \"rebase --continue\" was a logical conclusion\nof the command's evolution.\n\nThe lesson to be learned from this history is that \"cherry-pick A..B\" that\ninternally runs \"rebase --cherry-picking\" will need a similar \"--continue\"\nsupport that delegates to \"rebase\". \"running am\", which was originally\nthe whole point of \"rebase\", later became an implementation detail, and we\nneeded to teach \"--continue\" to \"rebase\" at that point.\n\nBecause from day one \"running rebase -i\" will be an implementation detail\nof \"cherry-pick A..B\", we need to teach \"cherry-pick\" to pass \"--abort\",\n\"--continue\", etc. to underlying \"rebase\" for the same reason.\n"},{"id":"129676","messageId":"20091210074358.GA7723@atjola.homenet","threadId":"21903","inReplyTo":"7v1vj4orra.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-12-10T07:43:58Z","receivedAt":"2009-12-10T07:43:58Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.12.09 11:46:01 -0800, Junio C Hamano wrote:\n> Björn Steinbrink writes:\n> \n> > \"merge --squash\" is one of the things I really dislike, because it turns\n> > off the \"history\" part of the merge. You can say \"Merging in git is about\n> > histories, merging in svn is about changes only\" to describe the major\n> > difference for the merge commands in the two systems... \"But then\n> > there's --squash which turns git into svn\".\n> \n> I agree with this to some degree, but I do not offhand think of a better\n> alternative. \n> \n> At the first sight, it looks as if what \"merge --squash\" does was\n> implemented as a new option \"--squash\" to the \"merge\" command merely\n> because the way _how_ it internally needs to compute the result was\n> already available in the implementation of \"merge\" command, and not\n> necessarily because _what_ it does was conceptually consistent with the\n> way \"merge\" works.\n> \n> But at the conceptual level, \"merge --squash\" is a short-hand for this\n> command sequence:\n> \n> git rebase -i HEAD that-branch\n> ... make everything except the first one into \"squash\"\n> git checkout - ;# come back to the original branch\n> git merge that-branch ;# fast forward to it\n> \n> So after all, it is \"merge it after squashing them\".\n\nTo me, that approach looks backwards, just like the \"rebase --revisions\"\nproposal. \"rebase\" just happens to already provide the necessary\noperations, but if cherry-pick would accepts ranges, this looks a lot\nmore logical to me:\n\ngit cherry-pick HEAD..that_branch\ngit reset --soft this_branch@{1} # [1]\ngit commit\n\n[1] I assume that like \"rebase\", such a cherry-pick command would\nalready add a single reflog entry for the current branch\n\nI cherry-pick all changes, and then use reset + commit to squash them\ntogether to a single commit. To me, it's \"I want to get all the changes\nand squash them into a single commit\", not \"I want to squash the other\nside's history in the background, without actually affecting the other\nside and then merge that squashed version of the history\".\n\nSo \"cherry-pick --squash ..that_branch\" seems more logical at the\nconceptual level. Internally, it could of course just do a three-way\nmerge, instead of being stupid and repeating the \"apply, commit --amend\"\nsequence over and over again.\n\nBjörn\n"},{"id":"129677","messageId":"alpine.DEB.2.00.0912100937580.22606@ds9.cixit.se","threadId":"21903","inReplyTo":"20091209134133.GA30596@atjola.homenet","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2009-12-10T08:43:51Z","receivedAt":"2009-12-10T08:43:51Z","isPatch":true,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Björn Steinbrink:\n\n> \"git merge\" is about merging histories. --squash and the A..B you suggest \n> make it degenerate into merging changes (and you can't record that using \n> the commit DAG). So that messes things up conceptually.\n\nI know, this is the one \"feature\" of CVS that I sometimes miss in Git, that \nI cannot \"merge\" just parts of a history, and have that recorded in the \nhistory tree. I know it's wrong, I know I could do it better, but sometimes \nit's the shortcut that would make life easier for me. :-)\n\nBut the reason I mentioned it was because of the discussion on whether the \n\"reverse rebase\" should be an option to \"cherry-pick\" or not, and I \nmentioned that it could just as well be \"merge\" since it can be used to \nthrow away history as well.\n\n> Anyway, \"git merge\" with a range simply makes no sense at all given how \n> git's merge works (opposed to svn's idea of merging, which is about \n> changes, not about histories). If you want a squash flag, tell cherry-pick \n> to handle ranges and teach such a flag to it.\n\nAnd tell \"merge\" to tell me that if I try, so that if I try\n\n $ git merge A..B\n\nI would get a message saying something like\n\n Cannot merge a range of commits. Try \"git cherry-pick A..B\" or\n \"git rebase --reverse A..B\".\n\nAnd perhaps we could also in the same way retire --squash?\n\n $ git merge --squash B\n The \"--squash\" option is obsolete. Please use \"git cherry-pick\n --squash B\".\n\n(with a transition period where it would just call the other). Or whatever \nthe options to simulate the old behaviour would be. This would make it \nclearer that \"merge\" preserves history while \"cherry-pick\" and \"rebase\" do \nnot.\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"129680","messageId":"20091210110840.GA12098@atjola.homenet","threadId":"21903","inReplyTo":"alpine.DEB.2.00.0912100937580.22606@ds9.cixit.se","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-12-10T11:08:40Z","receivedAt":"2009-12-10T11:08:40Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.12.10 09:43:51 +0100, Peter Krefting wrote:\n> Björn Steinbrink:\n> >\"git merge\" is about merging histories. --squash and the A..B you\n> >suggest make it degenerate into merging changes (and you can't\n> >record that using the commit DAG). So that messes things up\n> >conceptually.\n> \n> I know, this is the one \"feature\" of CVS that I sometimes miss in\n> Git, that I cannot \"merge\" just parts of a history, and have that\n> recorded in the history tree. I know it's wrong, I know I could do\n> it better, but sometimes it's the shortcut that would make life\n> easier for me. :-)\n\nHm, does CVS really record the fact that things were merged? I've never\nseriously used CVS, so I have no idea... And if it does, is it just the\nsame thing as the svn \"merge\"-tracking?\n\n> But the reason I mentioned it was because of the discussion on\n> whether the \"reverse rebase\" should be an option to \"cherry-pick\" or\n> not, and I mentioned that it could just as well be \"merge\" since it\n> can be used to throw away history as well.\n\nOK, and I disagreed because I think that \"merge --squash\" is already\nwrong. And given your comment below about retiring \"merge --squash\", I\nguess we're in agreement now, right?\n\n> >Anyway, \"git merge\" with a range simply makes no sense at all\n> >given how git's merge works (opposed to svn's idea of merging,\n> >which is about changes, not about histories). If you want a squash\n> >flag, tell cherry-pick to handle ranges and teach such a flag to\n> >it.\n> \n> And tell \"merge\" to tell me that if I try, so that if I try\n> \n> $ git merge A..B\n> \n> I would get a message saying something like\n> \n> Cannot merge a range of commits. Try \"git cherry-pick A..B\" or\n> \"git rebase --reverse A..B\".\n\nHm, for an error message that \"range of commits\" is probably on the edge\nof being confusing. After all \"git merge B\" will create a new commit M\nthat \"says\" that M^1..M^2 was merged to M^1. But I can't come up with a\nbetter error message either.\n\n> And perhaps we could also in the same way retire --squash?\n> \n> $ git merge --squash B\n> The \"--squash\" option is obsolete. Please use \"git cherry-pick\n> --squash B\".\n\ngit cherry-pick --squash ..B # Not just B itself, but the whole range\n\n> (with a transition period where it would just call the other). Or\n> whatever the options to simulate the old behaviour would be. This\n> would make it clearer that \"merge\" preserves history while\n> \"cherry-pick\" and \"rebase\" do not.\n\nI'd certainly like that.\n\nBjoern\n"},{"id":"129700","messageId":"7vpr6mkaoz.fsf@alter.siamese.dyndns.org","threadId":"21903","inReplyTo":"20091210074358.GA7723@atjola.homenet","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-12-10T17:20:28Z","receivedAt":"2009-12-10T17:20:28Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Björn Steinbrink writes:\n\n>> But at the conceptual level, \"merge --squash\" is a short-hand for this\n>> command sequence:\n>> \n>> git rebase -i HEAD that-branch\n>> ... make everything except the first one into \"squash\"\n>> git checkout - ;# come back to the original branch\n>> git merge that-branch ;# fast forward to it\n>> \n>> So after all, it is \"merge it after squashing them\".\n>\n> To me, that approach looks backwards,...\n\nYes, of course, but what you are missing (and I am at blame for forgetting\nto mention the history behind this in the message you are responding to)\nis that \"merge --squash\" to support a particular need/use case was done\nway before \"rebase -i\" came into existence.\n\nHere is how \"merge --squash\" is explained in the log message:\n\n git-merge --squash\n \n Some people tend to do many little commits on a topic branch,\n recording all the trials and errors, and when the topic is\n reasonably cooked well, would want to record the net effect of\n the series as one commit on top of the mainline, removing the\n cruft from the history. The topic is then abandoned or forked\n off again from that point at the mainline.\n\nA nicer workflow may be to use \"rebase -i\" to clean up the history before\neven contemplating to integrate the topic to the mainline, instead of the\nabove \"abandoning or forking off again\", if you know today's git. \n\nBut interactive was not available back then. It was introduced at 1b1dce4\n(Teach rebase an interactive mode, 2007-06-25), which is 1 year after\n7d0c688 (git-merge --squash, 2006-06-23).\n"},{"id":"129741","messageId":"20091211110720.GA19232@atjola.homenet","threadId":"21903","inReplyTo":"7vpr6mkaoz.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-12-11T11:07:20Z","receivedAt":"2009-12-11T11:07:20Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.12.10 09:20:28 -0800, Junio C Hamano wrote:\n> Björn Steinbrink writes:\n> \n> >> But at the conceptual level, \"merge --squash\" is a short-hand for this\n> >> command sequence:\n> >> \n> >> git rebase -i HEAD that-branch\n> >> ... make everything except the first one into \"squash\"\n> >> git checkout - ;# come back to the original branch\n> >> git merge that-branch ;# fast forward to it\n> >> \n> >> So after all, it is \"merge it after squashing them\".\n> >\n> > To me, that approach looks backwards,...\n> \n> Yes, of course, but what you are missing (and I am at blame for forgetting\n> to mention the history behind this in the message you are responding to)\n> is that \"merge --squash\" to support a particular need/use case was done\n> way before \"rebase -i\" came into existence.\n\nHm? You started explaining that \"merge --squash\" would be right because\nyou can do it via some command sequence that involves rebase -i and then\nmerge. I said that using that rebase+merge sequence as an argument for\nthe choice of the name is wrong. It would even have made more sense to\nme if you said:\n\ngit merge that-branch\ngit reset --soft HEAD^\ngit commit -C ORIG_HEAD\n\nWhich is \"merge, but then drop the extra parents\", which pretty close to\nwhat \"merge --squash\" does (and that sequence even gets it right not to\nrewrite that-branch).\n\nI'm not arguing that you shouldn't have chosen \"merge --squash\" to do\nthat. You couldn't possibly foresee the future and that git might get\nrebase -i or maybe at some day cherry-pick -i . I'm just saying\nthat in retrospective, it's sad that merge doesn't always mean \"merge\nhistories\", but that --squash makes it degenerate to \"merge changes\".\n\nI don't see why you're trying to defend the choice of \"merge --squash\"\nusing a IMHO rather weird command sequence that happens to involve\n\"merge\", using commands that weren't present when \"merge --squash\" was\nadded, but at the same ignore the \"cherry-pick -i \" command git\nmight learn in the near future, which allows for a much saner\nexplanation:\n\ngit cherry-pick -i ..that-branch\n... make everything except the first one into \"squash\"\n\nAnd given that, one could add a --squash flag to cherry-pick that makes\nit do the \"squash everything\" itself, allowing it to be a bit smarter\nabout the whole thing, because it could use a three-way merge\ninternally, instead of cherry-picking all the individual commits. Making\n\"git cherry-pick --squash ..that-branch\" the same as \"git merge --squash\nthat-branch\".\n\n> A nicer workflow may be to use \"rebase -i\" to clean up the history before\n> even contemplating to integrate the topic to the mainline, instead of the\n> above \"abandoning or forking off again\", if you know today's git. \n\nWell, I'm not saying that git should completely lose the abilitiy to do\nsomething like \"merge --squash\", just that if it learns \"git cherry-pick\n\", it might as well get the --squash thing for cherry-pick, maybe\nallowing for \"merge --squash\" to be phased out. And heck, having it as\nan option to cherry-pick instead of merge would probably already help a\nlot to make people realise that it won't remember that the changes got\n\"integrated\". We've had people on #git that wondered why repeated \"git\nmerge --squash\" commands would try to merge the same stuff over and over\nagain, leading to the same conflicts every time. Because they didn't\nrealise that with --squash, \"git merge\" is no longer about merging\nhistories.\n\n> But interactive was not available back then. It was introduced at 1b1dce4\n> (Teach rebase an interactive mode, 2007-06-25), which is 1 year after\n> 7d0c688 (git-merge --squash, 2006-06-23).\n\nAgain, I'm not blaming you for having chosen that command back then.\nJust saying that it might be better to have the same functionality in an\nextended cherry-pick now.\n\nBjörn\n"},{"id":"129817","messageId":"87ws0q5w5z.fsf@lysator.liu.se","threadId":"21903","inReplyTo":"7vfx7lcj18.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH RFC] rebase: add --revisions flag","fromName":"David Kågedal","fromEmail":"davidk@lysator.liu.se","sentAt":"2009-12-13T22:47:04Z","receivedAt":"2009-12-13T22:47:04Z","isPatch":true,"sender":{"key":"davidk@lysator.liu.se","avatar":"https://avatars.githubusercontent.com/u/60530?v=4"},"body":"Junio C Hamano writes:\n\n> \"Michael S. Tsirkin\" writes:\n>\n>> Add --revisions flag to rebase, so that it can be used\n>> to apply an arbitrary range of commits on top\n>> of a current branch.\n>\n> I would suggest calling the option to invoke that hidden mode not\n> \"--revisions\", but \"--reverse\" or \"--opposite\" or something of that\n> nature, though. It makes \"rebase\" work in different direction.\n\nAnd there are no \"revisions\" in git. So using that term for anything\nwould only be confusing. Git has \"commits\" and various kinds of\nreferences to them.\n\n-- \nDavid Kågedal\n"}]}