{"thread":{"id":"35513","subject":"Unexpected cherry-pick behaviour","startedAt":"2013-12-10T11:04:16Z","lastAt":"2013-12-16T20:15:27Z","messageCount":13,"participants":["Paulo Matos","Junio C Hamano","Antoine Pelisse","Philip Oakley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"231853","messageId":"118044938ad8ebf6b069bcc1d220a986@matos-sorge.com","threadId":"35513","inReplyTo":null,"subject":"Unexpected cherry-pick behaviour","fromName":"Paulo Matos","fromEmail":"paulo@matos-sorge.com","sentAt":"2013-12-10T11:04:16Z","receivedAt":"2013-12-10T11:04:16Z","isPatch":false,"sender":{"key":"paulo@matos-sorge.com","avatar":"https://gravatar.com/avatar/0877e386c336b900d05542bb71a10a85c15b96f5b13f28c334e492c0de9cd5bf?d=mp&s=160"},"body":"Hi,\n\nI have installed latest 1.8.5.1 git to confirm the behaviour I had seen \nin previous versions.\n\nWhat I see is that when I cherry-pick a patch across two branches \n(source and destination) in a repository, cherry-pick picks changes from \nthe source branch which do not exist in the cherry-picked patch.\n\nTo reproduce please follow the following in a clean directory (apologies \nfor the large repo I use as example):\n$ git clone git://gcc.gnu.org/git/gcc.git\n$ cd gcc\n$ git checkout -b gcc-4_8-branch origin/gcc-4_8-branch\n$ cd gcc\n$ sed -i '877i myport_hook ()' tree-ssa-threadedge.c\n$ git diff tree-ssa-threadedge.c\nindex b31e961..f022eed 100644\n--- a/gcc/tree-ssa-threadedge.c\n+++ b/gcc/tree-ssa-threadedge.c\n@@ -874,6 +874,7 @@ thread_across_edge (gimple dummy_cond,\n if (cond_arg_set_in_bb (e, e->dest))\n goto fail;\n }\n+myport_hook ()\n\n stmt_count = 0;\n$ git add tree-ssa-threadedge.c\n$ git commit -m 'cherry-pick test'\n[gcc-4_8-branch 49a2b7f] cherry-pick test\n 1 file changed, 1 insertion(+)\n$ git checkout master\n$ git cherry-pick 49a2b7f # ensure you're cherry-picking the right sha\nerror: could not apply 49a2b7f... cherry-pick test\nhint: after resolving the conflicts, mark the corrected paths\nhint: with 'git add ' or 'git rm '\nhint: and commit the result with 'git commit'\n$ git diff tree-ssa-threadedge.c\ndiff --cc gcc/tree-ssa-threadedge.c\nindex cb6accf,f022eed..0000000\n--- a/gcc/tree-ssa-threadedge.c\n+++ b/gcc/tree-ssa-threadedge.c\n@@@ -936,34 -854,33 +936,47 @@@ thread_around_empty_blocks (edge taken_\n STACK is used to undo temporary equivalences created during the \nwalk of\n E->dest.\n\n - SIMPLIFY is a pass-specific function used to simplify statements. \n*/\n -\n -void\n -thread_across_edge (gimple dummy_cond,\n - edge e,\n - bool handle_dominating_asserts,\n - vec *stack,\n - tree (*simplify) (gimple, gimple))\n -{\n - gimple stmt;\n + SIMPLIFY is a pass-specific function used to simplify statements.\n\n++<<<<<<< HEAD\n + Our caller is responsible for restoring the state of the expression\n + and const_and_copies stacks. */\n++=======\n+ /* If E is a backedge, then we want to verify that the COND_EXPR,\n+ SWITCH_EXPR or GOTO_EXPR at the end of e->dest is not affected\n+ by any statements in e->dest. If it is affected, then it is not\n+ safe to thread this edge. */\n+ if (e->flags & EDGE_DFS_BACK)\n+ {\n+ if (cond_arg_set_in_bb (e, e->dest))\n+ goto fail;\n+ }\n+ myport_hook ()\n++>>>>>>> 49a2b7f... cherry-pick test\n\n - stmt_count = 0;\n +static bool\n +thread_through_normal_block (edge e,\n + gimple dummy_cond,\n + bool handle_dominating_asserts,\n + vec *stack,\n + tree (*simplify) (gimple, gimple),\n + vec *path,\n + bitmap visited,\n + bool *backedge_seen_p,\n + bitmap src_map,\n + bitmap dst_map)\n +{\n + /* If we have traversed a backedge, then we do not want to look\n + at certain expressions in the table that can not be relied upon.\n + Luckily the only code that looked at those expressions is the\n + SIMPLIFY callback, which we replace if we can no longer use it. \n*/\n + if (*backedge_seen_p)\n + simplify = dummy_simplify;\n\n /* PHIs create temporary equivalences. */\n - if (!record_temporary_equivalences_from_phis (e, stack))\n - goto fail;\n + if (!record_temporary_equivalences_from_phis (e, stack, \n*backedge_seen_p,\n + src_map, dst_map))\n + return false;\n\n /* Now walk each statement recording any context sensitive\n temporary equivalences we can detect. */\n\n\nNote how there are changes that are not part of the cherry-picked patch \noutside of the conflicting zone. This is trouble some because it means \nthat when I go in to fix a patch and look only at the conflicting zone, \nI will have code outside the zone, that are _not_ part of the patch \nmodified as well.\n\nIs this a bug or a feature? If the latter, why this behaviour and how \ncan I avoid it?\n\nCheers,\n\n-- \nPaulo Matos\n"},{"id":"231870","messageId":"xmqqvbywts9d.fsf@gitster.dls.corp.google.com","threadId":"35513","inReplyTo":"118044938ad8ebf6b069bcc1d220a986@matos-sorge.com","subject":"Re: Unexpected cherry-pick behaviour","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-12-10T19:34:06Z","receivedAt":"2013-12-10T19:34:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Paulo Matos writes:\n\n> Note how there are changes that are not part of the cherry-picked\n> patch outside of the conflicting zone. This is trouble some because it\n> means that when I go in to fix a patch and look only at the\n> conflicting zone, I will have code outside the zone, that are _not_\n> part of the patch modified as well.\n\nMy suspicion (I am too lazy to try it myself ;-) is that your\naddition of a line \"myport_hook()\" was done to a section of code\nthat was modified between the original you added the line to and the\ntarget you are trying to cherry-pick your change (that will\ninevitably cause conflicts and you cannot avoid that), and the\npost-processing done to make the three-way merge result more\nreadable are ejecting common changes out of the conflicted region.\n\nPerhaps immediately after \"cherry-pick\" stopped and asked your help\nto resolve the conflicts, running\n\n\t$ git checkout --conflicts=diff3 gcc/tree-ssa-threadedge.c\n\nand looking at the file again may show you what is going on better.\n"},{"id":"231899","messageId":"7050e7272bb83d083a56a2c391228ed8@matos-sorge.com","threadId":"35513","inReplyTo":"xmqqvbywts9d.fsf@gitster.dls.corp.google.com","subject":"Re: Unexpected cherry-pick behaviour","fromName":"Paulo Matos","fromEmail":"paulo@matos-sorge.com","sentAt":"2013-12-11T10:04:26Z","receivedAt":"2013-12-11T10:04:26Z","isPatch":false,"sender":{"key":"paulo@matos-sorge.com","avatar":"https://gravatar.com/avatar/0877e386c336b900d05542bb71a10a85c15b96f5b13f28c334e492c0de9cd5bf?d=mp&s=160"},"body":"On 10/12/2013 19:34, Junio C Hamano wrote:\n> Perhaps immediately after \"cherry-pick\" stopped and asked your help\n> to resolve the conflicts, running\n> \n> \t$ git checkout --conflicts=diff3 gcc/tree-ssa-threadedge.c\n> \n> and looking at the file again may show you what is going on better.\n\nI don't know how to interpret the fact that the line you sent (with the \nobvious --conflicts being --conflict) outputs nothing...\n\nAny suggestions?\n\n-- \nPaulo Matos\n"},{"id":"231900","messageId":"CALWbr2zPPnDiv7oVBhnM9dSW=pfz2jUA_A5u_gk2ttgXTStvkw@mail.gmail.com","threadId":"35513","inReplyTo":"7050e7272bb83d083a56a2c391228ed8@matos-sorge.com","subject":"Re: Unexpected cherry-pick behaviour","fromName":"Antoine Pelisse","fromEmail":"apelisse@gmail.com","sentAt":"2013-12-11T11:09:02Z","receivedAt":"2013-12-11T11:09:02Z","isPatch":false,"sender":{"key":"apelisse@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1929644?v=4"},"body":"On Wed, Dec 11, 2013 at 11:04 AM, Paulo Matos wrote:\n> On 10/12/2013 19:34, Junio C Hamano wrote:\n>>\n>> Perhaps immediately after \"cherry-pick\" stopped and asked your help\n>> to resolve the conflicts, running\n>>\n>> $ git checkout --conflicts=diff3 gcc/tree-ssa-threadedge.c\n>>\n>> and looking at the file again may show you what is going on better.\n>\n>\n> I don't know how to interpret the fact that the line you sent (with the\n> obvious --conflicts being --conflict) outputs nothing...\n\nThat is expected. git-checkout with this option [1] will reset the\nconflict on gcc/tree-ssa-threadedge.c file to the initial conflict\nstate, and use the diff3 markers. You should have a new look at that\nfile as you will now be able to see the \"ancestor\" in the conflict.\n\n[1] You can have a look either at git-checkout manpage or here:\nhttp://git-scm.com/docs/git-checkout, especially --merge and\n--conflict options.\n"},{"id":"231901","messageId":"beee32a53ece8b839578703deb851eaa@matos-sorge.com","threadId":"35513","inReplyTo":"CALWbr2zPPnDiv7oVBhnM9dSW=pfz2jUA_A5u_gk2ttgXTStvkw@mail.gmail.com","subject":"Re: Unexpected cherry-pick behaviour","fromName":"Paulo Matos","fromEmail":"paulo@matos-sorge.com","sentAt":"2013-12-11T11:19:34Z","receivedAt":"2013-12-11T11:19:34Z","isPatch":false,"sender":{"key":"paulo@matos-sorge.com","avatar":"https://gravatar.com/avatar/0877e386c336b900d05542bb71a10a85c15b96f5b13f28c334e492c0de9cd5bf?d=mp&s=160"},"body":"On 11/12/2013 11:09, Antoine Pelisse wrote:\n>> \n>> I don't know how to interpret the fact that the line you sent (with \n>> the\n>> obvious --conflicts being --conflict) outputs nothing...\n> \n> That is expected. git-checkout with this option [1] will reset the\n> conflict on gcc/tree-ssa-threadedge.c file to the initial conflict\n> state, and use the diff3 markers. You should have a new look at that\n> file as you will now be able to see the \"ancestor\" in the conflict.\n> \n> [1] You can have a look either at git-checkout manpage or here:\n> http://git-scm.com/docs/git-checkout, especially --merge and\n> --conflict options.\n> --\n\nGot it, but still not helpful as git is still modifying code out of the \nconflicting zone.\n\n$ git checkout --conflict=diff3 tree-ssa-threadedge.c\n$ git diff tree-ssa-threadedge.c\ndiff --cc gcc/tree-ssa-threadedge.c\nindex cb6accf,f022eed..0000000\n--- a/gcc/tree-ssa-threadedge.c\n+++ b/gcc/tree-ssa-threadedge.c\n@@@ -936,34 -854,33 +936,57 @@@ thread_around_empty_blocks (edge taken_\n STACK is used to undo temporary equivalences created during the \nwalk of\n E->dest.\n\n - SIMPLIFY is a pass-specific function used to simplify statements. \n*/\n -\n -void\n -thread_across_edge (gimple dummy_cond,\n - edge e,\n - bool handle_dominating_asserts,\n - vec *stack,\n - tree (*simplify) (gimple, gimple))\n -{\n - gimple stmt;\n + SIMPLIFY is a pass-specific function used to simplify statements.\n\n++<<<<<<< ours\n + Our caller is responsible for restoring the state of the expression\n + and const_and_copies stacks. */\n++||||||| base\n++ /* If E is a backedge, then we want to verify that the COND_EXPR,\n++ SWITCH_EXPR or GOTO_EXPR at the end of e->dest is not affected\n++ by any statements in e->dest. If it is affected, then it is not\n++ safe to thread this edge. */\n++ if (e->flags & EDGE_DFS_BACK)\n++ {\n++ if (cond_arg_set_in_bb (e, e->dest))\n++ goto fail;\n++ }\n++=======\n+ /* If E is a backedge, then we want to verify that the COND_EXPR,\n+ SWITCH_EXPR or GOTO_EXPR at the end of e->dest is not affected\n+ by any statements in e->dest. If it is affected, then it is not\n+ safe to thread this edge. */\n+ if (e->flags & EDGE_DFS_BACK)\n+ {\n+ if (cond_arg_set_in_bb (e, e->dest))\n+ goto fail;\n+ }\n+ myport_hook ()\n++>>>>>>> theirs\n\n - stmt_count = 0;\n +static bool\n +thread_through_normal_block (edge e,\n + gimple dummy_cond,\n + bool handle_dominating_asserts,\n + vec *stack,\n + tree (*simplify) (gimple, gimple),\n + vec *path,\n + bitmap visited,\n + bool *backedge_seen_p,\n + bitmap src_map,\n + bitmap dst_map)\n +{\n + /* If we have traversed a backedge, then we do not want to look\n + at certain expressions in the table that can not be relied upon.\n + Luckily the only code that looked at those expressions is the\n + SIMPLIFY callback, which we replace if we can no longer use it. \n*/\n + if (*backedge_seen_p)\n + simplify = dummy_simplify;\n\n /* PHIs create temporary equivalences. */\n - if (!record_temporary_equivalences_from_phis (e, stack))\n - goto fail;\n + if (!record_temporary_equivalences_from_phis (e, stack, \n*backedge_seen_p,\n + src_map, dst_map))\n + return false;\n\n /* Now walk each statement recording any context sensitive\n temporary equivalences we can detect. */\n\n-- \nPaulo Matos\n"},{"id":"231996","messageId":"CALWbr2y1YDX0dzjpZoF8WL4+ND+8drurH+Wrf1wBs_-=0datOA@mail.gmail.com","threadId":"35513","inReplyTo":"beee32a53ece8b839578703deb851eaa@matos-sorge.com","subject":"Re: Unexpected cherry-pick behaviour","fromName":"Antoine Pelisse","fromEmail":"apelisse@gmail.com","sentAt":"2013-12-14T09:40:14Z","receivedAt":"2013-12-14T09:40:14Z","isPatch":false,"sender":{"key":"apelisse@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1929644?v=4"},"body":"On Wed, Dec 11, 2013 at 12:19 PM, Paulo Matos wrote:\n> On 11/12/2013 11:09, Antoine Pelisse wrote:\n>>>\n>>>\n>>> I don't know how to interpret the fact that the line you sent (with the\n>>> obvious --conflicts being --conflict) outputs nothing...\n>>\n>>\n>> That is expected. git-checkout with this option [1] will reset the\n>> conflict on gcc/tree-ssa-threadedge.c file to the initial conflict\n>> state, and use the diff3 markers. You should have a new look at that\n>> file as you will now be able to see the \"ancestor\" in the conflict.\n>>\n>> [1] You can have a look either at git-checkout manpage or here:\n>> http://git-scm.com/docs/git-checkout, especially --merge and\n>> --conflict options.\n>> --\n>\n>\n> Got it, but still not helpful as git is still modifying code out of the\n> conflicting zone.\n\nActually it didn't modify out of the conflicting zone.\nThis is because you are having a look at a combine-diff which tries to\nshow both how it changed master *and* the cherry-picked patch at the\nsame time. If you only want to see the diff applied to master, you\nshould run:\n\n $ git diff --ours\n\nYou can also have a look at what is currently being applied:\n\n $ git diff :1:gcc/tree-ssa-threadedge.c :3:gcc/tree-ssa-threadedge.c\n\nBy the way, does anybody know a better way to do that ? I happen to do\nthat quite a lot when fixing complex conflicts and the command is\nquite inconvenient (I always end-up forgetting which numbers to use,\netc..).\n\nHope that helps,\nAntoine\n"},{"id":"232024","messageId":"3FFF08967D2E480FA6B0E0EE3A72A8D9@PhilipOakley","threadId":"35513","inReplyTo":"CALWbr2y1YDX0dzjpZoF8WL4+ND+8drurH+Wrf1wBs_-=0datOA@mail.gmail.com","subject":"Re: Unexpected cherry-pick behaviour","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2013-12-14T13:07:21Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"\n----- Original Message ----- \nFrom: \"Antoine Pelisse\" \n\n>\n> You can also have a look at what is currently being applied:\n>\n> $ git diff :1:gcc/tree-ssa-threadedge.c \n> :3:gcc/tree-ssa-threadedge.c\n>\n> By the way, does anybody know a better way to do that ? I happen to do\n> that quite a lot when fixing complex conflicts and the command is\n> quite inconvenient (I always end-up forgetting which numbers to use,\n> etc..).\n\nWould this be a good use of the\n * Magic pathspecs like \":(icase)\nthat was recently released (v1.8.5 2Dec13) so that the merge stages \ncan be named.\n\nI'm not sure that the three 'merge stages' have well defined short names \nyet though.\n\n[1] \nhttp://schacon.github.io/gitbook/5_advanced_branching_and_merging.html\n[2] https://www.kernel.org/pub/software/scm/git/docs/git-merge.html see \nTrue Merge 4.\n\nAside: the 'merge stages' terminology does overlap the common user \ndiscussion of commit staging e.g. $gmane/236127 (Officially start moving \nto the term 'staging area'). Any pathspec magic names should reflect the \nconcept being indicated rather than the implementation - a thorny \nproblem.\n\n>\n> Hope that helps,\n> Antoine\n> --\n\nPhilip \n"},{"id":"232028","messageId":"7vvbyrgrcv.fsf@alter.siamese.dyndns.org","threadId":"35513","inReplyTo":"CALWbr2y1YDX0dzjpZoF8WL4+ND+8drurH+Wrf1wBs_-=0datOA@mail.gmail.com","subject":"Re: Unexpected cherry-pick behaviour","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-12-14T19:33:20Z","receivedAt":"2013-12-14T19:33:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Antoine Pelisse writes:\n\n> If you only want to see the diff applied to master, you\n> should run:\n>\n> $ git diff --ours\n\nDoes \"git diff HEAD\" have the same/similar effect?\n\n> You can also have a look at what is currently being applied:\n>\n> $ git diff :1:gcc/tree-ssa-threadedge.c :3:gcc/tree-ssa-threadedge.c\n>\n> By the way, does anybody know a better way to do that ?\n\nIn a merge, you can say \"git diff ...MERGE_HEAD\" (three-dots). You\nshould be able to tell \"git show\" the commit you are trying to pick\nduring a cherry-pick, I think.\n"},{"id":"232029","messageId":"7vmwk3gr39.fsf@alter.siamese.dyndns.org","threadId":"35513","inReplyTo":"3FFF08967D2E480FA6B0E0EE3A72A8D9@PhilipOakley","subject":"Re: Unexpected cherry-pick behaviour","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-12-14T19:39:06Z","receivedAt":"2013-12-14T19:39:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Philip Oakley\" writes:\n\n> Would this be a good use of the\n> * Magic pathspecs like \":(icase)\n> that was recently released (v1.8.5 2Dec13) so that the merge stages\n> can be named.\n\nBecause the pathspec mechahism is for you to tell an operation that\nworks on a collection of paths (e.g. \"all the paths in the HEAD\",\n\"all the paths at stage #1 in the index\") to narrow the set it\noperates on down to only those that match, I do not think it is a\ngood match at all to what you are trying to do.\n"},{"id":"232031","messageId":"CALWbr2wZ2tid45u8_ew2PH7tco7XkqY=gaUFEPKm9UN8Xk9HLg@mail.gmail.com","threadId":"35513","inReplyTo":"7vvbyrgrcv.fsf@alter.siamese.dyndns.org","subject":"Re: Unexpected cherry-pick behaviour","fromName":"Antoine Pelisse","fromEmail":"apelisse@gmail.com","sentAt":"2013-12-14T19:47:10Z","receivedAt":"2013-12-14T19:47:10Z","isPatch":false,"sender":{"key":"apelisse@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1929644?v=4"},"body":"On Sat, Dec 14, 2013 at 8:33 PM, Junio C Hamano wrote:\n> Antoine Pelisse writes:\n>\n>> If you only want to see the diff applied to master, you\n>> should run:\n>>\n>> $ git diff --ours\n>\n> Does \"git diff HEAD\" have the same/similar effect?\n\nYes, it does produce the same output as --ours.\n\n>> You can also have a look at what is currently being applied:\n>>\n>> $ git diff :1:gcc/tree-ssa-threadedge.c :3:gcc/tree-ssa-threadedge.c\n>>\n>> By the way, does anybody know a better way to do that ?\n>\n> In a merge, you can say \"git diff ...MERGE_HEAD\" (three-dots). You\n> should be able to tell \"git show\" the commit you are trying to pick\n> during a cherry-pick, I think.\n\nThanks,\n"},{"id":"232043","messageId":"0172E9F1B5F945EB9294F1066C2FB72E@PhilipOakley","threadId":"35513","inReplyTo":"7vmwk3gr39.fsf@alter.siamese.dyndns.org","subject":"Re: Unexpected cherry-pick behaviour","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2013-12-15T09:33:34Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Junio C Hamano\" , Saturday, December 14, 2013 \n7:39 PM\n> \"Philip Oakley\" writes:\n>\n>> Would this be a good use of the\n>> * Magic pathspecs like \":(icase)\n>> that was recently released (v1.8.5 2Dec13) so that the merge stages\n>> can be named.\n>\n> Because the pathspec mechahism is for you to tell an operation that\n> works on a collection of paths (e.g. \"all the paths in the HEAD\",\n> \"all the paths at stage #1 in the index\") to narrow the set it\n> operates on down to only those that match, I do not think it is a\n> good match at all to what you are trying to do.\n>\n\nMy point was that the \":1:\" syntax already was a \"path at stage #1 in \nthe index\" indicator, and that it would be good to have a memorable name \nfor the :1:2:3: stages as per Antoine's query.\n\nIt maybe that my referring to it as a 'magic pathspec' was a mistake, \nbut the difficulty of remembering which number is ours:theirs:base still \nstands.\n\n(for general info; the :: format is defined in 'git revision \n(7)' as the last method for Specifying Revisions)\n\nPhilip\n--\nPS should the cc: git-owner@vger.kernel.org be dropped as effectively a \nduplicate? \n"},{"id":"232060","messageId":"B4E4F29CB20847DEB23F21255A040187@PhilipOakley","threadId":"35513","inReplyTo":"0172E9F1B5F945EB9294F1066C2FB72E@PhilipOakley","subject":"Re: Unexpected cherry-pick behaviour","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2013-12-16T18:53:56Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Philip Oakley\" \n> From: \"Junio C Hamano\" , Saturday, December 14, \n> 2013 7:39 PM\n>> \"Philip Oakley\" writes:\n>>\n>>> Would this be a good use of the\n>>> * Magic pathspecs like \":(icase)\n>>> that was recently released (v1.8.5 2Dec13) so that the merge \n>>> stages\n>>> can be named.\n>>\n>> Because the pathspec mechahism is for you to tell an operation that\n>> works on a collection of paths (e.g. \"all the paths in the HEAD\",\n>> \"all the paths at stage #1 in the index\") to narrow the set it\n>> operates on down to only those that match, I do not think it is a\n>> good match at all to what you are trying to do.\n>>\n>\n> My point was that the \":1:\" syntax already was a \"path at stage #1 in \n> the index\" indicator, and that it would be good to have a memorable \n> name for the :1:2:3: stages as per Antoine's query.\n\nCould someone point me at where is this syntax decoded?\nMy initial hunt around the code base didn't find the relevant location.\n\n>\n> It maybe that my referring to it as a 'magic pathspec' was a mistake, \n> but the difficulty of remembering which number is ours:theirs:base \n> still stands.\n>\n> (for general info; the :: format is defined in 'git revision \n> (7)' as the last method for Specifying Revisions)\n>\n> Philip\n> --\nPhilip\n"},{"id":"232079","messageId":"xmqqk3f4o8m8.fsf@gitster.dls.corp.google.com","threadId":"35513","inReplyTo":"B4E4F29CB20847DEB23F21255A040187@PhilipOakley","subject":"Re: Unexpected cherry-pick behaviour","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-12-16T20:15:27Z","receivedAt":"2013-12-16T20:15:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Philip Oakley\" writes:\n\n> From: \"Philip Oakley\" \n>> From: \"Junio C Hamano\" , Saturday, December 14,\n>> 2013 7:39 PM\n>>> \"Philip Oakley\" writes:\n>>>\n>>>> Would this be a good use of the\n>>>> * Magic pathspecs like \":(icase)\n>>>> that was recently released (v1.8.5 2Dec13) so that the merge\n>>>> stages\n>>>> can be named.\n>>>\n>>> Because the pathspec mechahism is for you to tell an operation that\n>>> works on a collection of paths (e.g. \"all the paths in the HEAD\",\n>>> \"all the paths at stage #1 in the index\") to narrow the set it\n>>> operates on down to only those that match, I do not think it is a\n>>> good match at all to what you are trying to do.\n>>>\n>>\n>> My point was that the \":1:\" syntax already was a \"path at stage #1\n>> in the index\" indicator, and that it would be good to have a\n>> memorable name for the :1:2:3: stages as per Antoine's query.\n>\n> Could someone point me at where is this syntax decoded?\n\nsha1_name.c (anything that turns name to object name goes there, I\nthink). Look for this comment:\n\n\t/*\n\t * sha1:path --> object name of path in ent sha1\n\t * :path -> object name of absolute path in index\n\t * :./path -> object name of path relative to cwd in index\n\t * :[0-3]:path -> object name of path in index at stage\n\t * :/foo -> recent commit matching foo\n\t */\n\nI do not think adding \":ours:path\" as a synonym to \":2:path\" adds\nenough value to make it worthwhilte to worry about breaking the\nexpectation of those who thought \"ours:path/name\" will be something\nthey could track if they wanted to.\n\n\n\n> My initial hunt around the code base didn't find the relevant location.\n>\n>>\n>> It maybe that my referring to it as a 'magic pathspec' was a\n>> mistake, but the difficulty of remembering which number is\n>> ours:theirs:base still stands.\n>>\n>> (for general info; the :: format is defined in 'git revision\n>> (7)' as the last method for Specifying Revisions)\n>>\n>> Philip\n>> --\n> Philip\n"}]}