{"thread":{"id":"51069","subject":"[PATCH 0/1] p4: fix \"Not a valid object name HEAD0\" when unshelving","startedAt":"2019-05-10T15:33:08Z","lastAt":"2019-05-29T11:42:18Z","messageCount":7,"participants":["Mike Mueller via GitGitGadget","Junio C Hamano","Johannes Schindelin"],"isPatch":true,"patchVersion":1,"patchTotal":1},"messages":[{"id":"375301","messageId":"pull.183.git.gitgitgadget@gmail.com","threadId":"51069","inReplyTo":null,"subject":"[PATCH 0/1] p4: fix \"Not a valid object name HEAD0\" when unshelving","fromName":"Mike Mueller via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2019-05-10T15:33:04Z","receivedAt":"2019-05-10T15:33:08Z","isPatch":true,"sender":{"key":"mmueller@vigilantsw.com","avatar":null},"body":"git p4 unshelve was failing with \"fatal: Not a valid object name HEAD0\" and\n\"Command failed: git cat-file commit HEAD^0\" on certain systems e.g. git\nversion 2.21.0.windows.1 + python 2.7.16\n\nIt seems that certain python pOpen implementations drop the ^ character when\ninvoked using a string instead of an array as first argument, which is what\nis done by extractLogMessageFromGitCommit.\n\nSolution is to use the array format of passing the command to fOpen, which\nis preferred (see https://docs.python.org/2/library/subprocess.html) and is\nused in other parts of this code anyway.\n\nMike Mueller (1):\n p4 unshelve: fix \"Not a valid object name HEAD0\"\n\n git-p4.py | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\n\nbase-commit: aeb582a98374c094361cba1bd756dc6307432c42\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-183%2Fmdymike%2Fmaint-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-183/mdymike/maint-v1\nPull-Request: https://github.com/gitgitgadget/git/pull/183\n-- \ngitgitgadget\n"},{"id":"375302","messageId":"fc580e902bedb92b5caea8047c1ddd1c9fc822f6.1557502383.git.gitgitgadget@gmail.com","threadId":"51069","inReplyTo":"pull.183.git.gitgitgadget@gmail.com","subject":"[PATCH 1/1] p4 unshelve: fix \"Not a valid object name HEAD0\"","fromName":"Mike Mueller via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2019-05-10T15:33:05Z","receivedAt":"2019-05-10T15:33:09Z","isPatch":true,"sender":{"key":"mmueller@vigilantsw.com","avatar":null},"body":"From: Mike Mueller \n\ngit p4 unshelve was failing with these errors on Windows:\n\nfatal: Not a valid object name HEAD0\nCommand failed: git cat-file commit HEAD^0\n\n(git version 2.21.0.windows.1, python 2.7.16)\n\nThe pOpen call used by git-p4 to invoke the git command can take either a\nstring or an array as a first argument. The array form is preferred\nhowever the extractLogMessageFromGitCommit method was using the string\nform, which makes the caller responsible for escaping the command text\nappropriately (see https://docs.python.org/2/library/subprocess.html)\n\nSomewhat ironically, the carat character is the escape character in\nWindows and so should be escaped (HEAD^^0). Without the extra carat, the\nOS was passing an escaped 0 to the git command instead, and the git\ncommand was rejecting the invalid object name \"HEAD0\"\n\nThe behaviour can be confirmed by typing ECHO HEAD^0 at the command-\nprompt, which emits HEAD0.\n\nThe solution is simply to use the array format of passing the command to\nfOpen, which is preferred and used in other parts of this code anyway.\n\nSigned-off-by: Mike Mueller \n---\n git-p4.py | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/git-p4.py b/git-p4.py\nindex 5b79920f46..0b5bfcbc5e 100755\n--- a/git-p4.py\n+++ b/git-p4.py\n@@ -737,7 +737,7 @@ def extractLogMessageFromGitCommit(commit):\n \n ## fixme: title is first line of commit, not 1st paragraph.\n foundTitle = False\n- for log in read_pipe_lines(\"git cat-file commit %s\" % commit):\n+ for log in read_pipe_lines([\"git\", \"cat-file\", \"commit\", commit]):\n if not foundTitle:\n if len(log) == 1:\n foundTitle = True\n-- \ngitgitgadget\n"},{"id":"375595","messageId":"xmqqd0kk70ib.fsf@gitster-ct.c.googlers.com","threadId":"51069","inReplyTo":"fc580e902bedb92b5caea8047c1ddd1c9fc822f6.1557502383.git.gitgitgadget@gmail.com","subject":"Re: [PATCH 1/1] p4 unshelve: fix \"Not a valid object name HEAD0\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-05-15T05:25:00Z","receivedAt":"2019-05-15T05:25:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Mike Mueller via GitGitGadget\" writes:\n\n> From: Mike Mueller \n>\n> git p4 unshelve was failing with these errors on Windows:\n>\n> fatal: Not a valid object name HEAD0\n> Command failed: git cat-file commit HEAD^0\n>\n> (git version 2.21.0.windows.1, python 2.7.16)\n>\n> The pOpen call used by git-p4 to invoke the git command can take either a\n> string or an array as a first argument. The array form is preferred\n> however the extractLogMessageFromGitCommit method was using the string\n> form, which makes the caller responsible for escaping the command text\n> appropriately (see https://docs.python.org/2/library/subprocess.html)\n\nRewrite the sentence that begin with \"The array form is\npreferred...\", as it is somewhat unreadable. \"X is preferred\nbecause Y; however Z was using the other one\" would be\nunderstandable.\n\n> Somewhat ironically, the carat character is the escape character in\n\ns/carat/caret/ everywhere.\n\n> Windows and so should be escaped (HEAD^^0). Without the extra carat, the\n> OS was passing an escaped 0 to the git command instead, and the git\n> command was rejecting the invalid object name \"HEAD0\"\n>\n> The behaviour can be confirmed by typing ECHO HEAD^0 at the command-\n> prompt, which emits HEAD0.\n>\n> The solution is simply to use the array format of passing the command to\n> fOpen, which is preferred and used in other parts of this code anyway.\n>\n> Signed-off-by: Mike Mueller \n> ---\n> git-p4.py | 2 +-\n> 1 file changed, 1 insertion(+), 1 deletion(-)\n>\n> diff --git a/git-p4.py b/git-p4.py\n> index 5b79920f46..0b5bfcbc5e 100755\n> --- a/git-p4.py\n> +++ b/git-p4.py\n> @@ -737,7 +737,7 @@ def extractLogMessageFromGitCommit(commit):\n> \n> ## fixme: title is first line of commit, not 1st paragraph.\n> foundTitle = False\n> - for log in read_pipe_lines(\"git cat-file commit %s\" % commit):\n> + for log in read_pipe_lines([\"git\", \"cat-file\", \"commit\", commit]):\n> if not foundTitle:\n> if len(log) == 1:\n> foundTitle = True\n"},{"id":"376332","messageId":"pull.183.v2.git.gitgitgadget@gmail.com","threadId":"51069","inReplyTo":"pull.183.git.gitgitgadget@gmail.com","subject":"[PATCH v2 0/1] p4: fix \"Not a valid object name HEAD0\" when unshelving","fromName":"Mike Mueller via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2019-05-28T18:15:45Z","receivedAt":"2019-05-28T18:15:49Z","isPatch":true,"sender":{"key":"mmueller@vigilantsw.com","avatar":null},"body":"git p4 unshelve was failing with \"fatal: Not a valid object name HEAD0\" and\n\"Command failed: git cat-file commit HEAD^0\" on certain systems e.g. git\nversion 2.21.0.windows.1 + python 2.7.16\n\nIt seems that certain python pOpen implementations drop the ^ character when\ninvoked using a string instead of an array as first argument, which is what\nis done by extractLogMessageFromGitCommit.\n\nSolution is to use the array format of passing the command to fOpen, which\nis preferred (see https://docs.python.org/2/library/subprocess.html) and is\nused in other parts of this code anyway.\n\nMike Mueller (1):\n p4 unshelve: fix \"Not a valid object name HEAD0\" on Windows\n\n git-p4.py | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\n\nbase-commit: aeb582a98374c094361cba1bd756dc6307432c42\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-183%2Fmdymike%2Fmaint-v2\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-183/mdymike/maint-v2\nPull-Request: https://github.com/gitgitgadget/git/pull/183\n\nRange-diff vs v1:\n\n 1: fc580e902b ! 1: 5e89d1aceb p4 unshelve: fix \"Not a valid object name HEAD0\"\n @@ -1,8 +1,8 @@\n Author: Mike Mueller \n \n - p4 unshelve: fix \"Not a valid object name HEAD0\"\n + p4 unshelve: fix \"Not a valid object name HEAD0\" on Windows\n \n - git p4 unshelve was failing with these errors on Windows:\n + git p4 unshelve was failing with these errors:\n \n fatal: Not a valid object name HEAD0\n Command failed: git cat-file commit HEAD^0\n @@ -10,21 +10,19 @@\n (git version 2.21.0.windows.1, python 2.7.16)\n \n The pOpen call used by git-p4 to invoke the git command can take either a\n - string or an array as a first argument. The array form is preferred\n - however the extractLogMessageFromGitCommit method was using the string\n - form, which makes the caller responsible for escaping the command text\n - appropriately (see https://docs.python.org/2/library/subprocess.html)\n -\n - Somewhat ironically, the carat character is the escape character in\n - Windows and so should be escaped (HEAD^^0). Without the extra carat, the\n - OS was passing an escaped 0 to the git command instead, and the git\n - command was rejecting the invalid object name \"HEAD0\"\n + string or an array as a first argument. The array form is preferred\n + because platform-specific escaping of special characters will be\n + handled automatically.(https://docs.python.org/2/library/subprocess.html)\n + The extractLogMessageFromGitCommit method was, however, using the string\n + form and so the caret (^) character in the HEAD^0 argument was not being\n + escaped on Windows. The caret happens to be the escape character, which\n + is why the git command was receiving HEAD0.\n \n The behaviour can be confirmed by typing ECHO HEAD^0 at the command-\n prompt, which emits HEAD0.\n \n The solution is simply to use the array format of passing the command to\n - fOpen, which is preferred and used in other parts of this code anyway.\n + fOpen, which is recommended and used in other parts of this code anyway.\n \n Signed-off-by: Mike Mueller \n \n\n-- \ngitgitgadget\n"},{"id":"376333","messageId":"5e89d1aceb9125231797a355e9465d1a41a1741c.1559067344.git.gitgitgadget@gmail.com","threadId":"51069","inReplyTo":"pull.183.v2.git.gitgitgadget@gmail.com","subject":"[PATCH v2 1/1] p4 unshelve: fix \"Not a valid object name HEAD0\" on Windows","fromName":"Mike Mueller via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2019-05-28T18:15:46Z","receivedAt":"2019-05-28T18:15:49Z","isPatch":true,"sender":{"key":"mmueller@vigilantsw.com","avatar":null},"body":"From: Mike Mueller \n\ngit p4 unshelve was failing with these errors:\n\nfatal: Not a valid object name HEAD0\nCommand failed: git cat-file commit HEAD^0\n\n(git version 2.21.0.windows.1, python 2.7.16)\n\nThe pOpen call used by git-p4 to invoke the git command can take either a\nstring or an array as a first argument. The array form is preferred\nbecause platform-specific escaping of special characters will be\nhandled automatically.(https://docs.python.org/2/library/subprocess.html)\nThe extractLogMessageFromGitCommit method was, however, using the string\nform and so the caret (^) character in the HEAD^0 argument was not being\nescaped on Windows. The caret happens to be the escape character, which\nis why the git command was receiving HEAD0.\n\nThe behaviour can be confirmed by typing ECHO HEAD^0 at the command-\nprompt, which emits HEAD0.\n\nThe solution is simply to use the array format of passing the command to\nfOpen, which is recommended and used in other parts of this code anyway.\n\nSigned-off-by: Mike Mueller \n---\n git-p4.py | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/git-p4.py b/git-p4.py\nindex 5b79920f46..0b5bfcbc5e 100755\n--- a/git-p4.py\n+++ b/git-p4.py\n@@ -737,7 +737,7 @@ def extractLogMessageFromGitCommit(commit):\n \n ## fixme: title is first line of commit, not 1st paragraph.\n foundTitle = False\n- for log in read_pipe_lines(\"git cat-file commit %s\" % commit):\n+ for log in read_pipe_lines([\"git\", \"cat-file\", \"commit\", commit]):\n if not foundTitle:\n if len(log) == 1:\n foundTitle = True\n-- \ngitgitgadget\n"},{"id":"376350","messageId":"xmqq7eaa1fjt.fsf@gitster-ct.c.googlers.com","threadId":"51069","inReplyTo":"5e89d1aceb9125231797a355e9465d1a41a1741c.1559067344.git.gitgitgadget@gmail.com","subject":"Re: [PATCH v2 1/1] p4 unshelve: fix \"Not a valid object name HEAD0\" on Windows","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-05-28T20:37:26Z","receivedAt":"2019-05-28T20:37:31Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Mike Mueller via GitGitGadget\" writes:\n\n> From: Mike Mueller \n>\n> git p4 unshelve was failing with these errors:\n>\n> fatal: Not a valid object name HEAD0\n> Command failed: git cat-file commit HEAD^0\n>\n> (git version 2.21.0.windows.1, python 2.7.16)\n>\n> The pOpen call used by git-p4 to invoke the git command can take either a\n> string or an array as a first argument. The array form is preferred\n> because platform-specific escaping of special characters will be\n> handled automatically.(https://docs.python.org/2/library/subprocess.html)\n> The extractLogMessageFromGitCommit method was, however, using the string\n> form and so the caret (^) character in the HEAD^0 argument was not being\n> escaped on Windows. The caret happens to be the escape character, which\n> is why the git command was receiving HEAD0.\n\nIn the output from\n\n git grep 'read_pipe_lines(\"'\n\ntogether with a few hits to harmless constant command line, we find\nthis line\n\n diff = read_pipe_lines(\"git diff-tree -r %s \\\"%s^\\\" \\\"%s\\\"\" % (self.diffOpts, id, id))\n\nWould the caret we see there cause a similar problem? It would end\nup running something like\n\n $ git diff-tree -r -M \"HEAD^\" \"HEAD\"\n\n"},{"id":"376392","messageId":"nycvar.QRO.7.76.6.1905291341060.44@tvgsbejvaqbjf.bet","threadId":"51069","inReplyTo":"xmqq7eaa1fjt.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH v2 1/1] p4 unshelve: fix \"Not a valid object name HEAD0\" on Windows","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-05-29T11:41:54Z","receivedAt":"2019-05-29T11:42:18Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Tue, 28 May 2019, Junio C Hamano wrote:\n\n> \"Mike Mueller via GitGitGadget\" writes:\n>\n> > From: Mike Mueller \n> >\n> > git p4 unshelve was failing with these errors:\n> >\n> > fatal: Not a valid object name HEAD0\n> > Command failed: git cat-file commit HEAD^0\n> >\n> > (git version 2.21.0.windows.1, python 2.7.16)\n> >\n> > The pOpen call used by git-p4 to invoke the git command can take either a\n> > string or an array as a first argument. The array form is preferred\n> > because platform-specific escaping of special characters will be\n> > handled automatically.(https://docs.python.org/2/library/subprocess.html)\n> > The extractLogMessageFromGitCommit method was, however, using the string\n> > form and so the caret (^) character in the HEAD^0 argument was not being\n> > escaped on Windows. The caret happens to be the escape character, which\n> > is why the git command was receiving HEAD0.\n>\n> In the output from\n>\n> git grep 'read_pipe_lines(\"'\n>\n> together with a few hits to harmless constant command line, we find\n> this line\n>\n> diff = read_pipe_lines(\"git diff-tree -r %s \\\"%s^\\\" \\\"%s\\\"\" % (self.diffOpts, id, id))\n>\n> Would the caret we see there cause a similar problem? It would end\n> up running something like\n>\n> $ git diff-tree -r -M \"HEAD^\" \"HEAD\"\n\nI think you're right!\n\nIn addition, I wonder whether we would want to replace the `^` by a `~`,\nwhich would have the same effect, but does not need quoting in Bash nor\nCMD.\n\nCiao,\nDscho\n"}]}