{"thread":{"id":"44109","subject":"clarification of `rev-list --no-walk ^`?","startedAt":"2016-09-19T10:56:59Z","lastAt":"2016-09-21T16:15:54Z","messageCount":13,"participants":["Philip Oakley","Michael J Gruber","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"302125","messageId":"2AD952BD65034D25BF26C7F138D24F25@PhilipOakley","threadId":"44109","inReplyTo":null,"subject":"clarification of `rev-list --no-walk ^`?","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2016-09-19T10:56:54Z","receivedAt":"2016-09-19T10:56:59Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"A question came up on the Git user list regarding cherry-pick that got me\nreading the manual (again), in this case regarding --no-walk ranges.\n\nEssentially my question is: If --no-walk is given to rev-list (e.g. via\ncharry-pick), and the user includes a caret prefixed rev, when does that\nrange definition take effect on the command line, especially in light of\nthe --do-walk option?\n\nIn rev-list(1) there are only 8 references to 'range', with only\nthe --no-walk option saying \"This has no effect if a range is specified.\"\nbut leaving open the decision as to what does (and does not) comprises the\nspecification of a range on the cli.\n\nThe two and three dot notations are fairly obvious ranges from\ngitrevisions(7) as they are complete strings, while the caret prefix is an \nimplied range (it needs additional parameters to complete the range, and \nthere-in lies the issue).\n\nIt can be read that\n\n$ git cherry-pick maint next\n\nwould pick two single commits, while\n\n$ git cherry-pick maint next ^master\n\ncould implicitly be read as\n\n$ git cherry-pick maint next --do-walk ^master\n\nbecause the ^ caret starts the range that cancels the --no-walk.\n\nClearly that's not what is intended, which is\n\n$ git cherry-pick --do-walk maint next ^master\n\nbut it is open to interpretation as to where in the command line the caret\nrange prefix's --do-walk (to countermand the --no-walk) should applied.\n\nIf the user did want just the single commit at the tip of maint, and then\nthe range master..next, what would be their command line, and also, how\nwould the man page warn against false expectations?\n\n--\n\nPhilip\n\n\n\n\n\n"},{"id":"302137","messageId":"3b06b9ee-3975-acf1-41d8-02b774a2dd3c@drmicha.warpmail.net","threadId":"44109","inReplyTo":"2AD952BD65034D25BF26C7F138D24F25@PhilipOakley","subject":"Re: clarification of `rev-list --no-walk ^`?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2016-09-19T13:46:35Z","receivedAt":"2016-09-19T13:46:47Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Philip Oakley venit, vidit, dixit 19.09.2016 12:56:\n> A question came up on the Git user list regarding cherry-pick that got me\n> reading the manual (again), in this case regarding --no-walk ranges.\n> \n> Essentially my question is: If --no-walk is given to rev-list (e.g. via\n> charry-pick), and the user includes a caret prefixed rev, when does that\n> range definition take effect on the command line, especially in light of\n> the --do-walk option?\n> \n> In rev-list(1) there are only 8 references to 'range', with only\n> the --no-walk option saying \"This has no effect if a range is specified.\"\n> but leaving open the decision as to what does (and does not) comprises the\n> specification of a range on the cli.\n> \n> The two and three dot notations are fairly obvious ranges from\n> gitrevisions(7) as they are complete strings, while the caret prefix is an \n> implied range (it needs additional parameters to complete the range, and \n> there-in lies the issue).\n> \n> It can be read that\n> \n> $ git cherry-pick maint next\n> \n> would pick two single commits, while\n> \n> $ git cherry-pick maint next ^master\n> \n> could implicitly be read as\n> \n> $ git cherry-pick maint next --do-walk ^master\n> \n> because the ^ caret starts the range that cancels the --no-walk.\n> \n> Clearly that's not what is intended, which is\n> \n> $ git cherry-pick --do-walk maint next ^master\n> \n> but it is open to interpretation as to where in the command line the caret\n> range prefix's --do-walk (to countermand the --no-walk) should applied.\n> \n> If the user did want just the single commit at the tip of maint, and then\n> the range master..next, what would be their command line, and also, how\n> would the man page warn against false expectations?\n\nMaybe:\n\nEvery negative rev (rev prefixed with ^, or a range) implies a\n`--do-walk` (right at its position on the command line).\n\nAnd then curb the misleading range sentence in the `--no-walk` description.\n\nMichael\n\n"},{"id":"302141","messageId":"033051503D8C4F618B1E4879AFF8C28D@PhilipOakley","threadId":"44109","inReplyTo":"3b06b9ee-3975-acf1-41d8-02b774a2dd3c@drmicha.warpmail.net","subject":"Re: clarification of `rev-list --no-walk ^`?","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2016-09-19T14:46:50Z","receivedAt":"2016-09-19T14:47:18Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Michael J Gruber\" \n> Philip Oakley venit, vidit, dixit 19.09.2016 12:56:\n>> A question came up on the Git user list regarding cherry-pick that got me\n>> reading the manual (again), in this case regarding --no-walk ranges.\n>>\n>> Essentially my question is: If --no-walk is given to rev-list (e.g. via\n>> charry-pick), and the user includes a caret prefixed rev, when does that\n>> range definition take effect on the command line, especially in light of\n>> the --do-walk option?\n>>\n>> In rev-list(1) there are only 8 references to 'range', with only\n>> the --no-walk option saying \"This has no effect if a range is specified.\"\n>> but leaving open the decision as to what does (and does not) comprises \n>> the\n>> specification of a range on the cli.\n>>\n>> The two and three dot notations are fairly obvious ranges from\n>> gitrevisions(7) as they are complete strings, while the caret prefix is \n>> an\n>> implied range (it needs additional parameters to complete the range, and\n>> there-in lies the issue).\n>>\n>> It can be read that\n>>\n>> $ git cherry-pick maint next\n>>\n>> would pick two single commits, while\n>>\n>> $ git cherry-pick maint next ^master\n>>\n>> could implicitly be read as\n>>\n>> $ git cherry-pick maint next --do-walk ^master\n>>\n>> because the ^ caret starts the range that cancels the --no-walk.\n>>\n>> Clearly that's not what is intended, which is\n>>\n>> $ git cherry-pick --do-walk maint next ^master\n>>\n>> but it is open to interpretation as to where in the command line the \n>> caret\n>> range prefix's --do-walk (to countermand the --no-walk) should applied.\n>>\n>> If the user did want just the single commit at the tip of maint, and then\n>> the range master..next, what would be their command line, and also, how\n>> would the man page warn against false expectations?\n>\n> Maybe:\n>\n> Every negative rev (rev prefixed with ^, or a range) implies a\n> `--do-walk` (right at its position on the command line).\n>\n> And then curb the misleading range sentence in the `--no-walk` \n> description.\n\nAt the moment the cherry-pick man page's example implies that --do-walk is \napplied from the beginning, rather from the point given on the command line.\n\nI had a very quick search of the *.c code for the options but didn't get any \nfurther. Hopefully the user issue/misunderstanding is elsewhere... I'll add \nthis to my little list.\n\n--\nPhilip \n\n"},{"id":"302146","messageId":"xmqq8tunhns4.fsf@gitster.mtv.corp.google.com","threadId":"44109","inReplyTo":"3b06b9ee-3975-acf1-41d8-02b774a2dd3c@drmicha.warpmail.net","subject":"Re: clarification of `rev-list --no-walk ^`?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-09-19T16:12:11Z","receivedAt":"2016-09-19T16:12:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n>> It can be read that\n>> \n>> $ git cherry-pick maint next\n>> \n>> would pick two single commits, while\n>> \n>> $ git cherry-pick maint next ^master\n>> \n>> could implicitly be read as\n>> \n>> $ git cherry-pick maint next --do-walk ^master\n\nYou can read it as \"master..next maint\" that does force walking.\n\n>> Clearly that's not what is intended, which is\n>> \n>> $ git cherry-pick --do-walk maint next ^master\n\nI do not see the distinction betwee the above two you seem to be\ntrying to make. Care to explain?\n\n>> but it is open to interpretation as to where in the command line the caret\n>> range prefix's --do-walk (to countermand the --no-walk) should applied.\n\nI do not think it can be position dependent. Philip probably has a\nconfused notion that \"rev-list A..B C..D\" is somehow a union of set\nA..B and C..D?\n\n>> If the user did want just the single commit at the tip of maint, and then\n>> the range master..next, what would be their command line, and also, how\n>> would the man page warn against false expectations?\n\nYeah, this can show us that all of the have is coming from that\nexact confusion I suspected Philip has. We need to clarify in the\ndocumentation that rev-list set operation does *NOT* have union of\nmultiple sets to unconfuse the readers.\n\n"},{"id":"302148","messageId":"xmqq4m5bhnfg.fsf@gitster.mtv.corp.google.com","threadId":"44109","inReplyTo":"033051503D8C4F618B1E4879AFF8C28D@PhilipOakley","subject":"Re: clarification of `rev-list --no-walk ^`?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-09-19T16:19:47Z","receivedAt":"2016-09-19T16:19:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Philip Oakley\" writes:\n\n> At the moment the cherry-pick man page's example implies that\n> --do-walk is applied from the beginning, rather from the point given\n> on the command line.\n>\n> I had a very quick search of the *.c code for the options but didn't\n> get any further. Hopefully the user issue/misunderstanding is\n> elsewhere... I'll add this to my little list.\n\nI think the confusion is coming from not understanding that revision\nspecifiers cannot have position-dependent semantics, because there\nis no \"union of multiple sets\". You said\n\n\tcommits in 'master..next' range and the tip of 'maint'\n\nearlier, and that is a prime specimen of that confusion. That is\nasking \"things reachable from next excluding things reachable from\nmaster\" computed independently from everything else on the command\nline (i.e. that is one set), and \"the commit at the tip of 'maint'\"\n(i.e. that is another set, which consists of a singleton element),\nand wanting to take a union of it. But the revision machinery is\nnot structured to work that way. It can only do \"reachable from one\nenumeration of positive tips, excluding ones reachable from another\nenumeration of negative tips\". \"no-walk\" is a cheap hack that tells\nthe machinery \"stop after collecting that 'one enumeration of\npositive tips' and do not walk. Make that enumeration the resulting\nset\". Having anything negative in the enumeration of starting\npoints from the command line automatically turns \"no-walk\" off, even\nfor commands that default to \"no-walk\".\n\nWe may need further documentation updates to unconfuse readers.\n"},{"id":"302171","messageId":"989F47918A374EEF8C7FECD3CFC6767E@PhilipOakley","threadId":"44109","inReplyTo":"xmqq8tunhns4.fsf@gitster.mtv.corp.google.com","subject":"Re: clarification of `rev-list --no-walk ^`?","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2016-09-19T19:31:55Z","receivedAt":"2016-09-19T19:32:01Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Junio C Hamano\" \n> Michael J Gruber writes:\n>\n>>> It can be read that\n>>>\n>>> $ git cherry-pick maint next\n>>>\n>>> would pick two single commits, while\n>>>\n>>> $ git cherry-pick maint next ^master\n>>>\n>>> could implicitly be read as\n>>>\n>>> $ git cherry-pick maint next --do-walk ^master\n>\n> You can read it as \"master..next maint\" that does force walking.\n>\n>>> Clearly that's not what is intended, which is\n>>>\n>>> $ git cherry-pick --do-walk maint next ^master\n>\n> I do not see the distinction betwee the above two you seem to be\n> trying to make. Care to explain?\n>\n>>> but it is open to interpretation as to where in the command line the \n>>> caret\n>>> range prefix's --do-walk (to countermand the --no-walk) should applied.\n>\n> I do not think it can be position dependent.\n\nOK. (background, long story) When I first read the man page, and in trying \nto explain a user confusion between cherry pick commits and am'ing the same \ncommits via format-patch (where sometimes the patches had coverlapping \ncontext issues), I was trying to confirm for myself that 'git cherry-pick B \nC' and 'git cherry-pick C B' should get the same end result, and not be \nmistaken (e.g. user misunderstanding) for a range.\n\nI first spotted the 'git help cherry-pick's line:\n\n - no traversal is done by default, as if the --no-walk option was \nspecified, see git-rev-list(1).\n\nSo off I goes to rev-list, and see that the options no-walk/do-walk are said \n(implied) to be position dependent.\n\n--do-walk - Overrides a previous --no-walk.\n\nMeanwhile the --no-walk option says:\n\n --no-walk - This (option) has no effect if a range is specified.\n\nSo at this point I am wondering about the command line ordering and what \ncomprises the range if the negative ref is given last, or at least just \nbefore a --do-walk.\n\nThus (at this point) it felt like one of those specification rabbit-holes \nthat I often see at $dayjob. It was unclear as to the point at which the \n'range' was to be applied in to the command line to get the expected \nexamples.\n\n\nClimbing back out of the rabbit-hole. I now see that after the end of the \ncherry-pick line I quoted, there is a secondary \"Note that \nspecifying a range will feed all . arguments to a single revision \nwalk\", which at the time did not register (a classic human error.. Three \nMile Island et al.).\n\nSimilarly, in the rev-list --no-walk option, its says (mid-para) \"This has \nno effect if a range is specified.\" so in some ways that confirms the cherry \npick statement, but again a less obvious corollary.\n\nHowever, there is still a small step missing, which is to confirm that using \na negative ^ref anywhere(?) makes the whole list of refs into a range (i.e. \nit will look-back along the command line) to cancel any --no-walk options in \nplace.\n\nGiven that a walk usually requires a range, I'm now having difficulty seeing \nhow the --no-walk --do-walk can be combined anyway.\n\nThe bits I felt was missing (in the docs) was to say explicitly somewhere \nthat a negative ref defined that we had a range (to link back to those \nwalk-no-walk statements), and the extent of rev paramaters it applied to.\n\nAnd after re-reading, that some of those corollary statements about ranges \nflipping the walk-no-walk condition should be brought forward to be more \nobvious within the primary rev-list (to avoid the typical reader error).\n\n\n> Philip probably has a\n> confused notion that \"rev-list A..B C..D\" is somehow a union of set\n> A..B and C..D?\n\nThat wasn't the issue. Though it does beg the question that it's the same as \n\"rev-list D B ^A ^C\" isn't it?\n\n>\n>>> If the user did want just the single commit at the tip of maint, and \n>>> then\n>>> the range master..next, what would be their command line, and also, how\n>>> would the man page warn against false expectations?\n>\n> Yeah, this can show us that all of the have is coming from that\n> exact confusion I suspected Philip has. We need to clarify in the\n> documentation that rev-list set operation does *NOT* have union of\n> multiple sets to unconfuse the readers.\n\nI'd say it was the walk - no walk range confusion. Inclusion of any range \ndefinition of any sort (in particular ^rev) causes the expectation that an \nordered list of single revs can be included, to be broken.\ni.e. cherry-pick B D F G Q..T; isn't B D F G R S T, is it?\n\nI've also have a quick browse of the test scripts and didn't see any tests \nthat actually cover the example of `git cherry-pick maint next ^master` \nwhere both have multiple commits to pick, so couldn't see what the test \nwould expect.\n\n--\nPhilip\n\n"},{"id":"302176","messageId":"xmqqintrek64.fsf@gitster.mtv.corp.google.com","threadId":"44109","inReplyTo":"989F47918A374EEF8C7FECD3CFC6767E@PhilipOakley","subject":"Re: clarification of `rev-list --no-walk ^`?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-09-19T19:58:27Z","receivedAt":"2016-09-19T19:58:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Philip Oakley\" writes:\n\n>> Philip probably has a\n>> confused notion that \"rev-list A..B C..D\" is somehow a union of set\n>> A..B and C..D?\n>\n> That wasn't the issue. Though it does beg the question that it's the\n> same as \"rev-list D B ^A ^C\" isn't it?\n\nIf you think it begs the question, then you haven't understood what\nI meant by all of the explanation. Let me repeat:\n\n\t\"A..B C..D\" is exactly a short-hand for \"^A B ^C D\" which is\n\tthe same as ANY permutation like \"D B ^A ^C\".\n\nThis is because rev-list machinery NEVER does \"ah the command line\nasks for two or more sets to be computed and then a union of the\nresults to be returned\". As I said, it collects positive starting\npoints (B and D) and negative starting points (A and C), and does a\nsingle traversal \"ones that are reachable from positives, excluding\nthe ones that are reachable from negatives\". That is all it does.\n\nOnce that is understood, it should be obvious that it would not have\nany effect on the result to permute the order of positives and\nnegatives.\n\n> I'd say it was the walk - no walk range confusion.\n\nYou may _additionally_ have had that confusion ;-).\n\n> i.e. cherry-pick B D F G Q..T; isn't B D F G R S T, is it?\n\nOf course it isn't, but that is not about any ordering. It is\nbecause the machinery does not work this way:\n\n - we have positives B D F G and ... oh wait, we see Q..T, so we\n need to traverse ONLY that bit and come up with positives in the\n resulting set, which are R S T, and take a union of all of the\n above; and then\n\n - now we process --no-walk to show only the resulting positives.\n\nThe \"--no-walk\" tells the rev-list machinery \"I have only positives;\ndo not traverse from them AT ALL but just use these positives\".\nOnly under that condition, the order of the positive ends you list\non the command line matters.\n\nHaving ^Q in the input \"B D F G ^Q T\" contradicts that \"I have only\npositives\" precondtion and forces the machinery to traverse, i.e. to\nfind things reachable from B D F G T excluding things reachable from\nQ. The order of the output would be topological (i.e. a parent is\nnot shown until all its children are), with or without --date-order,\nand may not match the order you gave the positive ones from the\ncommand line.\n\nYou may want the \"exclude things reachable from Q\" part to not have\nany effect on things related to B, D, F or G, but the machinery does\nnot work that way. That is because there is only one single traversal\nand no union operation involved.\n\nIt is a different matter Git born in a fictional world that takes\nA..B C..D as a union of two sets is better than the current one.\nThere might be cases where such a variant of \"a set of commits that\nis a union of multiple sets\" is handy to use. But I think we are\ntalking about what Git in our world does, so I'd not go there in\nthis discussion.\n"},{"id":"302179","messageId":"DDC820F0373F4534B4A9D12E8B7B866B@PhilipOakley","threadId":"44109","inReplyTo":"xmqqintrek64.fsf@gitster.mtv.corp.google.com","subject":"Re: clarification of `rev-list --no-walk ^`?","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2016-09-19T20:12:51Z","receivedAt":"2016-09-19T20:12:55Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Junio C Hamano\" \n> \"Philip Oakley\" writes:\n>\n>>> Philip probably has a\n>>> confused notion\n\nHi Junio,\n\nCould you clarify a particular point from here..\n\n> The \"--no-walk\" tells the rev-list machinery \"I have only positives;\n> do not traverse from them AT ALL but just use these positives\".\n> Only under that condition, the order of the positive ends you list\n> on the command line matters.\n\nWhat does \"--do-walk\" do (\"Overrides a previous --no-walk\"), and when would \nit be applied?\n\n--\nPhilip \n\n"},{"id":"302184","messageId":"9B75514A5DC94A5D86FAFB66BF66E9B0@PhilipOakley","threadId":"44109","inReplyTo":"xmqqintrek64.fsf@gitster.mtv.corp.google.com","subject":"Re: clarification of `rev-list --no-walk ^`?","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2016-09-19T20:44:54Z","receivedAt":"2016-09-19T20:44:59Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Junio C Hamano\" \n> \"Philip Oakley\" writes:\n>\n>>> Philip probably has a\n>>> confused notion that \"rev-list A..B C..D\" is somehow a union of set\n>>> A..B and C..D?\n>>\n>> That wasn't the issue. Though it does beg the question that it's the\n>> same as \"rev-list D B ^A ^C\" isn't it?\n>\n> If you think it begs the question, then you haven't understood what\n> I meant by all of the explanation. Let me repeat:\n\nApologies. We appear to be having an British/American usage \nmisunderstanding. Locally, the answer to the begged (rhetorically asked) \nquestion is, as you say, \"Yes, they are the same\". It was simply confirming \nour common understanding.\n\n>\n> \"A..B C..D\" is exactly a short-hand for \"^A B ^C D\" which is\n> the same as ANY permutation like \"D B ^A ^C\".\n>\n\nregards,\nPhilip \n\n"},{"id":"302186","messageId":"xmqqa8f3ehaa.fsf@gitster.mtv.corp.google.com","threadId":"44109","inReplyTo":"DDC820F0373F4534B4A9D12E8B7B866B@PhilipOakley","subject":"Re: clarification of `rev-list --no-walk ^`?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-09-19T21:00:45Z","receivedAt":"2016-09-19T21:01:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Philip Oakley\" writes:\n\n>> The \"--no-walk\" tells the rev-list machinery \"I have only positives;\n>> do not traverse from them AT ALL but just use these positives\".\n>> Only under that condition, the order of the positive ends you list\n>> on the command line matters.\n>\n> What does \"--do-walk\" do (\"Overrides a previous --no-walk\"), and when\n> would it be applied?\n\nWouldn't \n\n $ git cherry-pick --no-walk --do-walk A\n\nend up walking the history behind A and reproducing the history\nsince the root commit?\n\n"},{"id":"302275","messageId":"affca640-4ed8-268a-9f7d-e2c7ce6d66fc@drmicha.warpmail.net","threadId":"44109","inReplyTo":"xmqq8tunhns4.fsf@gitster.mtv.corp.google.com","subject":"Re: clarification of `rev-list --no-walk ^`?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2016-09-21T14:46:45Z","receivedAt":"2016-09-21T14:46:52Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 19.09.2016 18:12:\n> Michael J Gruber writes:\n> \n>>> It can be read that\n>>>\n>>> $ git cherry-pick maint next\n>>>\n>>> would pick two single commits, while\n>>>\n>>> $ git cherry-pick maint next ^master\n>>>\n>>> could implicitly be read as\n>>>\n>>> $ git cherry-pick maint next --do-walk ^master\n> \n> You can read it as \"master..next maint\" that does force walking.\n> \n>>> Clearly that's not what is intended, which is\n>>>\n>>> $ git cherry-pick --do-walk maint next ^master\n> \n> I do not see the distinction betwee the above two you seem to be\n> trying to make. Care to explain?\n\nI think you answered to e-mail (in-reply-to) and to Philip's actual text\n(quotes), but just in case:\n\n[git]✓ git rev-list --no-walk ^HEAD~3 HEAD\n47d74601f5c6bbef215a887be2ca877e34391c9f\n574dece7b651fbae385add51d7aaea1cc414007a\n3fbbf6e9e40b151215cce6c6e25cd4db0232d870\n[git]✓ git rev-list ^HEAD~3 --no-walk HEAD\n47d74601f5c6bbef215a887be2ca877e34391c9f\n\nThe order of revision arguments and options does play role (but where I\nput my HEAD does not, uhm), i.e. walk-options vs. negative refs.\n\nThe reason is that negative revs come with an implicit --do-walk (we\nneed to walk to mark uninteresting revs), and the last\n--do-walk/--no-walk wins. That's what I meant with my comment.\n\nBut there is only one walk (or none), and one setting effective for all\nrevision arguments.\n\nMichael\n"},{"id":"302276","messageId":"65a10cb3-ede9-a107-9d7d-ee4b5250949e@drmicha.warpmail.net","threadId":"44109","inReplyTo":"affca640-4ed8-268a-9f7d-e2c7ce6d66fc@drmicha.warpmail.net","subject":"Re: clarification of `rev-list --no-walk ^`?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2016-09-21T14:51:32Z","receivedAt":"2016-09-21T14:51:39Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"[So many typos, sorry]\n\nMichael J Gruber venit, vidit, dixit 21.09.2016 16:46:\n> Junio C Hamano venit, vidit, dixit 19.09.2016 18:12:\n>> Michael J Gruber writes:\n>>\n>>>> It can be read that\n>>>>\n>>>> $ git cherry-pick maint next\n>>>>\n>>>> would pick two single commits, while\n>>>>\n>>>> $ git cherry-pick maint next ^master\n>>>>\n>>>> could implicitly be read as\n>>>>\n>>>> $ git cherry-pick maint next --do-walk ^master\n>>\n>> You can read it as \"master..next maint\" that does force walking.\n>>\n>>>> Clearly that's not what is intended, which is\n>>>>\n>>>> $ git cherry-pick --do-walk maint next ^master\n>>\n>> I do not see the distinction betwee the above two you seem to be\n>> trying to make. Care to explain?\n> \n> I think you answered to e-mail (in-reply-to) and to Philip's actual text\n> (quotes), but just in case:\n\n\"my e-mail\"\n\n> \n> [git]✓ git rev-list --no-walk ^HEAD~3 HEAD\n> 47d74601f5c6bbef215a887be2ca877e34391c9f\n> 574dece7b651fbae385add51d7aaea1cc414007a\n> 3fbbf6e9e40b151215cce6c6e25cd4db0232d870\n> [git]✓ git rev-list ^HEAD~3 --no-walk HEAD\n> 47d74601f5c6bbef215a887be2ca877e34391c9f\n> \n> The order of revision arguments and options does play role (but where I\n> put my HEAD does not, uhm), i.e. walk-options vs. negative refs.\n\n\"play a role\"\n\"negative revs\"\n\n> \n> The reason is that negative revs come with an implicit --do-walk (we\n> need to walk to mark uninteresting revs), and the last\n\n\"in order to mark\"\n\n> --do-walk/--no-walk wins. That's what I meant with my comment.\n> \n> But there is only one walk (or none), and one setting effective for all\n> revision arguments.\n> \n> Michael\n> \n\n"},{"id":"302283","messageId":"xmqqlgylb55a.fsf@gitster.mtv.corp.google.com","threadId":"44109","inReplyTo":"affca640-4ed8-268a-9f7d-e2c7ce6d66fc@drmicha.warpmail.net","subject":"Re: clarification of `rev-list --no-walk ^`?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-09-21T16:15:45Z","receivedAt":"2016-09-21T16:15:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> I think you answered to e-mail (in-reply-to) and to Philip's actual text\n> (quotes), but just in case:\n\nYes, my mistake. Sorry for the noise.\n"}]}