{"thread":{"id":"52263","subject":"[PATCH 0/2] Feature: New Variable git-p4.binary","startedAt":"2019-11-13T21:14:29Z","lastAt":"2019-12-03T15:59:58Z","messageCount":17,"participants":["Ben Keene via GitGitGadget","Junio C Hamano","Luke Diamand","Ben Keene"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"386144","messageId":"pull.465.git.1573679665.gitgitgadget@gmail.com","threadId":"52263","inReplyTo":null,"subject":"[PATCH 0/2] Feature: New Variable git-p4.binary","fromName":"Ben Keene via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2019-11-13T21:14:23Z","receivedAt":"2019-11-13T21:14:29Z","isPatch":true,"sender":{"key":"seraphire@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22523774?v=4"},"body":"Issue: Using git-p4.py on Windows does not resolve properly to the p4.exe\nbinary in all instances.\n\nTwo new code features are added to resolve the p4 executable location:\n\n 1. A new variable, git-p4.binary, has been added that takes precedence over\n the default p4 executable name. If this git option is set and the\n path.exists() passes for this file it will be used as executable for the \n system.popen calls.\n \n \n 2. If the new variable git-p4.binary is not set, the program checks if the\n operating system is Windows. If it is, the executable is changed to\n 'p4.exe'. All other operating systems\n (those that do not report 'Windows' in the platform.system() call)\n continue to use the current executable of 'p4'.\n\nBen Keene (2):\n Cast byte strings to unicode strings in python3\n Added general variable git-p4.binary and added a default for windows\n of 'P4.EXE'\n\n Documentation/git-p4.txt | 5 +++++\n git-p4.py | 40 +++++++++++++++++++++++++++++++++++++---\n 2 files changed, 42 insertions(+), 3 deletions(-)\n\n\nbase-commit: d9f6f3b6195a0ca35642561e530798ad1469bd41\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-465%2Fseraphire%2Fseraphire%2Fp4-binary-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-465/seraphire/seraphire/p4-binary-v1\nPull-Request: https://github.com/gitgitgadget/git/pull/465\n-- \ngitgitgadget\n"},{"id":"386145","messageId":"98bae92fda9ca01d01b2e9fb70b04b00470e7bec.1573679665.git.gitgitgadget@gmail.com","threadId":"52263","inReplyTo":"pull.465.git.1573679665.gitgitgadget@gmail.com","subject":"[PATCH 2/2] Added general variable git-p4.binary and added a default for windows of 'P4.EXE'","fromName":"Ben Keene via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2019-11-13T21:14:25Z","receivedAt":"2019-11-13T21:14:32Z","isPatch":true,"sender":{"key":"seraphire@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22523774?v=4"},"body":"From: Ben Keene \n\nSigned-off-by: Ben Keene \n---\n Documentation/git-p4.txt | 5 +++++\n git-p4.py | 14 +++++++++++++-\n 2 files changed, 18 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt\nindex 3494a1db3e..e206e69250 100644\n--- a/Documentation/git-p4.txt\n+++ b/Documentation/git-p4.txt\n@@ -547,6 +547,11 @@ git-p4.retries::\n \tSet the value to 0 to disable retries or if your p4 version\n \tdoes not support retries (pre 2012.2).\n \n+git-p4.binary::\n+\tSpecifies the p4 executable used by git-p4 to process commands.\n+\tThe default value for Windows is `p4.exe` and for all other\n+\tsystems the default is `p4`. \n+\n Clone and sync variables\n ~~~~~~~~~~~~~~~~~~~~~~~~\n git-p4.syncFromOrigin::\ndiff --git a/git-p4.py b/git-p4.py\nindex 6e8b3a26cd..160d966ee1 100755\n--- a/git-p4.py\n+++ b/git-p4.py\n@@ -26,6 +26,8 @@\n import zlib\n import ctypes\n import errno\n+import os.path\n+from os import path\n \n # support basestring in python3\n try:\n@@ -85,7 +87,17 @@ def p4_build_cmd(cmd):\n location. It means that hooking into the environment, or other configuration\n can be done more easily.\n \"\"\"\n- real_cmd = [\"p4\"]\n+ # Look for the P4 binary\n+ p4bin = gitConfig(\"git-p4.binary\")\n+ real_cmd = []\n+ if p4bin != \"\":\n+ if path.exists(p4bin):\n+ real_cmd = [p4bin]\n+ if real_cmd == []:\n+ if (platform.system() == \"Windows\"):\n+ real_cmd = [\"p4.exe\"] \n+ else:\n+ real_cmd = [\"p4\"]\n \n user = gitConfig(\"git-p4.user\")\n if len(user) > 0:\n-- \ngitgitgadget\n"},{"id":"386146","messageId":"0bca930ff82623bbef172b4cb6c36ef8e5c46098.1573679665.git.gitgitgadget@gmail.com","threadId":"52263","inReplyTo":"pull.465.git.1573679665.gitgitgadget@gmail.com","subject":"[PATCH 1/2] Cast byte strings to unicode strings in python3","fromName":"Ben Keene via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2019-11-13T21:14:24Z","receivedAt":"2019-11-13T21:14:33Z","isPatch":true,"sender":{"key":"seraphire@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22523774?v=4"},"body":"From: Ben Keene \n\nSigned-off-by: Ben Keene \n---\n git-p4.py | 26 ++++++++++++++++++++++++--\n 1 file changed, 24 insertions(+), 2 deletions(-)\n\ndiff --git a/git-p4.py b/git-p4.py\nindex 60c73b6a37..6e8b3a26cd 100755\n--- a/git-p4.py\n+++ b/git-p4.py\n@@ -36,12 +36,22 @@\n unicode = str\n bytes = bytes\n basestring = (str,bytes)\n+ isunicode = True\n+ def ustring(text):\n+ \"\"\"Returns the byte string as a unicode string\"\"\"\n+ if text == '' or text == b'':\n+ return ''\n+ return unicode(text, \"utf-8\")\n else:\n # 'unicode' exists, must be Python 2\n str = str\n unicode = unicode\n bytes = str\n basestring = basestring\n+ isunicode = False\n+ def ustring(text):\n+ \"\"\"Returns the byte string unchanged\"\"\"\n+ return text\n \n try:\n from subprocess import CalledProcessError\n@@ -196,6 +206,8 @@ def read_pipe_full(c):\n expand = isinstance(c,basestring)\n p = subprocess.Popen(c, stdout=subprocess.PIPE, stderr=subprocess.PIPE, shell=expand)\n (out, err) = p.communicate()\n+ out = ustring(out)\n+ err = ustring(err)\n return (p.returncode, out, err)\n \n def read_pipe(c, ignore_error=False):\n@@ -263,6 +275,7 @@ def p4_has_move_command():\n cmd = p4_build_cmd([\"move\", \"-k\", \"@from\", \"@to\"])\n p = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE)\n (out, err) = p.communicate()\n+ err = ustring(err)\n # return code will be 1 in either case\n if err.find(\"Invalid option\") >= 0:\n return False\n@@ -646,10 +659,18 @@ def p4CmdList(cmd, stdin=None, stdin_mode='w+b', cb=None, skip_info=False,\n if skip_info:\n if 'code' in entry and entry['code'] == 'info':\n continue\n+ if b'code' in entry and entry[b'code'] == b'info':\n+ continue\n if cb is not None:\n cb(entry)\n else:\n- result.append(entry)\n+ if isunicode:\n+ out = {}\n+ for key, value in entry.items():\n+ out[ustring(key)] = ustring(value)\n+ result.append(out)\n+ else:\n+ result.append(entry)\n except EOFError:\n pass\n exitCode = p4.wait()\n@@ -792,7 +813,7 @@ def gitConfig(key, typeSpecifier=None):\n cmd += [ key ]\n s = read_pipe(cmd, ignore_error=True)\n _gitConfig[key] = s.strip()\n- return _gitConfig[key]\n+ return ustring(_gitConfig[key])\n \n def gitConfigBool(key):\n \"\"\"Return a bool, using git config --bool. It is True only if the\n@@ -860,6 +881,7 @@ def branch_exists(branch):\n cmd = [ \"git\", \"rev-parse\", \"--symbolic\", \"--verify\", branch ]\n p = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE)\n out, _ = p.communicate()\n+ out = ustring(out)\n if p.returncode:\n return False\n # expect exactly one line of output: the branch name\n-- \ngitgitgadget\n\n"},{"id":"386156","messageId":"xmqq5zjn9oaz.fsf@gitster-ct.c.googlers.com","threadId":"52263","inReplyTo":"pull.465.git.1573679665.gitgitgadget@gmail.com","subject":"Re: [PATCH 0/2] Feature: New Variable git-p4.binary","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-11-14T02:36:36Z","receivedAt":"2019-11-14T02:36:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Ben Keene via GitGitGadget\" writes:\n\n> Issue: Using git-p4.py on Windows does not resolve properly to the p4.exe\n> binary in all instances.\n>\n> Two new code features are added to resolve the p4 executable location:\n>\n> 1. A new variable, git-p4.binary, has been added that takes precedence over\n> the default p4 executable name. If this git option is set and the\n> path.exists() passes for this file it will be used as executable for the \n> system.popen calls.\n> \n> \n> 2. If the new variable git-p4.binary is not set, the program checks if the\n> operating system is Windows. If it is, the executable is changed to\n> 'p4.exe'. All other operating systems\n> (those that do not report 'Windows' in the platform.system() call)\n> continue to use the current executable of 'p4'.\n\nI do not use Windows nor git-p4, but the above two changes make\nsense to me at the design level. One thing that needs to be updated\nis the configuration variable, though. It is more in line with the\nother parts of the system to name this \"git-p4.program\", because\nbinary-ness does not matter much to you, as long as the named thing\nworks correctly as \"p4\" program replacement.\n\nSeeing \"gpg.program\" is used in a similar way, it also is tempting\nto call it \"p4.program\", but no other parts of Git other than\n\"git-p4\" uses P4, and the \"git-p4.\" prefix is to collect variables\nrelated to \"git-p4\" together, so calling it \"p4.program\" may not be\na good idea---it would hurt discoverability. \"git-p4.p4program\"\nmay be OK, if we anticipate that git-p4 may need to use (and its\nusers need to specify paths to) external programs other than \"p4\",\nbut it probably is overkill.\n\nThanks.\n"},{"id":"386177","messageId":"CAE5ih7-_ZESWAGAiXL4vT-P0aVYtrOAHn6dbhsfTmmeKVkSUWA@mail.gmail.com","threadId":"52263","inReplyTo":"xmqq5zjn9oaz.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH 0/2] Feature: New Variable git-p4.binary","fromName":"Luke Diamand","fromEmail":"luke@diamand.org","sentAt":"2019-11-14T09:53:10Z","receivedAt":"2019-11-14T09:53:02Z","isPatch":true,"sender":{"key":"luke@diamand.org","avatar":"https://avatars.githubusercontent.com/u/5330967?v=4"},"body":"On Thu, 14 Nov 2019 at 02:36, Junio C Hamano wrote:\n>\n> \"Ben Keene via GitGitGadget\" writes:\n>\n> > Issue: Using git-p4.py on Windows does not resolve properly to the p4.exe\n> > binary in all instances.\n> >\n> > Two new code features are added to resolve the p4 executable location:\n> >\n> > 1. A new variable, git-p4.binary, has been added that takes precedence over\n> > the default p4 executable name. If this git option is set and the\n> > path.exists() passes for this file it will be used as executable for the\n> > system.popen calls.\n> >\n> >\n> > 2. If the new variable git-p4.binary is not set, the program checks if the\n> > operating system is Windows. If it is, the executable is changed to\n> > 'p4.exe'. All other operating systems\n> > (those that do not report 'Windows' in the platform.system() call)\n> > continue to use the current executable of 'p4'.\n>\n> I do not use Windows nor git-p4, but the above two changes make\n> sense to me at the design level. One thing that needs to be updated\n> is the configuration variable, though. It is more in line with the\n> other parts of the system to name this \"git-p4.program\", because\n> binary-ness does not matter much to you, as long as the named thing\n> works correctly as \"p4\" program replacement.\n>\n> Seeing \"gpg.program\" is used in a similar way, it also is tempting\n> to call it \"p4.program\", but no other parts of Git other than\n> \"git-p4\" uses P4, and the \"git-p4.\" prefix is to collect variables\n> related to \"git-p4\" together, so calling it \"p4.program\" may not be\n> a good idea---it would hurt discoverability. \"git-p4.p4program\"\n> may be OK, if we anticipate that git-p4 may need to use (and its\n> users need to specify paths to) external programs other than \"p4\",\n> but it probably is overkill.\n>\n> Thanks.\n\nThere's some trailing whitespace in 98bae, can we get that tidied up?\n\nOtherwise, modulo Junio's comments, it looks good.\n\nI agree that \"git-p4.binary\" might be harder to discover (\"Oh, I\nassumed that enabled binary mode!\"). p4program should be fine.\n"},{"id":"386200","messageId":"CAAvvW8R4ZDofFaptW60=QvuSXRFS4U7zdNRGfUcE4iynRDrhFg@mail.gmail.com","threadId":"52263","inReplyTo":"CAE5ih7-_ZESWAGAiXL4vT-P0aVYtrOAHn6dbhsfTmmeKVkSUWA@mail.gmail.com","subject":"Re: [PATCH 0/2] Feature: New Variable git-p4.binary","fromName":"Ben Keene","fromEmail":"seraphire@gmail.com","sentAt":"2019-11-14T20:16:49Z","receivedAt":"2019-11-14T20:17:03Z","isPatch":true,"sender":{"key":"seraphire@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22523774?v=4"},"body":"On Thu, Nov 14, 2019 at 4:52 AM Luke Diamand wrote:\n>\n> On Thu, 14 Nov 2019 at 02:36, Junio C Hamano wrote:\n> >\n> > \"Ben Keene via GitGitGadget\" writes:\n> >\n> > > Issue: Using git-p4.py on Windows does not resolve properly to the p4.exe\n> > > binary in all instances.\n> > >\n> > > Two new code features are added to resolve the p4 executable location:\n> > >\n> > > 1. A new variable, git-p4.binary, has been added that takes precedence over\n> > > the default p4 executable name. If this git option is set and the\n> > > path.exists() passes for this file it will be used as executable for the\n> > > system.popen calls.\n> > >\n> > >\n> > > 2. If the new variable git-p4.binary is not set, the program checks if the\n> > > operating system is Windows. If it is, the executable is changed to\n> > > 'p4.exe'. All other operating systems\n> > > (those that do not report 'Windows' in the platform.system() call)\n> > > continue to use the current executable of 'p4'.\n> >\n> > I do not use Windows nor git-p4, but the above two changes make\n> > sense to me at the design level. One thing that needs to be updated\n> > is the configuration variable, though. It is more in line with the\n> > other parts of the system to name this \"git-p4.program\", because\n> > binary-ness does not matter much to you, as long as the named thing\n> > works correctly as \"p4\" program replacement.\n> >\n> > Seeing \"gpg.program\" is used in a similar way, it also is tempting\n> > to call it \"p4.program\", but no other parts of Git other than\n> > \"git-p4\" uses P4, and the \"git-p4.\" prefix is to collect variables\n> > related to \"git-p4\" together, so calling it \"p4.program\" may not be\n> > a good idea---it would hurt discoverability. \"git-p4.p4program\"\n> > may be OK, if we anticipate that git-p4 may need to use (and its\n> > users need to specify paths to) external programs other than \"p4\",\n> > but it probably is overkill.\n> >\n> > Thanks.\n>\n> There's some trailing whitespace in 98bae, can we get that tidied up?\n>\n> Otherwise, modulo Junio's comments, it looks good.\n>\n> I agree that \"git-p4.binary\" might be harder to discover (\"Oh, I\n> assumed that enabled binary mode!\"). p4program should be fine.\n\nI have updated the Pull Request to change the variable name from\n'binary' to 'p4program'. I have also updated the PR description.\n\nHere's the new commit message:\n\nIssue: Using git-p4.py on Windows does not resolve properly to the\np4.exe binary in all instances.\n\nChanges since v1:\nCommit: (dc6817e) 2019-11-14\n\nRenamed the variable \"git-p4.binary\" to \"git-p4.p4program\"\n\nv1:\n\nTwo new code features are added to resolve the p4 executable location:\n\nA new variable, git-p4.binary, has been added that takes precedence\nover the default\np4 executable name. If this git option is set and the path.exists()\npasses for this file\nit will be used as executable for the system.popen calls.\n\nIf the new variable git-p4.binary is not set, the program checks if\nthe operating system\nis Windows. If it is, the executable is changed to 'p4.exe'. All other\noperating systems\n(those that do not report 'Windows' in the platform.system() call)\ncontinue to use the\ncurrent executable of 'p4'.\n"},{"id":"386268","messageId":"CAE5ih7--QUmDttrCCtoTNZ0FTLOnu5gQ4yzwKzAnE3-dmhD=Ag@mail.gmail.com","threadId":"52263","inReplyTo":"CAAvvW8R4ZDofFaptW60=QvuSXRFS4U7zdNRGfUcE4iynRDrhFg@mail.gmail.com","subject":"Re: [PATCH 0/2] Feature: New Variable git-p4.binary","fromName":"Luke Diamand","fromEmail":"luke@diamand.org","sentAt":"2019-11-15T09:28:45Z","receivedAt":"2019-11-15T09:28:12Z","isPatch":true,"sender":{"key":"luke@diamand.org","avatar":"https://avatars.githubusercontent.com/u/5330967?v=4"},"body":"On Thu, 14 Nov 2019 at 20:17, Ben Keene wrote:\n>\n> On Thu, Nov 14, 2019 at 4:52 AM Luke Diamand wrote:\n> >\n> > On Thu, 14 Nov 2019 at 02:36, Junio C Hamano wrote:\n> > >\n> > > \"Ben Keene via GitGitGadget\" writes:\n> > >\n> > > > Issue: Using git-p4.py on Windows does not resolve properly to the p4.exe\n> > > > binary in all instances.\n> > > >\n> > > > Two new code features are added to resolve the p4 executable location:\n> > > >\n> > > > 1. A new variable, git-p4.binary, has been added that takes precedence over\n> > > > the default p4 executable name. If this git option is set and the\n> > > > path.exists() passes for this file it will be used as executable for the\n> > > > system.popen calls.\n> > > >\n> > > >\n> > > > 2. If the new variable git-p4.binary is not set, the program checks if the\n> > > > operating system is Windows. If it is, the executable is changed to\n> > > > 'p4.exe'. All other operating systems\n> > > > (those that do not report 'Windows' in the platform.system() call)\n> > > > continue to use the current executable of 'p4'.\n> > >\n> > > I do not use Windows nor git-p4, but the above two changes make\n> > > sense to me at the design level. One thing that needs to be updated\n> > > is the configuration variable, though. It is more in line with the\n> > > other parts of the system to name this \"git-p4.program\", because\n> > > binary-ness does not matter much to you, as long as the named thing\n> > > works correctly as \"p4\" program replacement.\n> > >\n> > > Seeing \"gpg.program\" is used in a similar way, it also is tempting\n> > > to call it \"p4.program\", but no other parts of Git other than\n> > > \"git-p4\" uses P4, and the \"git-p4.\" prefix is to collect variables\n> > > related to \"git-p4\" together, so calling it \"p4.program\" may not be\n> > > a good idea---it would hurt discoverability. \"git-p4.p4program\"\n> > > may be OK, if we anticipate that git-p4 may need to use (and its\n> > > users need to specify paths to) external programs other than \"p4\",\n> > > but it probably is overkill.\n> > >\n> > > Thanks.\n> >\n> > There's some trailing whitespace in 98bae, can we get that tidied up?\n> >\n> > Otherwise, modulo Junio's comments, it looks good.\n> >\n> > I agree that \"git-p4.binary\" might be harder to discover (\"Oh, I\n> > assumed that enabled binary mode!\"). p4program should be fine.\n>\n> I have updated the Pull Request to change the variable name from\n> 'binary' to 'p4program'. I have also updated the PR description.\n\nI couldn't figure out how to download this. I tried p4-binary-1, but\nit gave me the old one. Maybe I was just using it wrong?\n\nCould you update the commit message to say why we needed to do this;\nif we have to dig through history in the future to figure out what's\ngoing on, it will be a lot easier if the explanation is in the commit\nmessage, rather than in an email thread. The branch description on\ngitgitgadget won't be around either.\n\n>\n> Here's the new commit message:\n>\n> Issue: Using git-p4.py on Windows does not resolve properly to the\n> p4.exe binary in all instances.\n>\n> Changes since v1:\n> Commit: (dc6817e) 2019-11-14\n>\n> Renamed the variable \"git-p4.binary\" to \"git-p4.p4program\"\n>\n> v1:\n>\n> Two new code features are added to resolve the p4 executable location:\n>\n> A new variable, git-p4.binary, has been added that takes precedence\n> over the default\n> p4 executable name. If this git option is set and the path.exists()\n> passes for this file\n> it will be used as executable for the system.popen calls.\n>\n> If the new variable git-p4.binary is not set, the program checks if\n> the operating system\n> is Windows. If it is, the executable is changed to 'p4.exe'. All other\n> operating systems\n> (those that do not report 'Windows' in the platform.system() call)\n> continue to use the\n> current executable of 'p4'.\n"},{"id":"386330","messageId":"pull.465.v2.git.1573828978.gitgitgadget@gmail.com","threadId":"52263","inReplyTo":"pull.465.git.1573679665.gitgitgadget@gmail.com","subject":"[PATCH v2 0/3] Feature: New Variable git-p4.p4program","fromName":"Ben Keene via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2019-11-15T14:42:55Z","receivedAt":"2019-11-15T14:43:03Z","isPatch":true,"sender":{"key":"seraphire@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22523774?v=4"},"body":"Issue: Using git-p4.py on Windows does not resolve properly to the p4.exe\nbinary in all instances.\n\nChanges since v1: Commit: (dc6817e) 2019-11-14\n\nRenamed the variable \"git-p4.binary\" to \"git-p4.p4program\" per the thread\ndiscussion.\n\nv1:\n\nTwo new code features are added to resolve the p4 executable location:\n\n 1. A new variable, git-p4.binary, has been added that takes precedence over\n the default p4 executable name. If this git option is set and the\n path.exists() passes for this file it will be used as executable for the \n system.popen calls.\n \n \n 2. If the new variable git-p4.binary is not set, the program checks if the\n operating system is Windows. If it is, the executable is changed to\n 'p4.exe'. All other operating systems\n (those that do not report 'Windows' in the platform.system() call)\n continue to use the current executable of 'p4'.\n\nBen Keene (3):\n Cast byte strings to unicode strings in python3\n Added general variable git-p4.binary and added a default for windows\n of 'P4.EXE'\n Changed the name of the parameter from git-p4.binary to\n git-p4.p4program\n\n Documentation/git-p4.txt | 5 +++++\n git-p4.py | 40 +++++++++++++++++++++++++++++++++++++---\n 2 files changed, 42 insertions(+), 3 deletions(-)\n\n\nbase-commit: d9f6f3b6195a0ca35642561e530798ad1469bd41\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-465%2Fseraphire%2Fseraphire%2Fp4-binary-v2\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-465/seraphire/seraphire/p4-binary-v2\nPull-Request: https://github.com/gitgitgadget/git/pull/465\n\nRange-diff vs v1:\n\n 1: 0bca930ff8 = 1: 0bca930ff8 Cast byte strings to unicode strings in python3\n 2: 98bae92fda = 2: 98bae92fda Added general variable git-p4.binary and added a default for windows of 'P4.EXE'\n -: ---------- > 3: dc6817eea3 Changed the name of the parameter from git-p4.binary to git-p4.p4program\n\n-- \ngitgitgadget\n"},{"id":"386331","messageId":"0bca930ff82623bbef172b4cb6c36ef8e5c46098.1573828978.git.gitgitgadget@gmail.com","threadId":"52263","inReplyTo":"pull.465.v2.git.1573828978.gitgitgadget@gmail.com","subject":"[PATCH v2 1/3] Cast byte strings to unicode strings in python3","fromName":"Ben Keene via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2019-11-15T14:42:56Z","receivedAt":"2019-11-15T14:43:03Z","isPatch":true,"sender":{"key":"seraphire@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22523774?v=4"},"body":"From: Ben Keene \n\nSigned-off-by: Ben Keene \n---\n git-p4.py | 26 ++++++++++++++++++++++++--\n 1 file changed, 24 insertions(+), 2 deletions(-)\n\ndiff --git a/git-p4.py b/git-p4.py\nindex 60c73b6a37..6e8b3a26cd 100755\n--- a/git-p4.py\n+++ b/git-p4.py\n@@ -36,12 +36,22 @@\n unicode = str\n bytes = bytes\n basestring = (str,bytes)\n+ isunicode = True\n+ def ustring(text):\n+ \"\"\"Returns the byte string as a unicode string\"\"\"\n+ if text == '' or text == b'':\n+ return ''\n+ return unicode(text, \"utf-8\")\n else:\n # 'unicode' exists, must be Python 2\n str = str\n unicode = unicode\n bytes = str\n basestring = basestring\n+ isunicode = False\n+ def ustring(text):\n+ \"\"\"Returns the byte string unchanged\"\"\"\n+ return text\n \n try:\n from subprocess import CalledProcessError\n@@ -196,6 +206,8 @@ def read_pipe_full(c):\n expand = isinstance(c,basestring)\n p = subprocess.Popen(c, stdout=subprocess.PIPE, stderr=subprocess.PIPE, shell=expand)\n (out, err) = p.communicate()\n+ out = ustring(out)\n+ err = ustring(err)\n return (p.returncode, out, err)\n \n def read_pipe(c, ignore_error=False):\n@@ -263,6 +275,7 @@ def p4_has_move_command():\n cmd = p4_build_cmd([\"move\", \"-k\", \"@from\", \"@to\"])\n p = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE)\n (out, err) = p.communicate()\n+ err = ustring(err)\n # return code will be 1 in either case\n if err.find(\"Invalid option\") >= 0:\n return False\n@@ -646,10 +659,18 @@ def p4CmdList(cmd, stdin=None, stdin_mode='w+b', cb=None, skip_info=False,\n if skip_info:\n if 'code' in entry and entry['code'] == 'info':\n continue\n+ if b'code' in entry and entry[b'code'] == b'info':\n+ continue\n if cb is not None:\n cb(entry)\n else:\n- result.append(entry)\n+ if isunicode:\n+ out = {}\n+ for key, value in entry.items():\n+ out[ustring(key)] = ustring(value)\n+ result.append(out)\n+ else:\n+ result.append(entry)\n except EOFError:\n pass\n exitCode = p4.wait()\n@@ -792,7 +813,7 @@ def gitConfig(key, typeSpecifier=None):\n cmd += [ key ]\n s = read_pipe(cmd, ignore_error=True)\n _gitConfig[key] = s.strip()\n- return _gitConfig[key]\n+ return ustring(_gitConfig[key])\n \n def gitConfigBool(key):\n \"\"\"Return a bool, using git config --bool. It is True only if the\n@@ -860,6 +881,7 @@ def branch_exists(branch):\n cmd = [ \"git\", \"rev-parse\", \"--symbolic\", \"--verify\", branch ]\n p = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE)\n out, _ = p.communicate()\n+ out = ustring(out)\n if p.returncode:\n return False\n # expect exactly one line of output: the branch name\n-- \ngitgitgadget\n\n"},{"id":"386332","messageId":"dc6817eea3005f3b891506dfd5fb23cec0a9d76c.1573828978.git.gitgitgadget@gmail.com","threadId":"52263","inReplyTo":"pull.465.v2.git.1573828978.gitgitgadget@gmail.com","subject":"[PATCH v2 3/3] Changed the name of the parameter from git-p4.binary to git-p4.p4program","fromName":"Ben Keene via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2019-11-15T14:42:58Z","receivedAt":"2019-11-15T14:43:04Z","isPatch":true,"sender":{"key":"seraphire@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22523774?v=4"},"body":"From: Ben Keene \n\nSigned-off-by: Ben Keene \n---\n Documentation/git-p4.txt | 2 +-\n git-p4.py | 2 +-\n 2 files changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt\nindex e206e69250..21ef100c28 100644\n--- a/Documentation/git-p4.txt\n+++ b/Documentation/git-p4.txt\n@@ -547,7 +547,7 @@ git-p4.retries::\n \tSet the value to 0 to disable retries or if your p4 version\n \tdoes not support retries (pre 2012.2).\n \n-git-p4.binary::\n+git-p4.p4program::\n \tSpecifies the p4 executable used by git-p4 to process commands.\n \tThe default value for Windows is `p4.exe` and for all other\n \tsystems the default is `p4`. \ndiff --git a/git-p4.py b/git-p4.py\nindex 160d966ee1..4fbb7344f1 100755\n--- a/git-p4.py\n+++ b/git-p4.py\n@@ -88,7 +88,7 @@ def p4_build_cmd(cmd):\n can be done more easily.\n \"\"\"\n # Look for the P4 binary\n- p4bin = gitConfig(\"git-p4.binary\")\n+ p4bin = gitConfig(\"git-p4.p4program\")\n real_cmd = []\n if p4bin != \"\":\n if path.exists(p4bin):\n-- \ngitgitgadget\n"},{"id":"386333","messageId":"98bae92fda9ca01d01b2e9fb70b04b00470e7bec.1573828978.git.gitgitgadget@gmail.com","threadId":"52263","inReplyTo":"pull.465.v2.git.1573828978.gitgitgadget@gmail.com","subject":"[PATCH v2 2/3] Added general variable git-p4.binary and added a default for windows of 'P4.EXE'","fromName":"Ben Keene via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2019-11-15T14:42:57Z","receivedAt":"2019-11-15T14:43:05Z","isPatch":true,"sender":{"key":"seraphire@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22523774?v=4"},"body":"From: Ben Keene \n\nSigned-off-by: Ben Keene \n---\n Documentation/git-p4.txt | 5 +++++\n git-p4.py | 14 +++++++++++++-\n 2 files changed, 18 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt\nindex 3494a1db3e..e206e69250 100644\n--- a/Documentation/git-p4.txt\n+++ b/Documentation/git-p4.txt\n@@ -547,6 +547,11 @@ git-p4.retries::\n \tSet the value to 0 to disable retries or if your p4 version\n \tdoes not support retries (pre 2012.2).\n \n+git-p4.binary::\n+\tSpecifies the p4 executable used by git-p4 to process commands.\n+\tThe default value for Windows is `p4.exe` and for all other\n+\tsystems the default is `p4`. \n+\n Clone and sync variables\n ~~~~~~~~~~~~~~~~~~~~~~~~\n git-p4.syncFromOrigin::\ndiff --git a/git-p4.py b/git-p4.py\nindex 6e8b3a26cd..160d966ee1 100755\n--- a/git-p4.py\n+++ b/git-p4.py\n@@ -26,6 +26,8 @@\n import zlib\n import ctypes\n import errno\n+import os.path\n+from os import path\n \n # support basestring in python3\n try:\n@@ -85,7 +87,17 @@ def p4_build_cmd(cmd):\n location. It means that hooking into the environment, or other configuration\n can be done more easily.\n \"\"\"\n- real_cmd = [\"p4\"]\n+ # Look for the P4 binary\n+ p4bin = gitConfig(\"git-p4.binary\")\n+ real_cmd = []\n+ if p4bin != \"\":\n+ if path.exists(p4bin):\n+ real_cmd = [p4bin]\n+ if real_cmd == []:\n+ if (platform.system() == \"Windows\"):\n+ real_cmd = [\"p4.exe\"] \n+ else:\n+ real_cmd = [\"p4\"]\n \n user = gitConfig(\"git-p4.user\")\n if len(user) > 0:\n-- \ngitgitgadget\n\n"},{"id":"386354","messageId":"xmqqeey85yt6.fsf@gitster-ct.c.googlers.com","threadId":"52263","inReplyTo":"0bca930ff82623bbef172b4cb6c36ef8e5c46098.1573828978.git.gitgitgadget@gmail.com","subject":"Re: [PATCH v2 1/3] Cast byte strings to unicode strings in python3","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-11-16T02:40:05Z","receivedAt":"2019-11-16T02:40:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Ben Keene via GitGitGadget\" writes:\n\n> From: Ben Keene \n> Subject: Re: [PATCH v2 1/3] Cast byte strings to unicode strings in python3\n\nThat is \"how\" this patch tries to achieve something that is not\nexplained in this proposed log message. Worse, the rest of the\nproposed log message is entirely empty and does not help readers\nunderstand what the author wanted to do, or decide if applying these\npatches is a good idea.\n\nYou wrote something about Python 3 having issues while comparing the\nstrings read out of process.popen() against string literals in the\ncode elsewhere in the cover letter. That information is probably\nvery relevant to explain why this commit exists, i.e. it should be\nexplained here.\n\nHere is what I _think_ is close to why you wrote this patch, but as\nI already said, I am far from being familiar with Py2to3\ndifferences, so there may be factual misunderstanding you would want\nto fix, even if you decide to pick some pieces out of it when\nsending an updated patch.\n\n Subject: [PATCH] git-p4: compare \"p4\" output with the right string type\n\n Communicating with a subprocess yields a byte string in both\n Python 2 and Python 3. Comparing the output or the error string\n with string literals makes the code fail, as string literals in\n Python 3 are unicode strings and not byte strings.\n\n Introduce a ustring() helper, which returns the corresponding\n unicode string for a given byte string (or return the argument\n as-is, when a unicode string is given) in Python 3, but returns\n the given bytestring as-is in Python 2. Use it to turn strings\n obtained from subprocess to the type suitable to compare with\n the string literals in both versions of Python.\n\nWhat does the name \"ustring()\" stand for?\n\nWhat purpose does the function serve at the higher conceptual level?\nName the function after the answer to that question and the code\nwould become easier to explain.\n\nIt certainly is not \"make sure we have unicode string\", as the name\nis shared between Python 2 and Python 3, and in the older Python 2\nworld, you want the helper to mean \"keep the string a bytestring\",\nnot turning it into a unicode string. So I doubt ustring() is a\ngreat name for this helper.\n\n> if skip_info:\n> if 'code' in entry and entry['code'] == 'info':\n> continue\n> + if b'code' in entry and entry[b'code'] == b'info':\n> + continue\n\nThis one explicitly calls for 'bytes', which I think would work\ncorrectly with Python 2. But why would we have to prepare for both\nvariants existing in the entry[] hash (especially when working with\nPython3)? Shouldn't the code that populates entry[] be responsible\nfor turning a byte string into a unicode string?\n\nAlso, is subprocess.communicate the only way bytestrings can come to\n\"git-p4\" program, or are there other avenues? What I am wondering\nis if it is sensible to declare that when running under Python 3,\nthe program will internally use unicode strings for everything and\nconvert any bytestring to unicode string as soon as it enters [*1*]\n\nThat would mean ...\n\n> if cb is not None:\n> cb(entry)\n> else:\n> - result.append(entry)\n> + if isunicode:\n> + out = {}\n> + for key, value in entry.items():\n> + out[ustring(key)] = ustring(value)\n> + result.append(out)\n> + else:\n> + result.append(entry)\n\n... a hunk like this would become entirely unnecessary, as keys and\nvalues of entry[] that are read from outside world would have\nalready been made into unicode strings under Python 3.\n\nBy the way, would values in entry[] always some string (iow, can\nthey have a literal number like 47 and 3.14)?\n\n> except EOFError:\n> pass\n> exitCode = p4.wait()\n> @@ -792,7 +813,7 @@ def gitConfig(key, typeSpecifier=None):\n> cmd += [ key ]\n> s = read_pipe(cmd, ignore_error=True)\n> _gitConfig[key] = s.strip()\n> - return _gitConfig[key]\n> + return ustring(_gitConfig[key])\n\nLikewise. I'd expect, if we were to declare that our internal\nstrings are all unicode in Python 3, we'd be using a thin wrapper of\nread_pipe() that yields a unicode string, so 's' would not be a\nbytestring, and s.strip() would not be either.\n\n> def gitConfigBool(key):\n> \"\"\"Return a bool, using git config --bool. It is True only if the\n> @@ -860,6 +881,7 @@ def branch_exists(branch):\n> cmd = [ \"git\", \"rev-parse\", \"--symbolic\", \"--verify\", branch ]\n> p = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE)\n> out, _ = p.communicate()\n> + out = ustring(out)\n\nBut perhaps it is a bit too much and it is easier to call the\nconversion helper on the results obtained by read_pipe() that gives\nus bytestring, like this one (and one above that) does? I dunno.\n\nThanks.\n\n\n[Footnote]\n\n*1* If it is not just string comparison but the general direction\n were to consistently use unicode strings under Python 3, which\n I think makes sense at the conceptual level, the sample log\n message I prepared in the earlier part of this response needs to\n be updated, so that it is not so message/comparison centric.\n\n I said \"at the conceptual level\", because there may be practical\n reasons not to use unicode everywhere (e.g. performance might\n degrade and some bytestrings used may not be text data in the\n first place).\n\n"},{"id":"386355","messageId":"xmqqd0ds5ysq.fsf@gitster-ct.c.googlers.com","threadId":"52263","inReplyTo":"pull.465.v2.git.1573828978.gitgitgadget@gmail.com","subject":"Re: [PATCH v2 0/3] Feature: New Variable git-p4.p4program","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-11-16T02:40:21Z","receivedAt":"2019-11-16T02:40:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Ben Keene via GitGitGadget\" writes:\n\n> Ben Keene (3):\n> Cast byte strings to unicode strings in python3\n> Added general variable git-p4.binary and added a default for windows\n> of 'P4.EXE'\n> Changed the name of the parameter from git-p4.binary to\n> git-p4.p4program\n\nThat's rather poor organization. In the larger picture, nobody\nwants to even know jthat you used to call git-p4.p4program with a\ndifferent name or what that different name was. They do not even\nneed to know why the new name is an improvement (but you do not even\ndiscuss to justify the name change in the proposed log message of\n3/3, which is even worse X-<).\n\nWhen presenting your work to the public, Git lets you pretend to be\na perfect human who never made mistake while preparing it and built\nthe series as a logical progression with perfect foresight. That is\nhow \"git rebase -i\" is useful. Learn to take advantage of that ;-)\n\nAs to individual patches, our local (read: project specific)\nconvention around here is to state the are the patch touches (in the\ncase of these patches, \"git-p4\" is the appropriate area name), colon,\nand then a one-line summary of what the step is about (the last one\nis done without initial capitalization). The summary is written with\nthe focus more on why and what than how.\n\nThanks.\n\n\n\n"},{"id":"386356","messageId":"xmqq8sog5ycj.fsf@gitster-ct.c.googlers.com","threadId":"52263","inReplyTo":"98bae92fda9ca01d01b2e9fb70b04b00470e7bec.1573828978.git.gitgitgadget@gmail.com","subject":"Re: [PATCH v2 2/3] Added general variable git-p4.binary and added a default for windows of 'P4.EXE'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-11-16T02:50:04Z","receivedAt":"2019-11-16T02:50:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Ben Keene via GitGitGadget\" writes:\n\n> From: Ben Keene \n> Subject: Re: [PATCH v2 2/3] Added general variable git-p4.binary and added a default for windows of 'P4.EXE'\n\nAgain, this is \"what\" you did, without explaining \"why\". You give\nreaders no hint to help them judge if/why it is a good idea to apply\nthis patch.\n\nPerhaps\n\n\tSubject: [PATCH] git-p4: allow path to the \"p4\" program configurable\n\n\tIntroduce \"git-p4.p4program\" configuration variable that can\n\tbe used to explicitly tell the path to the perforce client\n\tprogram. When unspecified, this defaults to \"p4\" except for\n\tWindows where \"p4.exe\" is used instead.\n\nor something? This is still weaker than ideal as an explanation of\n\"why\", but better than not saying anything as your original did ;-)\n\nThe reason why I find it weaker than ideal is because I would expect\nany P4 user to have their system set up so that they can say \"p4\"\nand get \"p4\" without configuring anything specifically (iow, \"%PATH%\"\nwould have been set up to have something with the p4.exe you want),\nand this change is to help those users, to whom that expectation\ndoes not hold (and in that case, it is better to explain in the\nproposed log message why their system would not let them run Perforce\nwithout first configuring this variable).\n\nAgain, as I said, you do not want to introduce \"git-p4.binary\" in\n2/3 and then turn around to \"oops, that was a mistake and it was not\na good name, so let's rename it\" in 3/3. Pretend as if you are a\nperfect developer with 100% foresight and have chosen the right name\nfrom the get-go by using \"git-p4.p4program\" in this step and drop\npatch 3/3.\n\nThanks.\n\n> Signed-off-by: Ben Keene \n> ---\n> Documentation/git-p4.txt | 5 +++++\n> git-p4.py | 14 +++++++++++++-\n> 2 files changed, 18 insertions(+), 1 deletion(-)\n>\n> diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt\n> index 3494a1db3e..e206e69250 100644\n> --- a/Documentation/git-p4.txt\n> +++ b/Documentation/git-p4.txt\n> @@ -547,6 +547,11 @@ git-p4.retries::\n> \tSet the value to 0 to disable retries or if your p4 version\n> \tdoes not support retries (pre 2012.2).\n> \n> +git-p4.binary::\n> +\tSpecifies the p4 executable used by git-p4 to process commands.\n> +\tThe default value for Windows is `p4.exe` and for all other\n> +\tsystems the default is `p4`. \n> +\n> Clone and sync variables\n> ~~~~~~~~~~~~~~~~~~~~~~~~\n> git-p4.syncFromOrigin::\n> diff --git a/git-p4.py b/git-p4.py\n> index 6e8b3a26cd..160d966ee1 100755\n> --- a/git-p4.py\n> +++ b/git-p4.py\n> @@ -26,6 +26,8 @@\n> import zlib\n> import ctypes\n> import errno\n> +import os.path\n> +from os import path\n> \n> # support basestring in python3\n> try:\n> @@ -85,7 +87,17 @@ def p4_build_cmd(cmd):\n> location. It means that hooking into the environment, or other configuration\n> can be done more easily.\n> \"\"\"\n> - real_cmd = [\"p4\"]\n> + # Look for the P4 binary\n> + p4bin = gitConfig(\"git-p4.binary\")\n> + real_cmd = []\n> + if p4bin != \"\":\n> + if path.exists(p4bin):\n> + real_cmd = [p4bin]\n> + if real_cmd == []:\n> + if (platform.system() == \"Windows\"):\n> + real_cmd = [\"p4.exe\"] \n> + else:\n> + real_cmd = [\"p4\"]\n> \n> user = gitConfig(\"git-p4.user\")\n> if len(user) > 0:\n"},{"id":"386361","messageId":"xmqqimnk4gwb.fsf@gitster-ct.c.googlers.com","threadId":"52263","inReplyTo":"xmqqeey85yt6.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH v2 1/3] Cast byte strings to unicode strings in python3","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-11-16T03:52:20Z","receivedAt":"2019-11-16T03:52:29Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n>> cmd += [ key ]\n>> s = read_pipe(cmd, ignore_error=True)\n>> _gitConfig[key] = s.strip()\n>> - return _gitConfig[key]\n>> + return ustring(_gitConfig[key])\n>\n> Likewise. I'd expect, if we were to declare that our internal\n> strings are all unicode in Python 3, we'd be using a thin wrapper of\n> read_pipe() that yields a unicode string, so 's' would not be a\n> bytestring, and s.strip() would not be either.\n\nOops, I did not even realize read_pipe() is already our own. So\nthere is no need to any wrapper around it, if we were to declare\nthat all strings we use are unicode under Python 3---we just need\nto have the ustring() call (after giviing the helper a better name)\ndirectly inside read_pipe() function.\n"},{"id":"386426","messageId":"xmqqeey63ryq.fsf@gitster-ct.c.googlers.com","threadId":"52263","inReplyTo":"xmqqd0ds5ysq.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH v2 0/3] Feature: New Variable git-p4.p4program","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-11-18T01:15:25Z","receivedAt":"2019-11-18T01:15:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> As to individual patches, our local (read: project specific)\n> convention around here is to state the are the patch touches (in the\n> case of these patches, \"git-p4\" is the appropriate area name), colon,\n> and then a one-line summary of what the step is about (the last one\n> is done without initial capitalization). The summary is written with\n> the focus more on why and what than how.\n\n\nSorry for a late typofix. \"to state the AREA the patch touches\" was\nwhat I meant. So I would expect all patches to this file (which is\nthe only component of 'git-p4' subsystem) to begin with \"git-p4: \"\nprefix.\n\nThanks.\n"},{"id":"387456","messageId":"8b1329db-edd7-496f-1328-7cd249b19451@gmail.com","threadId":"52263","inReplyTo":"xmqqeey63ryq.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH v2 0/3] Feature: New Variable git-p4.p4program","fromName":"Ben Keene","fromEmail":"seraphire@gmail.com","sentAt":"2019-12-03T15:59:54Z","receivedAt":"2019-12-03T15:59:58Z","isPatch":true,"sender":{"key":"seraphire@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22523774?v=4"},"body":"\nOn 11/17/2019 8:15 PM, Junio C Hamano wrote:\n> Junio C Hamano writes:\n>\n>> As to individual patches, our local (read: project specific)\n>> convention around here is to state the are the patch touches (in the\n>> case of these patches, \"git-p4\" is the appropriate area name), colon,\n>> and then a one-line summary of what the step is about (the last one\n>> is done without initial capitalization). The summary is written with\n>> the focus more on why and what than how.\n>\n> Sorry for a late typofix. \"to state the AREA the patch touches\" was\n> what I meant. So I would expect all patches to this file (which is\n> the only component of 'git-p4' subsystem) to begin with \"git-p4: \"\n> prefix.\n>\n> Thanks.\nI was having email trouble trying to reply to your suggestions. \n(Downloaded yet another mail client, and this seems to work)  I'll make \nthose changes.\n"}]}