{"thread":{"id":"16193","subject":"multiple-commit cherry-pick?","startedAt":"2008-11-06T02:45:27Z","lastAt":"2008-11-16T09:11:02Z","messageCount":31,"participants":["Miles Bader","Deskin Miller","Björn Steinbrink","Alex Riesen","Linus Torvalds","Junio C Hamano","Michael Radziej","Johannes Schindelin","Chris Frey","Francis Galiegue","Pierre Habouzit"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"95023","messageId":"buoiqr18tdk.fsf@dhapc248.dev.necel.com","threadId":"16193","inReplyTo":null,"subject":"multiple-commit cherry-pick?","fromName":"Miles Bader","fromEmail":"miles.bader@necel.com","sentAt":"2008-11-06T02:45:27Z","receivedAt":"2008-11-06T02:45:27Z","isPatch":false,"sender":{"key":"miles.bader@necel.com","avatar":"https://gravatar.com/avatar/be062d4050eb88e04229cbdb60f803e1bd647923a015996c2439e76f23e336a7?d=mp&s=160"},"body":"Is there any easy way to cherry pick a _range_ of commits from some other\nbranch to the current branch, instead of just one?\n\nI thought maybe git-rebase could be coerced to do this somehow, but I\ncouldn't figure a way.  [Using git-rebase would be nice because of all the\nuseful tools it provides, e.g., the --abort, --continue, and -i options.]\n\nThanks,\n\n-Miles\n\n-- \nP.S.  All information contained in the above letter is false,\n      for reasons of military security.\n"},{"id":"95025","messageId":"20081106032437.GA27237@euler","threadId":"16193","inReplyTo":"buoiqr18tdk.fsf@dhapc248.dev.necel.com","subject":"Re: multiple-commit cherry-pick?","fromName":"Deskin Miller","fromEmail":"deskinm@umich.edu","sentAt":"2008-11-06T03:24:37Z","receivedAt":"2008-11-06T03:24:37Z","isPatch":false,"sender":{"key":"deskinm@umich.edu","avatar":"https://gravatar.com/avatar/d340a0e612cdf0a79535c71863c0b4c535e9aba63b42032226ae903e638b64f9?d=mp&s=160"},"body":"On Thu, Nov 06, 2008 at 11:45:27AM +0900, Miles Bader wrote:\n> Is there any easy way to cherry pick a _range_ of commits from some other\n> branch to the current branch, instead of just one?\n> \n> I thought maybe git-rebase could be coerced to do this somehow, but I\n> couldn't figure a way.\n\nRebase is exactly what you want.  Given something like this:\n\no--o--o--A--B--C--o--o--X\n    \\\n     o--o--D\n\nwhere you want A, B, C to go on top of D:\n\n$ git checkout -b newbranch C\n$ git rebase --onto D ^A\n\nnewbranch will have <...> --D--A--B--C\n\nHope that helps,\nDeskin Miller\n"},{"id":"95037","messageId":"20081106095122.GA2656@atjola.homenet","threadId":"16193","inReplyTo":"20081106032437.GA27237@euler","subject":"Re: multiple-commit cherry-pick?","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2008-11-06T09:51:22Z","receivedAt":"2008-11-06T09:51:22Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2008.11.05 22:24:37 -0500, Deskin Miller wrote:\n> On Thu, Nov 06, 2008 at 11:45:27AM +0900, Miles Bader wrote:\n> > Is there any easy way to cherry pick a _range_ of commits from some other\n> > branch to the current branch, instead of just one?\n> > \n> > I thought maybe git-rebase could be coerced to do this somehow, but I\n> > couldn't figure a way.\n> \n> Rebase is exactly what you want.  Given something like this:\n> \n> o--o--o--A--B--C--o--o--X\n>     \\\n>      o--o--D\n> \n> where you want A, B, C to go on top of D:\n> \n> $ git checkout -b newbranch C\n> $ git rebase --onto D ^A\n\nThat should be A^ ;-)\n\n> newbranch will have <...> --D--A--B--C\n\n... and then you can merge newbranch into the existing branch that\nreferences D, fast-forwarding the branch. And then newbranch can be\ndeleted.\n\nIf you don't want to use a temporary branch, you can also do (while on\nthe branch onto which you want to cherry-pick):\n\ngit reset --hard C\ngit rebase --onto ORIG_HEAD A^\n\nWhich should get you the same result, without using a temporary branch.\n\nBjörn\n"},{"id":"95045","messageId":"buozlkd6oh1.fsf@dhapc248.dev.necel.com","threadId":"16193","inReplyTo":"20081106095122.GA2656@atjola.homenet","subject":"Re: multiple-commit cherry-pick?","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2008-11-06T12:14:18Z","receivedAt":"2008-11-06T12:14:18Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Björn Steinbrink <B.Steinbrink@gmx.de> writes:\n> git reset --hard C\n> git rebase --onto ORIG_HEAD A^\n\nIs that safe...?  Doesn't git-rebase also set ORIG_HEAD?\n\n-Miles\n\n-- \nTwice, adv. Once too often.\n"},{"id":"95047","messageId":"20081106122658.GB4192@atjola.homenet","threadId":"16193","inReplyTo":"buozlkd6oh1.fsf@dhapc248.dev.necel.com","subject":"Re: multiple-commit cherry-pick?","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2008-11-06T12:26:58Z","receivedAt":"2008-11-06T12:26:58Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2008.11.06 21:14:18 +0900, Miles Bader wrote:\n> Björn Steinbrink <B.Steinbrink@gmx.de> writes:\n> > git reset --hard C\n> > git rebase --onto ORIG_HEAD A^\n> \n> Is that safe...?  Doesn't git-rebase also set ORIG_HEAD?\n\nOne of the first things rebase does is validating and resolving its\narguments. And that's happening before any actions that would touch\nORIG_HEAD. Though I'm not sure if it's always been like that.\n\nBjörn\n"},{"id":"95081","messageId":"20081106213711.GA4334@blimp.localdomain","threadId":"16193","inReplyTo":"buoiqr18tdk.fsf@dhapc248.dev.necel.com","subject":"Re: multiple-commit cherry-pick?","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-11-06T21:37:11Z","receivedAt":"2008-11-06T21:37:11Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Miles Bader, Thu, Nov 06, 2008 03:45:27 +0100:\n> Is there any easy way to cherry pick a _range_ of commits from some other\n> branch to the current branch, instead of just one?\n> \n> I thought maybe git-rebase could be coerced to do this somehow, but I\n> couldn't figure a way.  [Using git-rebase would be nice because of all the\n> useful tools it provides, e.g., the --abort, --continue, and -i options.]\n> \n\ngit format-patch --full-index --binary --stdout <range...> | git am -3\n\nThis will not work if you want to pick a list, not a range, of\ncommits.\n"},{"id":"95097","messageId":"alpine.LFD.2.00.0811061925300.3451@nehalem.linux-foundation.org","threadId":"16193","inReplyTo":"20081106213711.GA4334@blimp.localdomain","subject":"Re: multiple-commit cherry-pick?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-11-07T03:29:04Z","receivedAt":"2008-11-07T03:29:04Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 6 Nov 2008, Alex Riesen wrote:\n> \n> git format-patch --full-index --binary --stdout <range...> | git am -3\n> \n> This will not work if you want to pick a list, not a range, of\n> commits.\n\nDoesn't \"--no-walk\" + list commits individually work?\n\nSo it _should_ be possible to pick a list of commits too. Although I think \nthat git format-patch will reverse the order.\n\n\t\tLinus\n"},{"id":"95098","messageId":"fc339e4a0811062038x22e7a3co503f09678f9ff5aa@mail.gmail.com","threadId":"16193","inReplyTo":"alpine.LFD.2.00.0811061925300.3451@nehalem.linux-foundation.org","subject":"Re: multiple-commit cherry-pick?","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2008-11-07T04:38:16Z","receivedAt":"2008-11-07T04:38:16Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":">> git format-patch --full-index --binary --stdout <range...> | git am -3\n>>\n>> This will not work if you want to pick a list, not a range, of\n>> commits.\n>\n> Doesn't \"--no-walk\" + list commits individually work?\n>\n> So it _should_ be possible to pick a list of commits too. Although I think\n> that git format-patch will reverse the order.\n\nIncidentally, the reason I like a rebase-based solution is that many\nof the rebase features like -i, --abort, and --continue (after\nconflict resolution) are very nice for the multi-cherry-pick case too,\nand I'm already very familiar with their operation from using rebase.\n\n[git-am seems to have some similar features, but I don't know how well\nthey work.]\n\n-Miles\n\n-- \nDo not taunt Happy Fun Ball.\n"},{"id":"95099","messageId":"7vskq4gmf5.fsf@gitster.siamese.dyndns.org","threadId":"16193","inReplyTo":"alpine.LFD.2.00.0811061925300.3451@nehalem.linux-foundation.org","subject":"Re: multiple-commit cherry-pick?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-11-07T05:00:46Z","receivedAt":"2008-11-07T05:00:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@linux-foundation.org> writes:\n\n> On Thu, 6 Nov 2008, Alex Riesen wrote:\n>> \n>> git format-patch --full-index --binary --stdout <range...> | git am -3\n>> \n>> This will not work if you want to pick a list, not a range, of\n>> commits.\n>\n> Doesn't \"--no-walk\" + list commits individually work?\n>\n> So it _should_ be possible to pick a list of commits too. Although I think \n> that git format-patch will reverse the order.\n\nOr \"git show --pretty=email $commit1 $commit2\" ... piped to \"am\"?\n"},{"id":"95100","messageId":"buozlkcqg0c.fsf@dhapc248.dev.necel.com","threadId":"16193","inReplyTo":"20081106122658.GB4192@atjola.homenet","subject":"Re: multiple-commit cherry-pick?","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2008-11-07T05:09:07Z","receivedAt":"2008-11-07T05:09:07Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Björn Steinbrink <B.Steinbrink@gmx.de> writes:\n>> > git reset --hard C\n>> > git rebase --onto ORIG_HEAD A^\n>> \n>> Is that safe...?  Doesn't git-rebase also set ORIG_HEAD?\n>\n> One of the first things rebase does is validating and resolving its\n> arguments. And that's happening before any actions that would touch\n> ORIG_HEAD.\n\nAh, I see.\n\nHmm, I guess using rebase --abort isn't a very good idea in this case\nthough... :-/\n\nKind of a shame, since it's nice being to just abort the whole operation\nif it turns out you did something wrong and aren't sure how to recover.\n\nThanks,\n\n-Miles\n\n-- \nKilt, n. A costume sometimes worn by Scotchmen [sic] in America and Americans\nin Scotland.\n"},{"id":"95102","messageId":"20081107071231.GA4063@blimp.localdomain","threadId":"16193","inReplyTo":"7vskq4gmf5.fsf@gitster.siamese.dyndns.org","subject":"Re: multiple-commit cherry-pick?","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-11-07T07:12:31Z","receivedAt":"2008-11-07T07:12:31Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Junio C Hamano, Fri, Nov 07, 2008 06:00:46 +0100:\n> Linus Torvalds <torvalds@linux-foundation.org> writes:\n> \n> > On Thu, 6 Nov 2008, Alex Riesen wrote:\n> >> \n> >> git format-patch --full-index --binary --stdout <range...> | git am -3\n> >> \n> >> This will not work if you want to pick a list, not a range, of\n> >> commits.\n> >\n> > Doesn't \"--no-walk\" + list commits individually work?\n> >\n> > So it _should_ be possible to pick a list of commits too. Although I think \n> > that git format-patch will reverse the order.\n> \n> Or \"git show --pretty=email $commit1 $commit2\" ... piped to \"am\"?\n> \n\nDoes not work if there are ranges given :-/\nIt'd be very nice to have: git show #c1..$c2 $c3 $c4 $c5..$c6\n"},{"id":"95103","messageId":"20081107071301.GB4063@blimp.localdomain","threadId":"16193","inReplyTo":"fc339e4a0811062038x22e7a3co503f09678f9ff5aa@mail.gmail.com","subject":"Re: multiple-commit cherry-pick?","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-11-07T07:13:01Z","receivedAt":"2008-11-07T07:13:01Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Miles Bader, Fri, Nov 07, 2008 05:38:16 +0100:\n> [git-am seems to have some similar features, but I don't know how well\n> they work.]\n\nThey work well.\n"},{"id":"95114","messageId":"20081107104630.GB12424@noris.de","threadId":"16193","inReplyTo":"7vskq4gmf5.fsf@gitster.siamese.dyndns.org","subject":"Re: multiple-commit cherry-pick?","fromName":"Michael Radziej","fromEmail":"mir@noris.de","sentAt":"2008-11-07T10:46:30Z","receivedAt":"2008-11-07T10:46:30Z","isPatch":false,"sender":{"key":"mir@noris.de","avatar":null},"body":"On Thu, Nov 06, Junio C Hamano wrote:\n> Or \"git show --pretty=email $commit1 $commit2\" ... piped to \"am\"?\n\nOr make git show write shell commands.\n\nI often have commits that later need to be cherry-picked into other\nbranches. For these, I use a commit message that starts with the name of the\nbranch, like \"implement-foo: make foo barfy\". Later when I want to do the\ncherry-picking, I use this:\n\ngit log t/whatever..master --reverse --pretty=tformat:'git cherry-pick %h #\n%s' | sed 's/^\\([^:]*\\) \\([^:]*\\):/git checkout \\2 \\&\\& \\1/'\n\ngiving me output like:\n\ngit checkout implement-foo && git cherry-pick 90ce727 # make foo barfy\ngit checkout ...\n\n... and I'm ready for cut'n'paste.\n\n\n\nMichael\n\n\n-- \nnoris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -\nTel +49-911-9352-0 - Fax +49-911-9352-100\nhttp://www.noris.de - The IT-Outsourcing Company\n \nVorstand: Ingo Kraupa (Vorsitzender), Joachim Astel, Hansjochen Klenk - \nVorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689\n"},{"id":"95115","messageId":"20081107110331.GA2938@atjola.homenet","threadId":"16193","inReplyTo":"buozlkcqg0c.fsf@dhapc248.dev.necel.com","subject":"Re: multiple-commit cherry-pick?","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2008-11-07T11:03:31Z","receivedAt":"2008-11-07T11:03:31Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2008.11.07 14:09:07 +0900, Miles Bader wrote:\n> Björn Steinbrink <B.Steinbrink@gmx.de> writes:\n> >> > git reset --hard C\n> >> > git rebase --onto ORIG_HEAD A^\n> >> \n> >> Is that safe...?  Doesn't git-rebase also set ORIG_HEAD?\n> >\n> > One of the first things rebase does is validating and resolving its\n> > arguments. And that's happening before any actions that would touch\n> > ORIG_HEAD.\n> \n> Ah, I see.\n> \n> Hmm, I guess using rebase --abort isn't a very good idea in this case\n> though... :-/\n\nWhy not? I mean, ok, you end up at C, and not where you have been before\nthe reset --hard, but there's the reflog to help you get back to\nwhatever previous state of the branch it is that you want.\n\nBjörn\n"},{"id":"95117","messageId":"fc339e4a0811070346k69c302bdnfcb59adf0036b5ea@mail.gmail.com","threadId":"16193","inReplyTo":"20081107110331.GA2938@atjola.homenet","subject":"Re: multiple-commit cherry-pick?","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2008-11-07T11:46:49Z","receivedAt":"2008-11-07T11:46:49Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":">> >> > git reset --hard C\n>> >> > git rebase --onto ORIG_HEAD A^\n\n>> Hmm, I guess using rebase --abort isn't a very good idea in this case\n>> though... :-/\n>\n> Why not? I mean, ok, you end up at C, and not where you have been before\n> the reset --hard, but there's the reflog to help you get back to\n> whatever previous state of the branch it is that you want.\n\nI just mean it's not a trivial way to get back to the state before the\nmulti-cherry-pick -- you need to know the details of what's going on,\nand handle the rest of the cleanup manually.\n\nSo, for instance, if you were to package up the above commands in a\nshell script, the abort issue is one of those rough edges which would\nprevent it from being as convenient as a real git command.  [A\nhypothetical extension of the cherry-pick command to handle multiple\ncommits would presumably offer a \"cherry-pick --abort\" option that did\neverything magically.]\n\n-Miles\n\n-- \nDo not taunt Happy Fun Ball.\n"},{"id":"95133","messageId":"alpine.LFD.2.00.0811071004170.3468@nehalem.linux-foundation.org","threadId":"16193","inReplyTo":"20081107071231.GA4063@blimp.localdomain","subject":"Re: multiple-commit cherry-pick?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-11-07T18:08:36Z","receivedAt":"2008-11-07T18:08:36Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 7 Nov 2008, Alex Riesen wrote:\n> \n> Does not work if there are ranges given :-/\n> It'd be very nice to have: git show #c1..$c2 $c3 $c4 $c5..$c6\n\nYeah, we've very fundamentally never supported that. Not for show, but \nalso not for anything else (ie \"gitk a..b c..d\" does _not_ give you two \nranges).\n\nIt's easy to see why once you understand what 'a..b' really means (ie it \njust expands to '^a' and 'b'), and how it's not really a \"range\" operation \nas much as a set operation that interacts with all the other arguments \ntoo. But unless you're very aware of that, it can be surprising.\n\n\t\tLinus\n"},{"id":"95350","messageId":"20081109102528.GA5463@blimp.localdomain","threadId":"16193","inReplyTo":"alpine.LFD.2.00.0811071004170.3468@nehalem.linux-foundation.org","subject":"Re: multiple-commit cherry-pick?","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-11-09T10:25:28Z","receivedAt":"2008-11-09T10:25:28Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Linus Torvalds, Fri, Nov 07, 2008 19:08:36 +0100:\n> On Fri, 7 Nov 2008, Alex Riesen wrote:\n> > \n> > Does not work if there are ranges given :-/\n> > It'd be very nice to have: git show #c1..$c2 $c3 $c4 $c5..$c6\n> \n> Yeah, we've very fundamentally never supported that. Not for show, but \n> also not for anything else (ie \"gitk a..b c..d\" does _not_ give you two \n> ranges).\n> \n> It's easy to see why once you understand what 'a..b' really means (ie it \n> just expands to '^a' and 'b'), and how it's not really a \"range\" operation \n> as much as a set operation that interacts with all the other arguments \n> too. But unless you're very aware of that, it can be surprising.\n> \n\nOh, I am. But it is just so convenient to have range support for\ncommands which just show commits. Besides, git-show just errors out,\ninstead of producing the commits like git-log does.\n"},{"id":"95366","messageId":"alpine.DEB.1.00.0811102054470.30769@pacific.mpi-cbg.de","threadId":"16193","inReplyTo":"20081109102528.GA5463@blimp.localdomain","subject":"Re: multiple-commit cherry-pick?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-11-10T19:58:11Z","receivedAt":"2008-11-10T19:58:11Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 9 Nov 2008, Alex Riesen wrote:\n\n> Linus Torvalds, Fri, Nov 07, 2008 19:08:36 +0100:\n> > On Fri, 7 Nov 2008, Alex Riesen wrote:\n> > > \n> > > Does not work if there are ranges given :-/\n> > > It'd be very nice to have: git show #c1..$c2 $c3 $c4 $c5..$c6\n> > \n> > Yeah, we've very fundamentally never supported that. Not for show, but \n> > also not for anything else (ie \"gitk a..b c..d\" does _not_ give you \n> > two ranges).\n> > \n> > It's easy to see why once you understand what 'a..b' really means (ie \n> > it just expands to '^a' and 'b'), and how it's not really a \"range\" \n> > operation as much as a set operation that interacts with all the other \n> > arguments too. But unless you're very aware of that, it can be \n> > surprising.\n> > \n> \n> Oh, I am. But it is just so convenient to have range support for \n> commands which just show commits. Besides, git-show just errors out, \n> instead of producing the commits like git-log does.\n\nHave fun implementing the support, and then explaining to users why this \nshows only one commit:\n\n\tgit show HEAD^..HEAD HEAD~10\n\nCiao,\nDscho\n"},{"id":"95372","messageId":"81b0412b0811101224gcffc958o6dbfcdc45e022874@mail.gmail.com","threadId":"16193","inReplyTo":"alpine.DEB.1.00.0811102054470.30769@pacific.mpi-cbg.de","subject":"Re: multiple-commit cherry-pick?","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-11-10T20:24:22Z","receivedAt":"2008-11-10T20:24:22Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"2008/11/10 Johannes Schindelin <Johannes.Schindelin@gmx.de>:\n> On Sun, 9 Nov 2008, Alex Riesen wrote:\n>>\n>> Oh, I am. But it is just so convenient to have range support for\n>> commands which just show commits. Besides, git-show just errors out,\n>> instead of producing the commits like git-log does.\n>\n> Have fun implementing the support, and then explaining to users why this\n> shows only one commit:\n>\n>        git show HEAD^..HEAD HEAD~10\n>\n\nfor cs in HEAD^..HEAD HEAD~10; do\n  case \"$cs\"; in\n  *..*)\n     git format-patch --stdout \"$cs\"\n     ;;\n  *)\n     git show --pretty=email \"$cs\"\n     ;;\n  esac\ndone\n\nAt least, this is what I have in mind and how I expect it to work.\n"},{"id":"95383","messageId":"7vabc75n5q.fsf@gitster.siamese.dyndns.org","threadId":"16193","inReplyTo":"alpine.DEB.1.00.0811102054470.30769@pacific.mpi-cbg.de","subject":"Re: multiple-commit cherry-pick?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-11-10T20:41:37Z","receivedAt":"2008-11-10T20:41:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> On Sun, 9 Nov 2008, Alex Riesen wrote:\n>\n>> Oh, I am. But it is just so convenient to have range support for \n>> commands which just show commits. Besides, git-show just errors out, \n>> instead of producing the commits like git-log does.\n>\n> Have fun implementing the support, and then explaining to users why this \n> shows only one commit:\n>\n> \tgit show HEAD^..HEAD HEAD~10\n\nI find what Alex says somewhat silly because show is always \"no walk\", and\nrange by definition means you need to walk.\n\nBut when you give that command line, Alex could also change the command to\nshow the HEAD and HEAD~10, by changing the way series of range parameters\nare evaluated by the revision parsing machinery.  You take HEAD^..HEAD and\ncome up with one set (that has only one commit, HEAD), you take the next\nparameter HEAD~10 and come up with another set (that also has only one\ncommit, HEAD~10, because show does not walk), then you take union.\n\nI personally do not want to see that happen, though.  The way multiple\n\"ranges\" that come from separate command line parameters combine using set\noperator semantics is so useful to do something like...\n\n\tgit log ko/master..master ^maint\n\nwhich is my way to ask \"Which commits on master are the ones that I\nhaven't pushed out?  By the way, I have pushed out maint already so I do\nnot want to see anything that is already in maint\", where ko/master tracks\nwhat I pushed out to the public repository at k.org; this query is used to\nsee if I can still rewrite commits when I find typo/thinko in them.\n"},{"id":"95389","messageId":"alpine.DEB.1.00.0811102230330.30769@pacific.mpi-cbg.de","threadId":"16193","inReplyTo":"81b0412b0811101224gcffc958o6dbfcdc45e022874@mail.gmail.com","subject":"Re: multiple-commit cherry-pick?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-11-10T21:31:32Z","receivedAt":"2008-11-10T21:31:32Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 10 Nov 2008, Alex Riesen wrote:\n\n> 2008/11/10 Johannes Schindelin <Johannes.Schindelin@gmx.de>:\n> > On Sun, 9 Nov 2008, Alex Riesen wrote:\n> >>\n> >> Oh, I am. But it is just so convenient to have range support for\n> >> commands which just show commits. Besides, git-show just errors out,\n> >> instead of producing the commits like git-log does.\n> >\n> > Have fun implementing the support, and then explaining to users why this\n> > shows only one commit:\n> >\n> >        git show HEAD^..HEAD HEAD~10\n> >\n> \n> for cs in HEAD^..HEAD HEAD~10; do\n>   case \"$cs\"; in\n>   *..*)\n>      git format-patch --stdout \"$cs\"\n>      ;;\n>   *)\n>      git show --pretty=email \"$cs\"\n>      ;;\n>   esac\n> done\n> \n> At least, this is what I have in mind and how I expect it to work.\n\nThat is not the way git-show is implemented (it uses setup_revisions() to \ncheck for validity and to parse the arguments), and I cannot think of any \nway to make this work without ugly workarounds.\n\nCiao,\nDscho\n"},{"id":"95390","messageId":"alpine.DEB.1.00.0811102234040.30769@pacific.mpi-cbg.de","threadId":"16193","inReplyTo":"7vabc75n5q.fsf@gitster.siamese.dyndns.org","subject":"Re: multiple-commit cherry-pick?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-11-10T21:34:49Z","receivedAt":"2008-11-10T21:34:49Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 10 Nov 2008, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> Alex could also change the command to show the HEAD and HEAD~10, by \n> changing the way series of range parameters are evaluated by the \n> revision parsing machinery.  You take HEAD^..HEAD and come up with one \n> set (that has only one commit, HEAD), you take the next parameter \n> HEAD~10 and come up with another set (that also has only one commit, \n> HEAD~10, because show does not walk), then you take union.\n> \n> I personally do not want to see that happen, though.  The way multiple\n> \"ranges\" that come from separate command line parameters combine using set\n> operator semantics is so useful to do something like...\n> \n> \tgit log ko/master..master ^maint\n> \n> which is my way to ask \"Which commits on master are the ones that I\n> haven't pushed out?\n\nExactly one of my use cases, since we do not have ko/master,maint..master.\n\nCiao,\nDscho\n"},{"id":"95763","messageId":"20081114050822.GA23963@foursquare.net","threadId":"16193","inReplyTo":"alpine.DEB.1.00.0811102230330.30769@pacific.mpi-cbg.de","subject":"Re: multiple-commit cherry-pick?","fromName":"Chris Frey","fromEmail":"cdfrey@foursquare.net","sentAt":"2008-11-14T05:08:22Z","receivedAt":"2008-11-14T05:08:22Z","isPatch":false,"sender":{"key":"cdfrey@foursquare.net","avatar":null},"body":"On Mon, Nov 10, 2008 at 10:31:32PM +0100, Johannes Schindelin wrote:\n> On Mon, 10 Nov 2008, Alex Riesen wrote:\n> > for cs in HEAD^..HEAD HEAD~10; do\n> >   case \"$cs\"; in\n> >   *..*)\n> >      git format-patch --stdout \"$cs\"\n> >      ;;\n> >   *)\n> >      git show --pretty=email \"$cs\"\n> >      ;;\n> >   esac\n> > done\n> > \n> > At least, this is what I have in mind and how I expect it to work.\n> \n> That is not the way git-show is implemented (it uses setup_revisions() to \n> check for validity and to parse the arguments), and I cannot think of any \n> way to make this work without ugly workarounds.\n\nWould it be possible to add \"range\" support to a subset of commands by\nusing a git-range wrapper?\n\nHypothetical, pie-in-the-sky idea:\n\n\tgit range HEAD^..HEAD HEAD~10 -- show --pretty=email\n\tgit range HEAD^..HEAD HEAD~10 -- log\n\tgit range HEAD^..HEAD HEAD~10 -- cherry-pick\n\nWhich would call the given command for each of the commits found in all\nthe specified ranges and lists.  git-range could have an internal list\nof supported git subcommands that it would massage the parameter lists for.\n\nI find this both elegant and ugly at the same time. :-)\n\n- Chris\n"},{"id":"95786","messageId":"alpine.DEB.1.00.0811141452550.30769@pacific.mpi-cbg.de","threadId":"16193","inReplyTo":"20081114050822.GA23963@foursquare.net","subject":"Re: multiple-commit cherry-pick?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-11-14T14:00:51Z","receivedAt":"2008-11-14T14:00:51Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 14 Nov 2008, Chris Frey wrote:\n\n> On Mon, Nov 10, 2008 at 10:31:32PM +0100, Johannes Schindelin wrote:\n> > On Mon, 10 Nov 2008, Alex Riesen wrote:\n> > > for cs in HEAD^..HEAD HEAD~10; do\n> > >   case \"$cs\"; in\n> > >   *..*)\n> > >      git format-patch --stdout \"$cs\"\n> > >      ;;\n> > >   *)\n> > >      git show --pretty=email \"$cs\"\n> > >      ;;\n> > >   esac\n> > > done\n> > > \n> > > At least, this is what I have in mind and how I expect it to work.\n> > \n> > That is not the way git-show is implemented (it uses setup_revisions() to \n> > check for validity and to parse the arguments), and I cannot think of any \n> > way to make this work without ugly workarounds.\n> \n> Would it be possible to add \"range\" support to a subset of commands by\n> using a git-range wrapper?\n> \n> Hypothetical, pie-in-the-sky idea:\n> \n> \tgit range HEAD^..HEAD HEAD~10 -- show --pretty=email\n> \tgit range HEAD^..HEAD HEAD~10 -- log\n> \tgit range HEAD^..HEAD HEAD~10 -- cherry-pick\n\nThis is not really well defined is it?  What about\n\n\tgit range HEAD -- log makefile\n\nWhere should it insert the \"HEAD\" argument?\n\nBesides, I do not like how this muddies the semantics: if git range as you \nproposed it became part of Git, people _would_ get confused why \"git range \nHEAD^..HEAD HEAD~10\" interprets the range _differently_ from \"git log \nHEAD^..HEAD HEAD~10\".\n\nCiao,\nDscho\n"},{"id":"95796","messageId":"alpine.LFD.2.00.0811140800540.3468@nehalem.linux-foundation.org","threadId":"16193","inReplyTo":"20081114050822.GA23963@foursquare.net","subject":"Re: multiple-commit cherry-pick?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-11-14T16:11:41Z","receivedAt":"2008-11-14T16:11:41Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 14 Nov 2008, Chris Frey wrote:\n> \n> Would it be possible to add \"range\" support to a subset of commands by\n> using a git-range wrapper?\n\nIt would be better to just extend the SHA-1 arithmetic. We could do it, no \nproblem. It's just a SMOP.\n\nFor example, right now the arithmetic is entirely \"flat\", with no \nprecedence, no nesting, nothing but a single level of set operations. We \ncould extend it to be hierarchical.\n\nSo we _could_ do something like\n\n\tgit log {a..b} {c..d ^e}\n\nand just declare that { $args } is a self-contained \"subset\", and \neffectively becomes the same thing as \"$(git rev-list $args)\" but with \nmagic no-walking semantics (ie all walking is done only _within_ the { }, \nnot between different groups.\n\nYou literally _can_ do it right now that way:\n\n\tgit log --no-walk $(git rev-list HEAD~5..HEAD~3) $(git rev-list HEAD~1..)\n\nactually works, but that will hit argument size limits on many platforms \nreally quickly.\n\nSo we could make a '{ }' in the argument space basically do a SHA1 \nexpansion of the range inside, and imply --no-walk. It's _not_ entirely \ntrivial, because we'd need to handle the fact that object flags are \nsticky, and clear them in between invocations of multiple ranges, but it's \nnot _fundmanetally_ difficult. It's just that somebody would need to do \nit.\n\n\t\tLinus\n"},{"id":"95798","messageId":"alpine.DEB.1.00.0811141758230.30769@pacific.mpi-cbg.de","threadId":"16193","inReplyTo":"alpine.LFD.2.00.0811140800540.3468@nehalem.linux-foundation.org","subject":"Re: multiple-commit cherry-pick?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-11-14T16:59:22Z","receivedAt":"2008-11-14T16:59:22Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 14 Nov 2008, Linus Torvalds wrote:\n\n> So we _could_ do something like\n> \n> \tgit log {a..b} {c..d ^e}\n> \n> and just declare that { $args } is a self-contained \"subset\", and \n> effectively becomes the same thing as \"$(git rev-list $args)\" but with \n> magic no-walking semantics (ie all walking is done only _within_ the { \n> }, not between different groups.\n> \n> You literally _can_ do it right now that way:\n> \n> \tgit log --no-walk $(git rev-list HEAD~5..HEAD~3) $(git rev-list \n> \tHEAD~1..)\n> \n> actually works, but that will hit argument size limits on many platforms \n> really quickly.\n> \n> So we could make a '{ }' in the argument space basically do a SHA1 \n> expansion of the range inside, and imply --no-walk. It's _not_ entirely \n> trivial, because we'd need to handle the fact that object flags are \n> sticky, and clear them in between invocations of multiple ranges, but \n> it's not _fundmanetally_ difficult. It's just that somebody would need \n> to do it.\n\nWell, do not forget the case\n\n\tgit log ^HEAD^ {HEAD^..HEAD} $BLUB\n\nCiao,\nDscho\n"},{"id":"95801","messageId":"7v1vxeb4il.fsf@gitster.siamese.dyndns.org","threadId":"16193","inReplyTo":"alpine.LFD.2.00.0811140800540.3468@nehalem.linux-foundation.org","subject":"Re: multiple-commit cherry-pick?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-11-14T17:29:06Z","receivedAt":"2008-11-14T17:29:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@linux-foundation.org> writes:\n\n> So we could make a '{ }' in the argument space basically do a SHA1 \n> expansion of the range inside, and imply --no-walk. It's _not_ entirely \n> trivial, because we'd need to handle the fact that object flags are \n> sticky, and clear them in between invocations of multiple ranges, but it's \n> not _fundmanetally_ difficult. It's just that somebody would need to do \n> it.\n\nWouldn't you lose the nice streaming output (iow short latency)?\n"},{"id":"95802","messageId":"alpine.LFD.2.00.0811140936050.3468@nehalem.linux-foundation.org","threadId":"16193","inReplyTo":"7v1vxeb4il.fsf@gitster.siamese.dyndns.org","subject":"Re: multiple-commit cherry-pick?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-11-14T17:41:08Z","receivedAt":"2008-11-14T17:41:08Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 14 Nov 2008, Junio C Hamano wrote:\n> Linus Torvalds <torvalds@linux-foundation.org> writes:\n> \n> > So we could make a '{ }' in the argument space basically do a SHA1 \n> > expansion of the range inside, and imply --no-walk. It's _not_ entirely \n> > trivial, because we'd need to handle the fact that object flags are \n> > sticky, and clear them in between invocations of multiple ranges, but it's \n> > not _fundmanetally_ difficult. It's just that somebody would need to do \n> > it.\n> \n> Wouldn't you lose the nice streaming output (iow short latency)?\n\nOh, absolutely. So the '{x}' format would be not be a replacement for \nnon-{} format - it would be an addition to.\n\nBut it's no different from 'a..b' in that sense: anything that sets \n'revs->limited' automatically forces a synchronous revision walk. So you'd \nbe crazy to do\n\n\tgitk {HEAD}\n\nbecause\n (a) there would be no point\n (b) it indeed loses the streaming data and would become synchronous.\n\nbut if you already do\n\n\tgitk a..b\n\nthen you're _already_ doing a revision limiter and forcing the revision \nwalk to be synchronous, so there would be no interactivity downside \nbetween 'a..b' and '{a..b}'.\n\n\t\tLinus\n"},{"id":"95808","messageId":"alpine.LFD.2.00.0811140945000.3468@nehalem.linux-foundation.org","threadId":"16193","inReplyTo":"alpine.LFD.2.00.0811140936050.3468@nehalem.linux-foundation.org","subject":"Re: multiple-commit cherry-pick?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-11-14T17:55:51Z","receivedAt":"2008-11-14T17:55:51Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 14 Nov 2008, Linus Torvalds wrote:\n> \n> but if you already do\n> \n> \tgitk a..b\n> \n> then you're _already_ doing a revision limiter and forcing the revision \n> walk to be synchronous, so there would be no interactivity downside \n> between 'a..b' and '{a..b}'.\n\nBtw, the biggest problem (I think) is actually non-simple ranges and just \nthe _syntax_ of these things.\n\nIt's entirely reasonable to want to group a more complex expression than \njust a single range. IOW, something like\n\n\tgitk {..origin/pu ^origin/next} {HEAD~5..HEAD~2}\n\nto show a union of what is in 'pu' but not master or next, and the \nsymmetrical difference of the current merge. It's a perfectly sensible \nthing to do. And we _can_ do it right now, just with a nasty syntax:\n\n\tgitk --no-walk $(git rev-list ..origin/pu ^origin/next) $(git rev-list HEAD~5..HEAD~2)\n\nactually works. But look again at how nasty it is to parse the '{x}' \nversion, because the '{..}' thing now spans multiple arguments. \n\n\t\t\tLinus\n"},{"id":"95812","messageId":"200811141938.24734.fg@one2team.com","threadId":"16193","inReplyTo":"alpine.LFD.2.00.0811140800540.3468@nehalem.linux-foundation.org","subject":"Re: multiple-commit cherry-pick?","fromName":"Francis Galiegue","fromEmail":"fg@one2team.com","sentAt":"2008-11-14T18:38:24Z","receivedAt":"2008-11-14T18:38:24Z","isPatch":false,"sender":{"key":"fg@one2team.com","avatar":null},"body":"Le Friday 14 November 2008 17:11:41 Linus Torvalds, vous avez écrit :\n[...]\n>\n> So we _could_ do something like\n>\n> \tgit log {a..b} [...]\n>\n\nI don't know if you really meant this, but entering SHA1s as is at a shell \nprompt may have dangerous side effects... If not right now, then in (some not \nso distant time in) the future. Consider this (I use bash 3.2, maintained by \nGentoo):\n\n$ echo {a..c}\na b c\n\nWho knows if some day they won't have the idea of, say, \nextending \"{aeb32ca..ee23ff1}\" to, well... You see what I mean.\n\n-- \nFrancis Galiegue\nONE2TEAM\nIngénieur système\nMob : +33 (0) 6 83 87 78 75\nTel : +33 (0) 1 78 94 55 52\nfge@one2team.com\n40 avenue Raymond Poincaré\n75116 Paris\n"},{"id":"95932","messageId":"20081116091102.GA19315@artemis.corp","threadId":"16193","inReplyTo":"alpine.LFD.2.00.0811140945000.3468@nehalem.linux-foundation.org","subject":"Re: multiple-commit cherry-pick?","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2008-11-16T09:11:02Z","receivedAt":"2008-11-16T09:11:02Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Fri, Nov 14, 2008 at 05:55:51PM +0000, Linus Torvalds wrote:\n> \n> \n> On Fri, 14 Nov 2008, Linus Torvalds wrote:\n> > \n> > but if you already do\n> > \n> > \tgitk a..b\n> > \n> > then you're _already_ doing a revision limiter and forcing the revision \n> > walk to be synchronous, so there would be no interactivity downside \n> > between 'a..b' and '{a..b}'.\n> \n> Btw, the biggest problem (I think) is actually non-simple ranges and just \n> the _syntax_ of these things.\n> \n> It's entirely reasonable to want to group a more complex expression than \n> just a single range. IOW, something like\n> \n> \tgitk {..origin/pu ^origin/next} {HEAD~5..HEAD~2}\n> \n> to show a union of what is in 'pu' but not master or next, and the \n> symmetrical difference of the current merge. It's a perfectly sensible \n> thing to do. And we _can_ do it right now, just with a nasty syntax:\n> \n> \tgitk --no-walk $(git rev-list ..origin/pu ^origin/next) $(git rev-list HEAD~5..HEAD~2)\n> \n> actually works. But look again at how nasty it is to parse the '{x}' \n> version, because the '{..}' thing now spans multiple arguments. \n\nThat would probably be a job that parseopt could take care of. to some\ndegree.\n\nAlso { } is a poor choice as it's an expansion thingy for many shells.\nzsh even refuses ` { a.. b } ` as an argument, pretending there is a\nsyntax error at the closing brace. [ ] looks like a safer choice, it's\nused for shells supporting arrays, but only when stuck after an\nidentifier which won't be our case ever, so we would be probably safe.\n\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"}]}