{"thread":{"id":"44664","subject":"[BUG] Colon in remote urls","startedAt":"2016-12-09T14:38:10Z","lastAt":"2016-12-22T22:19:19Z","messageCount":46,"participants":["Klaus Ethgen","Jeff King","Junio C Hamano","Johannes Sixt","Johannes Schindelin","Philip Oakley","Duy Nguyen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"307358","messageId":"20161209140215.qlam6bexm5irpro2@ikki.ethgen.ch","threadId":"44664","inReplyTo":null,"subject":"[BUG] Colon in remote urls","fromName":"Klaus Ethgen","fromEmail":"klaus@ethgen.ch","sentAt":"2016-12-09T14:02:15Z","receivedAt":"2016-12-09T14:38:10Z","isPatch":false,"sender":{"key":"klaus@ethgen.ch","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA512\n\nHello,\n\nI have some repositories where I have a colon in the (local) url for a\nremote. That was no problem until now but with 2.11.0, I see the\nfollowing problem:\n ~> git push\n Counting objects: 11, done.\n Delta compression using up to 8 threads.\n Compressing objects: 100% (10/10), done.\n Writing objects: 100% (11/11), 1.26 KiB | 0 bytes/s, done.\n Total 11 (delta 7), reused 0 (delta 0)\n remote: error: object directory /home/xxx does not exist; check .git/objects/info/alternates.\n remote: error: object directory yyy.git/objects does not exist; check .git/objects/info/alternates.\n remote: fatal: unresolved deltas left after unpacking\n error: unpack failed: unpack-objects abnormal exit\n To /home/xxx:yyy.git\n ! [remote rejected] master -> master (unpacker error)\n error: failed to push some refs to '/home/xxx:yyy.git'\n\nPrepending the path with \"file://\" does not help.\n\nIt seems that the new git version splits the url at \":\" which ends in\ntwo incorrect paths.\n\nPull seems tho work well currently.\n\nRegards\n Klaus\n\nPs. I am not subscribet to the mailing list, so please keep me in Cc.\n- -- \nKlaus Ethgen http://www.ethgen.ch/\npub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen \nFingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C\n-----BEGIN PGP SIGNATURE-----\nComment: Charset: ISO-8859-1\n\niQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAlhKuV4ACgkQpnwKsYAZ\n9qz81Qv6AsgZHlaEHEybERAvGikjZgUvjyC7dzQ2zCmc8iv0eb8kGLiBtVtInsWr\neo/CiMSdX2emoCD5LQq/sxcRIgIoWpF8m2NEXiBMl94d6YLOpvWV1yC1kQ8qK6bt\nPyeo9/LofAnpLcQRn1am8tFwrcCMLZxSM7cxMxjtP6i+RU0MHc/rS1HqhdzptpsH\njvB0x41X7LNoeRLqG5n8lVlyHP1PiGyP0Dl4Aa9rFBHn+hydiJEmLEwdn9w4wgIz\nvo2DZmqGm0r4vTaTP1gQRPxoW6fsBZ1uUWKRMjd947R1eaELpyROj4SFt0bWNqwW\ncx9izYUuTg+xSe1KTaSgPlmZn1817DlG2yJ/YduKH8v61ZJ2r6B1awO2tz32g7cA\nQdjsnzAyz6eVLrrsJ5OrJPRF2Fl7gM22jo9gs3BJrHeJdC9dU6kVIAR3eryoFvUg\nfG/Vl2zvfbMRQAaUDGMyxNk5TGVFB6ANw0KS/NczRvmbPA9kukBz012+8ZY8MHzD\naEvmk/yz\n=tDwn\n-----END PGP SIGNATURE-----\n"},{"id":"307359","messageId":"20161209152219.ehfk475vdg4levop@sigill.intra.peff.net","threadId":"44664","inReplyTo":"20161209140215.qlam6bexm5irpro2@ikki.ethgen.ch","subject":"Re: [BUG] Colon in remote urls","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-09T15:22:19Z","receivedAt":"2016-12-09T15:22:27Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Dec 09, 2016 at 03:02:15PM +0100, Klaus Ethgen wrote:\n\n> I have some repositories where I have a colon in the (local) url for a\n> remote. That was no problem until now but with 2.11.0, I see the\n> following problem:\n> ~> git push\n> Counting objects: 11, done.\n> Delta compression using up to 8 threads.\n> Compressing objects: 100% (10/10), done.\n> Writing objects: 100% (11/11), 1.26 KiB | 0 bytes/s, done.\n> Total 11 (delta 7), reused 0 (delta 0)\n> remote: error: object directory /home/xxx does not exist; check .git/objects/info/alternates.\n> remote: error: object directory yyy.git/objects does not exist; check .git/objects/info/alternates.\n> remote: fatal: unresolved deltas left after unpacking\n\nHrm. The problem v2.11's new object-quarantine system. The receiving\nside of a push will write into a new temporary object directory, and\nrefer to the original with the GIT_ALTERNATE_OBJECT_DIRECTORIES\nenvironment variable. But that variable splits its entries on \":\", and\nhas no way of representing a path that includes a \":\".\n\nSo I think the solution would probably be to introduce some kind of\nquoting mechanism to that variable, so that it can pass through\narbitrary paths. Or alternatively use a separate variable, but that does\nnothing to help other cases where somebody wants to use xxx:yyy.git as\nan alternate.\n\n(One other option is to just declare that the quarantine feature doesn't\nwork with colons in the pathname, but stop turning it on by default. I'm\nnot sure I like that, though).\n\nHere's a rough idea of what the quoting solution could look like. It\nshould make your case work, but I'm not sure what we want to do about\nbackwards-compatibility, if anything.\n\n---\n sha1_file.c | 41 ++++++++++++++++++++++++++++++-----------\n tmp-objdir.c | 18 ++++++++++++++++--\n 2 files changed, 46 insertions(+), 13 deletions(-)\n\ndiff --git a/sha1_file.c b/sha1_file.c\nindex 9c86d1924..a0b341b5a 100644\n--- a/sha1_file.c\n+++ b/sha1_file.c\n@@ -329,13 +329,35 @@ static int link_alt_odb_entry(const char *entry, const char *relative_base,\n \treturn 0;\n }\n \n+const char *parse_alt_odb_entry(const char *string, int sep,\n+\t\t\t\tstruct strbuf *out)\n+{\n+\tconst char *p;\n+\tint literal = 0;\n+\n+\tstrbuf_reset(out);\n+\n+\tfor (p = string; *p; p++) {\n+\t\tif (literal) {\n+\t\t\tstrbuf_addch(out, *p);\n+\t\t\tliteral = 0;\n+\t\t} else {\n+\t\t\tif (*p == '\\\\')\n+\t\t\t\tliteral = 1;\n+\t\t\telse if (*p == sep)\n+\t\t\t\treturn p + 1;\n+\t\t\telse\n+\t\t\t\tstrbuf_addch(out, *p);\n+\t\t}\n+\t}\n+\treturn p;\n+}\n+\n static void link_alt_odb_entries(const char *alt, int len, int sep,\n \t\t\t\t const char *relative_base, int depth)\n {\n-\tstruct string_list entries = STRING_LIST_INIT_NODUP;\n-\tchar *alt_copy;\n-\tint i;\n \tstruct strbuf objdirbuf = STRBUF_INIT;\n+\tstruct strbuf entry = STRBUF_INIT;\n \n \tif (depth > 5) {\n \t\terror(\"%s: ignoring alternate object stores, nesting too deep.\",\n@@ -348,16 +370,13 @@ static void link_alt_odb_entries(const char *alt, int len, int sep,\n \t\tdie(\"unable to normalize object directory: %s\",\n \t\t objdirbuf.buf);\n \n-\talt_copy = xmemdupz(alt, len);\n-\tstring_list_split_in_place(&entries, alt_copy, sep, -1);\n-\tfor (i = 0; i < entries.nr; i++) {\n-\t\tconst char *entry = entries.items[i].string;\n-\t\tif (entry[0] == '\\0' || entry[0] == '#')\n+\twhile (*alt) {\n+\t\talt = parse_alt_odb_entry(alt, sep, &entry);\n+\t\tif (!entry.len || entry.buf[0] == '#')\n \t\t\tcontinue;\n-\t\tlink_alt_odb_entry(entry, relative_base, depth, objdirbuf.buf);\n+\t\tlink_alt_odb_entry(entry.buf, relative_base, depth, objdirbuf.buf);\n \t}\n-\tstring_list_clear(&entries, 0);\n-\tfree(alt_copy);\n+\tstrbuf_release(&entry);\n \tstrbuf_release(&objdirbuf);\n }\n \ndiff --git a/tmp-objdir.c b/tmp-objdir.c\nindex 64435f23a..900e15af1 100644\n--- a/tmp-objdir.c\n+++ b/tmp-objdir.c\n@@ -70,6 +70,17 @@ static void remove_tmp_objdir_on_signal(int signo)\n \traise(signo);\n }\n \n+static char *backslash_quote(const char *s, int delim)\n+{\n+\tstruct strbuf buf = STRBUF_INIT;\n+\twhile (*s) {\n+\t\tif (*s == '\\\\' || *s == delim)\n+\t\t\tstrbuf_addch(&buf, '\\\\');\n+\t\tstrbuf_addch(&buf, *s++);\n+\t}\n+\treturn strbuf_detach(&buf, NULL);\n+}\n+\n /*\n * These env_* functions are for setting up the child environment; the\n * \"replace\" variant overrides the value of any existing variable with that\n@@ -79,12 +90,15 @@ static void remove_tmp_objdir_on_signal(int signo)\n */\n static void env_append(struct argv_array *env, const char *key, const char *val)\n {\n+\tchar *quoted = backslash_quote(val, PATH_SEP);\n \tconst char *old = getenv(key);\n \n \tif (!old)\n-\t\targv_array_pushf(env, \"%s=%s\", key, val);\n+\t\targv_array_pushf(env, \"%s=%s\", key, quoted);\n \telse\n-\t\targv_array_pushf(env, \"%s=%s%c%s\", key, old, PATH_SEP, val);\n+\t\targv_array_pushf(env, \"%s=%s%c%s\", key, old, PATH_SEP, quoted);\n+\n+\tfree(quoted);\n }\n \n static void env_replace(struct argv_array *env, const char *key, const char *val)\n-- \n2.11.0.201.g51bd297\n\n"},{"id":"307384","messageId":"xmqqwpf8rkeq.fsf@gitster.mtv.corp.google.com","threadId":"44664","inReplyTo":"20161209152219.ehfk475vdg4levop@sigill.intra.peff.net","subject":"Re: [BUG] Colon in remote urls","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-12-09T19:07:25Z","receivedAt":"2016-12-09T19:07:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> (One other option is to just declare that the quarantine feature doesn't\n> work with colons in the pathname, but stop turning it on by default. I'm\n> not sure I like that, though).\n\nI think we long time ago in 2005 have declared that a colon in a\ndirectory name would not work for Git repositories because of things\nlike GIT_CEILING_DIRECTORIES, GIT_ALTERNATE_OBJECT_DIRECTORIES; so I\ndo not think we terribly mind that direction.\n\n> Here's a rough idea of what the quoting solution could look like. It\n> should make your case work, but I'm not sure what we want to do about\n> backwards-compatibility, if anything.\n\nYes, obviously it robs from those with backslash in their pathnames\nto please those with colons; we've never catered to the latter, so I\nam not sure if the trade-off is worth it.\n\nI can see how adding a new environment variable could work, though.\nA naive way would be to add GIT_ALT_OBJ_DIRS that uses your quoting\nwhen splitting its elements, give it precedence over the existing\none (or allow to use both and take union as the set of alternate\nobject stores) and make sure that the codepaths we use internally\nuses the new variable. But if the quarantine codepath will stay to\nbe the only user of this mechanism (and I strongly suspect that will\nbe the case), the new environment could just be pointing at a single\ndirectory, i.e. GIT_OBJECT_QUARANTINE_DIRECTORY, whose value is\nadded without splitting to the list of alternate object stores, and\nthe quarantine codepath can export that instead.\n"},{"id":"307396","messageId":"88bed7c9-4d5d-45d5-5d13-6a8ae834e602@kdbg.org","threadId":"44664","inReplyTo":"20161209152219.ehfk475vdg4levop@sigill.intra.peff.net","subject":"Re: [BUG] Colon in remote urls","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2016-12-09T21:32:48Z","receivedAt":"2016-12-09T21:32:56Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 09.12.2016 um 16:22 schrieb Jeff King:\n> +const char *parse_alt_odb_entry(const char *string, int sep,\n> +\t\t\t\tstruct strbuf *out)\n> +{\n> +\tconst char *p;\n> +\tint literal = 0;\n> +\n> +\tstrbuf_reset(out);\n> +\n> +\tfor (p = string; *p; p++) {\n> +\t\tif (literal) {\n> +\t\t\tstrbuf_addch(out, *p);\n> +\t\t\tliteral = 0;\n> +\t\t} else {\n> +\t\t\tif (*p == '\\\\')\n> +\t\t\t\tliteral = 1;\n\nThere are too many systems out there that use a backslash in path names. \nI don't think it is wise to use it also as the quoting character.\n\n> +\t\t\telse if (*p == sep)\n> +\t\t\t\treturn p + 1;\n> +\t\t\telse\n> +\t\t\t\tstrbuf_addch(out, *p);\n> +\t\t}\n> +\t}\n> +\treturn p;\n> +}\n\n-- Hannes\n\n"},{"id":"307417","messageId":"20161210082657.zjp52a2zdtqifmg3@sigill.intra.peff.net","threadId":"44664","inReplyTo":"88bed7c9-4d5d-45d5-5d13-6a8ae834e602@kdbg.org","subject":"Re: [BUG] Colon in remote urls","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-10T08:26:57Z","receivedAt":"2016-12-10T08:27:05Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Dec 09, 2016 at 10:32:48PM +0100, Johannes Sixt wrote:\n\n> > +\t\t\tif (*p == '\\\\')\n> > +\t\t\t\tliteral = 1;\n> \n> There are too many systems out there that use a backslash in path names. I\n> don't think it is wise to use it also as the quoting character.\n\nYeah, I picked it arbitrarily as the common quoting character, but I\nagree it probably makes backwards compatibility (and general usability\nwhen you have to double-backslash each instance) pretty gross on\nWindows.\n\nMost of the printable characters are going to suffer from backwards\ncompatibility issues. Syntactically, we could use any ASCII control code\nbelow 0x20. Certainly our C code would be fine with that, but it seems\npretty nasty.\n\nThere's probably some crazy non-printing UTF-8 sequence we could use,\ntoo, but I'm not sure I want to go there.\n\n-Peff\n"},{"id":"307420","messageId":"20161210085133.2pnkz6eqlxoxdckg@sigill.intra.peff.net","threadId":"44664","inReplyTo":"xmqqwpf8rkeq.fsf@gitster.mtv.corp.google.com","subject":"Re: [BUG] Colon in remote urls","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-10T08:51:34Z","receivedAt":"2016-12-10T08:52:03Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Dec 09, 2016 at 11:07:25AM -0800, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > (One other option is to just declare that the quarantine feature doesn't\n> > work with colons in the pathname, but stop turning it on by default. I'm\n> > not sure I like that, though).\n> \n> I think we long time ago in 2005 have declared that a colon in a\n> directory name would not work for Git repositories because of things\n> like GIT_CEILING_DIRECTORIES, GIT_ALTERNATE_OBJECT_DIRECTORIES; so I\n> do not think we terribly mind that direction.\n\nI don't mind declaring the feature incompatible. But I'm not sure\nwhether I like not having it on by default, if only because it means we\nhave two distinct code paths to care about. They're sufficiently\ndifferent that I'd worry about a bug creeping into one and not the\nother.\n\n> > Here's a rough idea of what the quoting solution could look like. It\n> > should make your case work, but I'm not sure what we want to do about\n> > backwards-compatibility, if anything.\n> \n> Yes, obviously it robs from those with backslash in their pathnames\n> to please those with colons; we've never catered to the latter, so I\n> am not sure if the trade-off is worth it.\n> \n> I can see how adding a new environment variable could work, though.\n> A naive way would be to add GIT_ALT_OBJ_DIRS that uses your quoting\n> when splitting its elements, give it precedence over the existing\n> one (or allow to use both and take union as the set of alternate\n> object stores) and make sure that the codepaths we use internally\n> uses the new variable.\n\nYeah, a new variable solves the backwards-compatibility issue, though if\nwe continue to use backslash as an escape, then people on Windows will\nannoying _have_ to backslash-escape \"C:\\\\\" (worse, AIUI the conversion\nfrom \"/unix/path\" to \"C:\\unix\\path\" happens transparently via msys\nmagic, and it would not know that we need to quote).\n\nI think the least-gross alternative would be to make newline the new\ndelimiter. It's already the delimiter (and not quotable) in the\nobjects/info/alternates file, and I have a lot less trouble telling\npeople with newline in their filenames that they're Doing It Wrong.\n\n> But if the quarantine codepath will stay to\n> be the only user of this mechanism (and I strongly suspect that will\n> be the case), the new environment could just be pointing at a single\n> directory, i.e. GIT_OBJECT_QUARANTINE_DIRECTORY, whose value is\n> added without splitting to the list of alternate object stores, and\n> the quarantine codepath can export that instead.\n\nYes, I also considered that approach. The big downside is that it does\nnot help other users of GIT_ALTERNATE_OBJECT_DIRECTORIES. I doubt that\nmatters much in practice, though.\n\nMy other question is whether we care about compatibility between Git\nversions here. If receive-pack sets the variable, we can assume that\nindex-pack will be run from the same version. But we also run hooks with\nthe quarantine variables set. The nice thing about the existing scheme\nis that older versions of Git (or alternate implementations of Git) will\njust work, because it builds on a mechanism that has existed for ages.\n\nAnd that's the one thing that a quoting scheme has going for it: it only\nimpacts the variable when there is something to be quoted. So if your\nrepo path has a colon in it (or semi-colon on Windows) _and_ you are\ncalling something like jgit from your hook, then you might see a\nfailure. But either of those by itself is not a problem.\n\nSide note: It makes me wonder if all implementations even support\nGIT_ALTERNATE_OBJECT_DIRECTORIES. JGit seems to, looks like libgit2 does\nnot. The most backwards-compatible thing is not enabling quarantine by\ndefault, and then there's no chance of regression, and you are\nresponsible for making sure you have a compatible setup before turning\nthe feature on. But like I said, I'd love to avoid that if we can.\n\nSo here's the array of options, as I see it:\n\n 1. Disable quarantine by default; only turn it on if you don't have\n any of the funny corner cases.\n\n 2. Introduce an extra single-item environment variable that gets\n appended to the list of alternates, and side-steps quoting issues.\n\n 3. Introduce a new variable that can hold an alternate list, and\n either teach it reasonable quoting semantics, or give it a\n less-common separator.\n\n 4. Introduce quoting to the existing variable, but make the quoting\n character sufficiently obscure that nobody cares about the lack of\n backwards compatibility.\n\nI actually think (4) is reasonably elegant, except that the resulting\nquoting scheme would be vaguely insane to look at. E.g., if we pick\nnewline as the quote character (not the separator), then you end up\nwith:\n\n $ repo=foo:bar.git\n $ GIT_ALTERNATE_OBJECT_DIRECTORIES=$(echo $repo | perl -pe 's/:/\\n$&/')\n $ echo \"$GIT_ALTERNATE_OBJECT_DIRECTORIES\"\n foo\n :bar.git\n\nIt's pleasant for machines, but not for humans.\n\nSo I dunno. Opinions on those 4 options are welcome.\n\n-Peff\n"},{"id":"307425","messageId":"20161210092928.jkaf2rwxhicafmxr@ikki.ethgen.ch","threadId":"44664","inReplyTo":"xmqqwpf8rkeq.fsf@gitster.mtv.corp.google.com","subject":"Re: [BUG] Colon in remote urls","fromName":"Klaus Ethgen","fromEmail":"klaus@ethgen.ch","sentAt":"2016-12-10T09:29:28Z","receivedAt":"2016-12-10T09:29:40Z","isPatch":false,"sender":{"key":"klaus@ethgen.ch","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA512\n\nHello,\n\nAm Fr den 9. Dez 2016 um 20:07 schrieb Junio C Hamano:\n> Jeff King writes:\n> > (One other option is to just declare that the quarantine feature doesn't\n> > work with colons in the pathname, but stop turning it on by default. I'm\n> > not sure I like that, though).\n> \n> I think we long time ago in 2005 have declared that a colon in a\n> directory name would not work for Git repositories because of things\n> like GIT_CEILING_DIRECTORIES, GIT_ALTERNATE_OBJECT_DIRECTORIES; so I\n> do not think we terribly mind that direction.\n\nThat is the first I hear and I really wonder about.\n\nA colon a perfectly allowed character in POSIX filesystems.\n\nMoreover, it was no problem before and was introduced as a problem just\nin that version. Even more, a pull (and so a clone I believe) of such a\npath is absolutely ok. Just the push fails.\n\n> > Here's a rough idea of what the quoting solution could look like. It\n> > should make your case work, but I'm not sure what we want to do about\n> > backwards-compatibility, if anything.\n> \n> Yes, obviously it robs from those with backslash in their pathnames\n> to please those with colons; we've never catered to the latter, so I\n> am not sure if the trade-off is worth it.\n\nAs I quote above, a colon is perfect common in POSIX filesystems. A\nbackslash is at least uncommon and always needed to quote as it, most\noften, has special meaning to os/shell.\n\nI cannot see why a tool (as git is) should decide what characters are\n\"bad\" and what are \"good\". If the filesystem beneath supports it...\n\nBy the way, I didn't find anywhere in git documentation that there are\n\"bad\" chars around.\n\n> I can see how adding a new environment variable could work, though.\n> A naive way would be to add GIT_ALT_OBJ_DIRS that uses your quoting\n> when splitting its elements, give it precedence over the existing\n> one (or allow to use both and take union as the set of alternate\n> object stores) and make sure that the codepaths we use internally\n> uses the new variable. But if the quarantine codepath will stay to\n> be the only user of this mechanism (and I strongly suspect that will\n> be the case), the new environment could just be pointing at a single\n> directory, i.e. GIT_OBJECT_QUARANTINE_DIRECTORY, whose value is\n> added without splitting to the list of alternate object stores, and\n> the quarantine codepath can export that instead.\n\nI didn't get it, why is there a need to split? I mean, it is not\npossible to push to two locations at the same time, so why is there\nsplitting at all?\n\nRegards\n Klaus\n- -- \nKlaus Ethgen http://www.ethgen.ch/\npub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen \nFingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C\n-----BEGIN PGP SIGNATURE-----\nComment: Charset: ISO-8859-1\n\niQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAlhLyvIACgkQpnwKsYAZ\n9qyBzgv9EzMEWrEgsTd1Z0gjpzpJlhpO8R2I7H4mGvEjlxoTXtUNwjvM+ojAYzaI\nF34IBRv9BCha+h7I6ccoaAsfmurz73lA1AKy1IFPrYAoxompYLomC9exY+8+ggdN\nG2uVbMTmiL+CxJGo0ItxmiQCcv7himVoyto70Dekc7se+panbzCq/vG4+Rz7pwRn\nsWnlKs0tQomi6QXbibo8992v4ECkAXzE2Xc/l5DvosSwNNPsqgdeeiNHEMDTbQq8\njqencfOruCfyMnQ0ejCaTWNbYY5SVUtfWikwta12jB06D1BgHTCRVKZCfhoHJx5+\nFfqj8uuiCJuZGQcopzJWiYU5X+SUHz7Ya+iA3VQOxNEKsGAZgq6QQqDcd0y9fyPt\npzMAYo26GRioDiuQZzZ4CzA5eC0wWozv3oESsKLD5RsbWHV/9ODbpr7lHMW2TmUp\nH2vZhre1K/ZX2bODQByJoRNtDUqKvZmI6GsbXrvRAFKF4aCLByFIgcrZprmj++DH\njlb25tjq\n=jOGb\n-----END PGP SIGNATURE-----\n"},{"id":"307426","messageId":"20161210093230.26q7fxcrs2cpll6g@ikki.ethgen.ch","threadId":"44664","inReplyTo":"88bed7c9-4d5d-45d5-5d13-6a8ae834e602@kdbg.org","subject":"Re: [BUG] Colon in remote urls","fromName":"Klaus Ethgen","fromEmail":"klaus@ethgen.ch","sentAt":"2016-12-10T09:32:31Z","receivedAt":"2016-12-10T09:32:42Z","isPatch":false,"sender":{"key":"klaus@ethgen.ch","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA512\n\nAm Fr den 9. Dez 2016 um 22:32 schrieb Johannes Sixt:\n> There are too many systems out there that use a backslash in path names. I\n> don't think it is wise to use it also as the quoting character.\n\nWell, the minority, I believe. And only the minority where the command\nline git is used anywhere.\n\nBut for the majority of OS, where the command line git is in use\n(instead of graphically third party git tools) is perfect known for\nbackslash as escaping character. However, don't forget that a backslash\ncould also be part of the file name.\n\nRegads\n Klaus\n- -- \nKlaus Ethgen http://www.ethgen.ch/\npub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen \nFingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C\n-----BEGIN PGP SIGNATURE-----\nComment: Charset: ISO-8859-1\n\niQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAlhLy64ACgkQpnwKsYAZ\n9qzYfQwAmVIR+bVOvOcZ+yu7HddC5mwo7st6w+vPcdLKpFWcHIhsG//cHq6he+mm\n/Dmfhnc4Yp+dSy7Z99p9DV67hAj0Zxj2koxBo4eCdwWhnKrphCHSST8j2IxIg/0h\nY1axQEBc5hV9nImTYmOks0pa5c9wKkZS36aTjP63PKgIv46A8RDY/QXAm2uO4kjj\ngfBEiDVkQA99QlvpP1qbuRCK3QUmfqxrP9ldiAhmuDBbNv2smiBxhoN3E6NgKTJG\nfM6WjaZPUqpDUiky5gO0xfOpf6s2c/GMTEO1I5aWom6VKtrOoYUyMlyeMiqALWj7\nKfN7TJfDqp3THo0AkLXuukrNMv9gdfgiAimGqYgSfFM9P60aPjGeC7nBt875PSae\njdVjIGyl0tHZzSIbBoSecQqx8h65eZaHLaS1uNf704m+EwIs1X2daI7Re3DcAyzL\nEWJxtZyZbG/GooCdA9deywlEAtGNOdIg+p+YkThsmEGiaOir/fAMyviSP/jONTCq\nOC5oHOcK\n=x9y4\n-----END PGP SIGNATURE-----\n"},{"id":"307427","messageId":"20161210094133.7htkb6cmjuhkdh4v@ikki.ethgen.ch","threadId":"44664","inReplyTo":"20161210082657.zjp52a2zdtqifmg3@sigill.intra.peff.net","subject":"Re: [BUG] Colon in remote urls","fromName":"Klaus Ethgen","fromEmail":"klaus@ethgen.ch","sentAt":"2016-12-10T09:41:33Z","receivedAt":"2016-12-10T09:41:44Z","isPatch":false,"sender":{"key":"klaus@ethgen.ch","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA512\n\nAm Sa den 10. Dez 2016 um 9:26 schrieb Jeff King:\n> Yeah, I picked it arbitrarily as the common quoting character, but I\n> agree it probably makes backwards compatibility (and general usability\n> when you have to double-backslash each instance) pretty gross on\n> Windows.\n\nWell, I don't know of many people using the original git on windows.\nMost of them using some graphical third-party tools.\n\nThe main git suite is most often used on linux where a colon is a valid\ncharacter For example using /mnt/c: as mount path for windows file\nsystems or /bla/foo/dated_repository_2016-12-10_12:00.git for dated and\ntimed repositories.\n\nMy btrfs snapshot dir looks like:\n ~snapshot> l -gGhN\n [...]\n drwxr-x--x 1 296 2016-07-30T13:55 daily_2016-12-10_00:00:01.270213478\n drwxr-x--x 1 296 2016-07-30T13:55 hourly_2016-12-10_05:00:01.372037552\n [...]\n\nCompared to the backslash, although it is a perfect legal character in\nPOSIX file systems, I do not know any use of it.\n\nRegards\n Klaus\n- -- \nKlaus Ethgen http://www.ethgen.ch/\npub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen \nFingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C\n-----BEGIN PGP SIGNATURE-----\nComment: Charset: ISO-8859-1\n\niQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAlhLzc0ACgkQpnwKsYAZ\n9qy1jQv/Wcafo8nJuy/dNIpxN5tNaLEENrY6a2dkv379F2miEJYROlWO6UzG86hY\n0WIZAm5BKK6SpPVztTMcs2GHPF0iCB4V4RyQFdFa73OhaAgHOJRdy50eaGSz6vt6\nlDZkJZsG0FoXcT6Fapdl5xZeoNDXjPcYH/7yFQ7VjMD5HTpLDIs8E5Mb8V1jwehV\nJKzQd136vksS2qB96jElAYonXFwImvYfTplH3nELJh/kKRJOT8Mzgj/+X7vxnQcC\nNISiLysSxqPm5d9yDsfN1eofMNGn2zgJZStOP6jNV2yqldMgN0fJX4Mt449GpBO8\nOSYjN828QsDYXCWdTCKxbLCxjfNxfvQgHHR7ugSlf9xPrro3MjQjg2cMhZ/fCzCm\nXcC4X+Iyec2F0wHSQiXqlb7wiOXa1Oup6zmTRe/G5HkhlCap/+R2nOCfkqEEwhkB\nmoYTqfETqqTJUJiiYVM/U8LBFWGnBBCGWgRPzyNdFna+WnvD93s9JPeg7q9qFm6x\n8flMJBm8\n=M5IW\n-----END PGP SIGNATURE-----\n"},{"id":"307429","messageId":"20161210102446.2sf3dxy7yj7sifcd@sigill.intra.peff.net","threadId":"44664","inReplyTo":"20161210092928.jkaf2rwxhicafmxr@ikki.ethgen.ch","subject":"Re: [BUG] Colon in remote urls","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-10T10:24:46Z","receivedAt":"2016-12-10T10:24:55Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Dec 10, 2016 at 10:29:28AM +0100, Klaus Ethgen wrote:\n\n> > I think we long time ago in 2005 have declared that a colon in a\n> > directory name would not work for Git repositories because of things\n> > like GIT_CEILING_DIRECTORIES, GIT_ALTERNATE_OBJECT_DIRECTORIES; so I\n> > do not think we terribly mind that direction.\n> \n> That is the first I hear and I really wonder about.\n> \n> A colon a perfectly allowed character in POSIX filesystems.\n\nSure, it's allowed, but it will cause problems due to other syntactic\nconventions. Try putting \"/usr/path:with:colons\" into your $PATH\nvariable, for instance. Try rsyncing \"xxx:yyy.git\" somewhere.\n\nGit does have heuristics for figuring out the difference between\n\"host:repo.git\" as an SSH remote versus a local path, but they're not\nfoolproof.\n\n> Moreover, it was no problem before and was introduced as a problem just\n> in that version. Even more, a pull (and so a clone I believe) of such a\n> path is absolutely ok. Just the push fails.\n\nSort of. This has always been a problem with the variables Junio\nmentioned. The change in v2.11 is that the alternates subsystem is being\nused in some cases where it wasn't before, which is surfacing this\nlimitation in more places.\n\n> > directory, i.e. GIT_OBJECT_QUARANTINE_DIRECTORY, whose value is\n> > added without splitting to the list of alternate object stores, and\n> > the quarantine codepath can export that instead.\n> \n> I didn't get it, why is there a need to split? I mean, it is not\n> possible to push to two locations at the same time, so why is there\n> splitting at all?\n\nBecause the new quarantine feature[1] is built on top of the existing\nalternates mechanism, which can have several sources.\n\nI do think we should address this as a regression, but I think repo\nnames with colons are always going to suffer from some corner cases.\n\n-Peff\n\n[1] See 25ab004c5 and the commits leading up to it for more discussion\n of what the new feature is, if you're curious.\n"},{"id":"307430","messageId":"20161210102657.ateotzowgek7bjuc@sigill.intra.peff.net","threadId":"44664","inReplyTo":"20161210094133.7htkb6cmjuhkdh4v@ikki.ethgen.ch","subject":"Re: [BUG] Colon in remote urls","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-10T10:26:57Z","receivedAt":"2016-12-10T10:27:05Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Dec 10, 2016 at 10:41:33AM +0100, Klaus Ethgen wrote:\n\n> Am Sa den 10. Dez 2016 um 9:26 schrieb Jeff King:\n> > Yeah, I picked it arbitrarily as the common quoting character, but I\n> > agree it probably makes backwards compatibility (and general usability\n> > when you have to double-backslash each instance) pretty gross on\n> > Windows.\n> \n> Well, I don't know of many people using the original git on windows.\n> Most of them using some graphical third-party tools.\n\nI laid out options for addressing the problem elsewhere, but I want to\nmake clear that this line of reasoning is not likely to get any traction\nhere. Git for Windows is a non-trivial part of the user base, and we do\ncare about avoiding regressions there.\n\n-Peff\n"},{"id":"307431","messageId":"20161210104615.koit4zyu6fioaehm@ikki.ethgen.ch","threadId":"44664","inReplyTo":"20161210102446.2sf3dxy7yj7sifcd@sigill.intra.peff.net","subject":"Re: [BUG] Colon in remote urls","fromName":"Klaus Ethgen","fromEmail":"klaus@ethgen.ch","sentAt":"2016-12-10T10:46:18Z","receivedAt":"2016-12-10T10:46:39Z","isPatch":false,"sender":{"key":"klaus@ethgen.ch","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA512\n\nHi,\n\nAm Sa den 10. Dez 2016 um 11:24 schrieb Jeff King:\n> > A colon a perfectly allowed character in POSIX filesystems.\n> \n> Sure, it's allowed, but it will cause problems due to other syntactic\n> conventions. Try putting \"/usr/path:with:colons\" into your $PATH\n> variable, for instance.\n\nTrue.\n\n> Try rsyncing \"xxx:yyy.git\" somewhere.\n\nOnly a problem when the part before the colon has no directory limiter\n(/) in it. And even then there is ways to work around that limitation.\n\nAnd in this case, it is pretty good documented. As I told, I never\nheared of such limitation in git commands.\n\n> Git does have heuristics for figuring out the difference between\n> \"host:repo.git\" as an SSH remote versus a local path, but they're not\n> foolproof.\n\nWell, that is the reason why I first tried to solve it via file://...\n\nNote, I have no problem with it, if that char has to be qouted somehow;\nif it is clearly documented. But also then, the handling should be\nconsistent. In git (in this version) it is not. Pull works without\nproblems but push dosn't.\n\n> > Moreover, it was no problem before and was introduced as a problem just\n> > in that version. Even more, a pull (and so a clone I believe) of such a\n> > path is absolutely ok. Just the push fails.\n> \n> Sort of. This has always been a problem with the variables Junio\n> mentioned. The change in v2.11 is that the alternates subsystem is being\n> used in some cases where it wasn't before, which is surfacing this\n> limitation in more places.\n\n- -v please. I didn't get it with that alternate stuff in push.\n\nA link to some man page is ok too.\n\n> > > directory, i.e. GIT_OBJECT_QUARANTINE_DIRECTORY, whose value is\n> > > added without splitting to the list of alternate object stores, and\n> > > the quarantine codepath can export that instead.\n> > \n> > I didn't get it, why is there a need to split? I mean, it is not\n> > possible to push to two locations at the same time, so why is there\n> > splitting at all?\n> \n> Because the new quarantine feature[1] is built on top of the existing\n> alternates mechanism, which can have several sources.\n\nI'll clone the repo and read about, thanks for the pointer.\n\nI even have to find out about that alternates mechanism and what it has\nto do with push but not with pull.\n\nRegards\n Klaus\n- -- \nKlaus Ethgen http://www.ethgen.ch/\npub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen \nFingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C\n-----BEGIN PGP SIGNATURE-----\nComment: Charset: ISO-8859-1\n\niQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAlhL3PIACgkQpnwKsYAZ\n9qwVXAv/VQPtAfete9ZwVUqjdiALVv6n6Cyy+AyTNyLsj56/83ibl5OIBJyr1qDb\ne1QueLKEH6qyln+rC5vgejjq4AHk5aPhAx1IpJaaKJKh298c+IImIMxy+84m8xt5\nx39u8Kwuz3oGQNshlTed3/qVUR/zzLzPhbFuvHKk3wXDcIJHjDBmBJ4CWyvmyNOh\nOfOnXaqu4ohNJpwlCNsJvojjstdcpl6Uj7UM5BIdmw1JFuZClw0ljWLHDqC1YIma\n2QbcJ7eY29E+uR6sJKbXuWLgVDE+RrhbBn/GVBATxP5giBLa2z7+gLSMwxcZjTmv\n2gd5nhjBL0aIWrr7IIsgcW9I0P/PTazMGSSBsgupjXqA+/pEBL1ePFoK930F/Hdx\nBqh28jT5OYDoaIQHHDm3z6eZzqysdT2tc+uvBBa+g9NA/D6RzEw1qeRmNvvd4UeS\nr8rENu7+nLibUE4JjQqDWKwF6FsZkwVH5xXZZ/VQoZHfFQep73ZnQGz3PcfKXGkl\n5BMLh24Y\n=FX+B\n-----END PGP SIGNATURE-----\n"},{"id":"307432","messageId":"20161210105155.7kf6jgrojfxa47qf@ikki.ethgen.ch","threadId":"44664","inReplyTo":"20161210102657.ateotzowgek7bjuc@sigill.intra.peff.net","subject":"Re: [BUG] Colon in remote urls","fromName":"Klaus Ethgen","fromEmail":"klaus@ethgen.ch","sentAt":"2016-12-10T10:51:55Z","receivedAt":"2016-12-10T10:52:02Z","isPatch":false,"sender":{"key":"klaus@ethgen.ch","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA512\n\nAm Sa den 10. Dez 2016 um 11:26 schrieb Jeff King:\n> On Sat, Dec 10, 2016 at 10:41:33AM +0100, Klaus Ethgen wrote:\n> \n> > Am Sa den 10. Dez 2016 um 9:26 schrieb Jeff King:\n> > > Yeah, I picked it arbitrarily as the common quoting character, but I\n> > > agree it probably makes backwards compatibility (and general usability\n> > > when you have to double-backslash each instance) pretty gross on\n> > > Windows.\n> > \n> > Well, I don't know of many people using the original git on windows.\n> > Most of them using some graphical third-party tools.\n> \n> I laid out options for addressing the problem elsewhere, but I want to\n> make clear that this line of reasoning is not likely to get any traction\n> here. Git for Windows is a non-trivial part of the user base, and we do\n> care about avoiding regressions there.\n\nI value that.\n\nI just wanted to point out what my observations are and too I don't want\nto see that windows stuff (what is the minority in this case) will get\nmore attention or more priority as stuff on linux (which pretty much is\nthe majority, I believe). Don't get me wrong, I see them both as\nimportant.\n\nAnd even on windows there are pathes with colon in it. (read c:\\...,\nd:\\...)\n\nRegards\n Klaus\n- -- \nKlaus Ethgen http://www.ethgen.ch/\npub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen \nFingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C\n-----BEGIN PGP SIGNATURE-----\nComment: Charset: ISO-8859-1\n\niQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAlhL3ksACgkQpnwKsYAZ\n9qznAgv+IPrgt2yvFE9m/YpZv7viSlV9SsIyr6DjvK1C06N9IZes69z4yywTSjVf\nL5x4ecWEg+k4N7ET+qNp1iaFS70juNvWg0hysbteczxElNGOerR8pEWXxKA+8xpN\ntcY55ZcbBgihPDlQ+ztHAGlngD7E3wwMbzSC5kGCPYYe7Kw9mhLrXzX/MN5V2H/k\n60XXsTkW05kUg01ofFATNppFLJHDTFJhEHiZmytJ5se5fTAUXM0gwFkCYEcPh+72\nd6GsodVNRW++i9ojAEqglPbAaEAAFg1MOULa3KN2xsIYhvyZ8P4hNc2DzPcAsdtr\n8ngoJb80XQ+gLzwJ80RjUnUNFLE+BFUzLrCRxgYyjk3kD7rewLUFHJkte05WBTRv\nt21V/AudDC8i8z7XnQtAFpV8QHjTv00nMqV9e2iaTqmd7QJ8bPvDQmSu86/x3MMM\n/2aFUcPmRu1Pp+XGm8KUDOF+kba8IJAi7Zs0UCNdyj6domjZBsE9N3pKkcbxsNBJ\n0+5Ln4Vi\n=twtR\n-----END PGP SIGNATURE-----\n"},{"id":"307443","messageId":"alpine.DEB.2.20.1612101918040.23160@virtualbox","threadId":"44664","inReplyTo":"20161210093230.26q7fxcrs2cpll6g@ikki.ethgen.ch","subject":"Re: [BUG] Colon in remote urls","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-12-10T18:18:43Z","receivedAt":"2016-12-10T18:19:00Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Klaus,\n\nOn Sat, 10 Dec 2016, Klaus Ethgen wrote:\n\n> -----BEGIN PGP SIGNED MESSAGE-----\n> Hash: SHA512\n> \n> Am Fr den 9. Dez 2016 um 22:32 schrieb Johannes Sixt:\n> > There are too many systems out there that use a backslash in path names. I\n> > don't think it is wise to use it also as the quoting character.\n> \n> Well, the minority, I believe. And only the minority where the command\n> line git is used anywhere.\n\nPlease provide evidence for such bold assumptions.\n\nCiao,\nJohannes\n"},{"id":"307460","messageId":"20161211110208.642unp7c2i653sav@ikki.ethgen.ch","threadId":"44664","inReplyTo":"alpine.DEB.2.20.1612101918040.23160@virtualbox","subject":"Re: [BUG] Colon in remote urls","fromName":"Klaus Ethgen","fromEmail":"klaus@ethgen.ch","sentAt":"2016-12-11T11:02:09Z","receivedAt":"2016-12-11T11:02:20Z","isPatch":false,"sender":{"key":"klaus@ethgen.ch","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA512\n\nHi,\n\nAm Sa den 10. Dez 2016 um 19:18 schrieb Johannes Schindelin:\n> On Sat, 10 Dec 2016, Klaus Ethgen wrote:\n> > Am Fr den 9. Dez 2016 um 22:32 schrieb Johannes Sixt:\n> > > There are too many systems out there that use a backslash in path names. I\n> > > don't think it is wise to use it also as the quoting character.\n> > Well, the minority, I believe. And only the minority where the command\n> > line git is used anywhere.\n> \n> Please provide evidence for such bold assumptions.\n\nHow is it \"bold\" to see that the majority of widows users does not use\nor even like command line tools. And as git is command line tool (most\nof them), users does use third party tools instead of the original.\n\nI know companies where the \"developers\" doesn't even know of the\nexistent of a git command line use. They look with owe when they see\nthat I use a shell to use git.\n\nRegards\n Klaus\n- -- \nKlaus Ethgen http://www.ethgen.ch/\npub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen \nFingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C\n-----BEGIN PGP SIGNATURE-----\nComment: Charset: ISO-8859-1\n\niQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAlhNMioACgkQpnwKsYAZ\n9qzPygv/ZZr+qW4y/JoTWP6BVu+qDFhean7mHoj5vCSgXwCPzZHSvWIDLdqcrboR\nUR7K3oTz9yMaoMRiNq7pu/QBJlwRSJ8ByqSde8mzXOVTqvEC5kvLugU3Ehc1fs0u\nZpoQvXBy0SrpKcuNApMdTFMO9OmCwRNAt2JecCQqyQi6hs6Ws5xTCReOEry00wb/\nRdLKOpXwOn5n3ESRAQcqLWhWGs9aUVrfQRCHR2rIYsjx1s/tt+NVWa0hzTnJZt3T\nwcQDlGjgeXsu8gJHPNSxAJv5paiNK4JG5x6UUOUuAzmvIYmwd6kEiyNQctTRd0JM\nZCBEYnmZQhHbvrkyKsVvUYJhE9FT0hKMAJO791ZiLCN696EJR4BCOZ9I+7GePFtY\ndxb3RNsI9imCXqAHyaguY5tQImzc7P5eQfvH4CdmI9DOmwMUlirvt7pjT94pLFNQ\npxFphD+gd5tUL6QL5fmoUFQVQacQ9Vfs2riTiHerWnBq8P1Hw4KWVYd6ImFo8u3o\naWvUfXFg\n=1Yj3\n-----END PGP SIGNATURE-----\n"},{"id":"307471","messageId":"913EC5FA0C2B4452AF027A84786F08BB@PhilipOakley","threadId":"44664","inReplyTo":"20161211110208.642unp7c2i653sav@ikki.ethgen.ch","subject":"Re: [BUG] Colon in remote urls","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2016-12-11T14:51:43Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Klaus Ethgen\" \nTo: \n> Am Sa den 10. Dez 2016 um 19:18 schrieb Johannes Schindelin:\n>> On Sat, 10 Dec 2016, Klaus Ethgen wrote:\n>> > Am Fr den 9. Dez 2016 um 22:32 schrieb Johannes Sixt:\n>> > > There are too many systems out there that use a backslash in path \n>> > > names. I\n>> > > don't think it is wise to use it also as the quoting character.\n>> > Well, the minority, I believe. And only the minority where the command\n>> > line git is used anywhere.\n>>\n>> Please provide evidence for such bold assumptions.\n>\n> How is it \"bold\" to see that the majority of widows users does not use\n> or even like command line tools. And as git is command line tool (most\n> of them), users does use third party tools instead of the original.\n>\n> I know companies where the \"developers\" doesn't even know of the\n> existent of a git command line use. They look with owe when they see\n> that I use a shell to use git.\n>\nHasn't this drifted a little off topic. The issue was typeable characters in \nURLs and how that affects the accessibility of various paths.\n\nWe (Git) should be avoiding lock-in to particular systems where possible.\n\n--\n\nPhilip\n\n"},{"id":"307500","messageId":"alpine.DEB.2.20.1612121133220.23160@virtualbox","threadId":"44664","inReplyTo":"20161211110208.642unp7c2i653sav@ikki.ethgen.ch","subject":"Re: [BUG] Colon in remote urls","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-12-12T11:03:06Z","receivedAt":"2016-12-12T11:03:21Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Klaus,\n\nOn Sun, 11 Dec 2016, Klaus Ethgen wrote:\n\n> Am Sa den 10. Dez 2016 um 19:18 schrieb Johannes Schindelin:\n> > On Sat, 10 Dec 2016, Klaus Ethgen wrote:\n> > > Am Fr den 9. Dez 2016 um 22:32 schrieb Johannes Sixt:\n> > > > There are too many systems out there that use a backslash in path names. I\n> > > > don't think it is wise to use it also as the quoting character.\n> > > Well, the minority, I believe. And only the minority where the command\n> > > line git is used anywhere.\n> > \n> > Please provide evidence for such bold assumptions.\n> \n> How is it \"bold\" to see that the majority of widows users does not use\n> or even like command line tools.\n\nFirst of all, it is \"Windows users\", not \"widows users\", unless, of\ncourse, you want to discuss things that are completely inappropriate for\nthis list.\n\nSecond, you still did not back up your claim with anything resembling\nevidence, instead just reiterating your beliefs. That is not good enough.\n\nThird, my experience contradicts your beliefs rather violently.\n\nSo let's try some evidence for a change: the 64-bit installer of Git for\nWindows v2.10.2 was downloaded over 1.25 million times. That is not a\nnegligible number. If you want to go back to v2.8.1, it is even 3.8\nmillion downloads. That is a tall number to call a minority.\n\nNow let's look at your claim that Windows users do not use the\ncommand-line. The mere existence of posh-git (Powershell bindings for Git)\nis already a contradiction to that claim.\n\nEven if that was not enough, the Git for Windows bug tracker is full of\nreports of users who clearly use the command-line.\n\nAnd there is more evidence: When comparing the download numbers of the\ndifferent Git for Windows versions, one thing really sticks out: those\nversions were downloaded the most (by a factor of more than 2x over the\nother versions) which were made available through Visual Studio's\n\"Download command-line Git tools\" feature, e.g. v2.8.1 and v2.9.0. That is\na rather strong indicator that users wanted to use the command-line.\n\nFourth, even if Windows users were the minority, and even if Windows users\nwere not using the command-line, which are claims soundly refuted by the\nevidence I presented above, the fact alone that you are talking about\nputting a group of people at a disadvantage based merely on your belief\nthat they are in a minority should not inform us, the Git developers, on\nany kind of policy decision.\n\nWe will not intentionally break Git usage, or make Git usage hard, for\na specific group of Git users, unless there are technical reasons to\ndo that. Demographic reasons do not count.\n\nFor example, we will not make Git hard to use for female programmers,\non the grounds that they currently constitute a minority.\n\n> I know companies where the \"developers\" doesn't even know of the\n> existent of a git command line use. They look with owe when they see\n> that I use a shell to use git.\n\nI must have spoken to hundreds of Git for Windows users, and must have\nbeen in communication with many more via email or bug tracker, and I\ncannot recall a single one who used Git without using the command-line.\n\nNote: I do not count my personal experience here as evidence, but the\nnumbers alone are a strong indicator to me that your argument has a pretty\nweak foundation.\n\nCiao,\nJohannes\n\nP.S.: Maybe reply-to-all in the future; it is the custom on this here\nmailing list.\n"},{"id":"307505","messageId":"20161212115030.qx2y276bxnzbtxkj@ikki.ethgen.ch","threadId":"44664","inReplyTo":"alpine.DEB.2.20.1612121133220.23160@virtualbox","subject":"Re: [BUG] Colon in remote urls","fromName":"Klaus Ethgen","fromEmail":"klaus@ethgen.ch","sentAt":"2016-12-12T11:50:30Z","receivedAt":"2016-12-12T11:50:39Z","isPatch":false,"sender":{"key":"klaus@ethgen.ch","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA512\n\nHi,\n\nAm Mo den 12. Dez 2016 um 12:03 schrieb Johannes Schindelin:\n> On Sun, 11 Dec 2016, Klaus Ethgen wrote:\n> > Am Sa den 10. Dez 2016 um 19:18 schrieb Johannes Schindelin:\n> > > On Sat, 10 Dec 2016, Klaus Ethgen wrote:\n> > > > Am Fr den 9. Dez 2016 um 22:32 schrieb Johannes Sixt:\n> > > > > There are too many systems out there that use a backslash in path names. I\n> > > > > don't think it is wise to use it also as the quoting character.\n> > > > Well, the minority, I believe. And only the minority where the command\n> > > > line git is used anywhere.\n> > > Please provide evidence for such bold assumptions.\n> > How is it \"bold\" to see that the majority of widows users does not use\n> > or even like command line tools.\n> \n> First of all, it is \"Windows users\", not \"widows users\", unless, of\n> course, you want to discuss things that are completely inappropriate for\n> this list.\n\nSorry to have a typo in my response.\n\n> Second, you still did not back up your claim with anything resembling\n> evidence, instead just reiterating your beliefs. That is not good enough.\n\nWell, my evidence is what I seen with many windows users in the past. I\nhave no link or something like that. I just shared that observation.\n\n> Third, my experience contradicts your beliefs rather violently.\n\nSo we have two different observations. Good. Have no problem with that.\n\n[...]\n> Now let's look at your claim that Windows users do not use the\n> command-line. The mere existence of posh-git (Powershell bindings for Git)\n> is already a contradiction to that claim.\n\nIs that the same git tools or is it a separate implementation?\n\n[Proof of many downloads and other]\n\nProofs accepted. They do not match my observations but ok.\n\n> Fourth, even if Windows users were the minority, and even if Windows users\n> were not using the command-line, which are claims soundly refuted by the\n> evidence I presented above, the fact alone that you are talking about\n> putting a group of people at a disadvantage based merely on your belief\n> that they are in a minority should not inform us, the Git developers, on\n> any kind of policy decision.\n> \n> We will not intentionally break Git usage, or make Git usage hard, for\n> a specific group of Git users, unless there are technical reasons to\n> do that. Demographic reasons do not count.\n\nSorry, but I was posting my answer to the comment of preferring not to\nallow \":\" in prefer of using \"\\\" for quoting. I never wanted to attack\nyou. It was just a response... And I do not remember attacking you\npersonally to style me \"bold\".\n\nCurrently the source of that all was, that push to pathes with \":\" did\nbreak in the current version. I did not ask for implementing something\ninstead of something different. I just ask for fixing of a regression.\n\nMoreover, as you might know, windows users are more affected by that bug\nas they have a colon in every absolute path. Nevertheless I had that\nproblem on linux but with a map to a windows share.\n\nFor more, I have to agree with Philip, that this is a bit off topic. So\nplease stop taking single words on the personal level. Please stay on\nthe technical level. My english is to bad to go to personal level\ndiscussions. And I don't want to spend time to personal or (as you\ntried) feminism discussions.\n\nRegards\n Klaus\n- -- \nKlaus Ethgen http://www.ethgen.ch/\npub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen \nFingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C\n-----BEGIN PGP SIGNATURE-----\nComment: Charset: ISO-8859-1\n\niQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAlhOjvwACgkQpnwKsYAZ\n9qyb2wwAuUFTRrOQcJ6mDLx5bHPNrQy6e4ify4qWcfcp3VJhOLpA56CdJwwA2bcl\ngcllUwOn+SSjjYaRmuFQ6aY0/oKDEtF98Zh01pXLnAgY+Dabg9gfBCMWyWv8LxUf\nNWHADPpSkY2eongvm6aXOGTqNvU73wriuQKM6BwG49bJUpdR1q8Fe+DjtufrS8eW\nALeGoEFrbm0aIbd121AvWw53hCz3j9ssDpGdFefkhjeJnRcSSDmzTID5KcuWME9P\nL67BjGJb3swYIpw3Sdg7LjWnMK0o9GpzfZVNuJFMsRHBQUaWAQvVG79AHe/5QI9w\npq0K5C6frllP5CgcoD2/H+8F8sMD7BrhyN1MxFRdaa4eCEh/hFxZV2nIfbZnx0SS\n5/SNMKcCdly+yodZCgohU4uJuqDBkRIEbr6+OCffsupQMCYkh/Ew/RRa8tMN26bN\n45/ferqMK1KEenpllXGNHi3/a9dT5CaqEvLjErdatChhQR6i7QbA5B3KhXKRSsRz\nYPbYc7rc\n=e8K5\n-----END PGP SIGNATURE-----\n"},{"id":"307507","messageId":"alpine.DEB.2.20.1612121453020.23160@virtualbox","threadId":"44664","inReplyTo":"20161212115030.qx2y276bxnzbtxkj@ikki.ethgen.ch","subject":"Re: [BUG] Colon in remote urls","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-12-12T14:05:05Z","receivedAt":"2016-12-12T14:05:21Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Klaus,\n\nyou probably missed the note about reply-to-all being customary on this\nlist. The reason is that this list is high-volume, and open to\nnon-subscribers. You may want to get into the habit of hitting\nreply-to-all when responding to mails from this list, in case that you\nplan to continue communicating on this forum.\n\nOn Mon, 12 Dec 2016, Klaus Ethgen wrote:\n\n> Am Mo den 12. Dez 2016 um 12:03 schrieb Johannes Schindelin:\n> > On Sun, 11 Dec 2016, Klaus Ethgen wrote:\n> > > Am Sa den 10. Dez 2016 um 19:18 schrieb Johannes Schindelin:\n> > > > On Sat, 10 Dec 2016, Klaus Ethgen wrote:\n> > > > > Am Fr den 9. Dez 2016 um 22:32 schrieb Johannes Sixt:\n> > > > > > There are too many systems out there that use a backslash in path names. I\n> > > > > > don't think it is wise to use it also as the quoting character.\n> > > > > Well, the minority, I believe. And only the minority where the command\n> > > > > line git is used anywhere.\n> > > > Please provide evidence for such bold assumptions.\n> > > How is it \"bold\" to see that the majority of widows users does not use\n> > > or even like command line tools.\n> > \n> > Second, you still did not back up your claim with anything resembling\n> > evidence, instead just reiterating your beliefs. That is not good enough.\n> \n> Well, my evidence is what I seen with many windows users in the past. I\n> have no link or something like that. I just shared that observation.\n\nThank you for confirming that you just shared a personal observation and\ndid not plan to back that up by scientific evidence.\n\nIn light of that, let's continue according to Johannes Sixt's insightful\nsuggestions.\n\nCiao,\nJohannes\n"},{"id":"307535","messageId":"20161212194929.bdcihf7orjabzb2h@sigill.intra.peff.net","threadId":"44664","inReplyTo":"20161210085133.2pnkz6eqlxoxdckg@sigill.intra.peff.net","subject":"[PATCH 0/2] handling alternates paths with colons","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-12T19:49:29Z","receivedAt":"2016-12-12T19:49:38Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Dec 10, 2016 at 03:51:33AM -0500, Jeff King wrote:\n\n> So here's the array of options, as I see it:\n> \n> 1. Disable quarantine by default; only turn it on if you don't have\n> any of the funny corner cases.\n> \n> 2. Introduce an extra single-item environment variable that gets\n> appended to the list of alternates, and side-steps quoting issues.\n> \n> 3. Introduce a new variable that can hold an alternate list, and\n> either teach it reasonable quoting semantics, or give it a\n> less-common separator.\n> \n> 4. Introduce quoting to the existing variable, but make the quoting\n> character sufficiently obscure that nobody cares about the lack of\n> backwards compatibility.\n\nSo I started on (4), but writing the user-facing documentation made me\nthrow up in my mouth a little. Fortunately that inspired me to come up\nwith a fifth option: introduce a quoting mechanism that needs a more\nobscure signature to kick in, but once kicked-in, uses a less obscure\nsyntax.\n\nSo here are patches that do that. It kicks in only when the first\ncharacter of a path is a double-quote, and then expects the usual\nC-style quoting. My reasoning is that we wouldn't want to sacrifice\n'\"' for ':', but it's probably OK if we only care about '\"' at the very\nbeginning of a path. And it's consistent with many other parts of git\nwhich allow optional quoting.\n\nThoughts?\n\n [1/2]: alternates: accept double-quoted paths\n [2/2]: tmp-objdir: quote paths we add to alternates\n\n Documentation/git.txt | 6 ++++++\n sha1_file.c | 47 +++++++++++++++++++++++++++++++++++-----------\n t/t5547-push-quarantine.sh | 19 +++++++++++++++++++\n t/t5615-alternate-env.sh | 18 ++++++++++++++++++\n tmp-objdir.c | 18 +++++++++++++++++-\n 5 files changed, 96 insertions(+), 12 deletions(-)\n\n-Peff\n"},{"id":"307537","messageId":"20161212195222.rxnabok6amklt2zf@sigill.intra.peff.net","threadId":"44664","inReplyTo":"20161212194929.bdcihf7orjabzb2h@sigill.intra.peff.net","subject":"[PATCH 1/2] alternates: accept double-quoted paths","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-12T19:52:22Z","receivedAt":"2016-12-12T19:52:31Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"We read lists of alternates from objects/info/alternates\nfiles (delimited by newline), as well as from the\nGIT_ALTERNATE_OBJECT_DIRECTORIES environment variable\n(delimited by colon or semi-colon, depending on the\nplatform).\n\nThere's no mechanism for quoting the delimiters, so it's\nimpossible to specify an alternate path that contains a\ncolon in the environment, or one that contains a newline in\na file. We've lived with that restriction for ages because\nboth alternates and filenames with colons are relatively\nrare, and it's only a problem when the two meet. But since\n722ff7f87 (receive-pack: quarantine objects until\npre-receive accepts, 2016-10-03), which builds on the\nalternates system, every push causes the receiver to set\nGIT_ALTERNATE_OBJECT_DIRECTORIES internally.\n\nIt would be convenient to have some way to quote the\ndelimiter so that we can represent arbitrary paths.\n\nThe simplest thing would be an escape character before a\nquoted delimiter (e.g., \"\\:\" as a literal colon). But that\ncreates a backwards compatibility problem: any path which\nuses that escape character is now broken, and we've just\nshifted the problem. We could choose an unlikely escape\ncharacter (e.g., something from the non-printable ASCII\nrange), but that's awkward to use.\n\nInstead, let's treat names as unquoted unless they begin\nwith a double-quote, in which case they are interpreted via\nour usual C-stylke quoting rules. This also breaks\nbackwards-compatibility, but in a smaller way: it only\nmatters if your file has a double-quote as the very _first_\ncharacter in the path (whereas an escape character is a\nproblem anywhere in the path). It's also consistent with\nmany other parts of git, which accept either a bare pathname\nor a double-quoted one, and the sender can choose to quote\nor not as required.\n\nSigned-off-by: Jeff King \n---\nThis also lets you specify paths that start with \"#\", or ones that\ncontain newlines in an alternates file, though I doubt anybody really\ncares much in practice. I didn't even bother to add them to the test\nsuite, mostly because of the compatibility hassle (though I guess we\ncould just mark them with !MINGW and be OK).\n\n Documentation/git.txt | 6 ++++++\n sha1_file.c | 47 ++++++++++++++++++++++++++++++++++++-----------\n t/t5615-alternate-env.sh | 18 ++++++++++++++++++\n 3 files changed, 60 insertions(+), 11 deletions(-)\n\ndiff --git a/Documentation/git.txt b/Documentation/git.txt\nindex af191c51b..98033302b 100644\n--- a/Documentation/git.txt\n+++ b/Documentation/git.txt\n@@ -871,6 +871,12 @@ Git so take care if using a foreign front-end.\n \tspecifies a \":\" separated (on Windows \";\" separated) list\n \tof Git object directories which can be used to search for Git\n \tobjects. New objects will not be written to these directories.\n++\n+\tEntries that begin with `\"` (double-quote) will be interpreted\n+\tas C-style quoted paths, removing leading and trailing\n+\tdouble-quotes and respecting backslash escapes. E.g., the value\n+\t`\"path-with-\\\"-and-:-in-it\":vanilla-path` has two paths:\n+\t`path-with-\"-and-:-in-it` and `vanilla-path`.\n \n `GIT_DIR`::\n \tIf the `GIT_DIR` environment variable is set then it\ndiff --git a/sha1_file.c b/sha1_file.c\nindex 9c86d1924..117307185 100644\n--- a/sha1_file.c\n+++ b/sha1_file.c\n@@ -26,6 +26,7 @@\n #include \"mru.h\"\n #include \"list.h\"\n #include \"mergesort.h\"\n+#include \"quote.h\"\n \n #ifndef O_NOATIME\n #if defined(__linux__) && (defined(__i386__) || defined(__PPC__))\n@@ -329,13 +330,40 @@ static int link_alt_odb_entry(const char *entry, const char *relative_base,\n \treturn 0;\n }\n \n+static const char *parse_alt_odb_entry(const char *string,\n+\t\t\t\t int sep,\n+\t\t\t\t struct strbuf *out)\n+{\n+\tconst char *end;\n+\n+\tstrbuf_reset(out);\n+\n+\tif (*string == '#') {\n+\t\t/* comment; consume up to next separator */\n+\t\tend = strchrnul(string, sep);\n+\t} else if (*string == '\"' && !unquote_c_style(out, string, &end)) {\n+\t\t/*\n+\t\t * quoted path; unquote_c_style has copied the\n+\t\t * data for us and set \"end\". Broken quoting (e.g.,\n+\t\t * an entry that doesn't end with a quote) falls\n+\t\t * back to the unquoted case below.\n+\t\t */\n+\t} else {\n+\t\t/* normal, unquoted path */\n+\t\tend = strchrnul(string, sep);\n+\t\tstrbuf_add(out, string, end - string);\n+\t}\n+\n+\tif (*end)\n+\t\tend++;\n+\treturn end;\n+}\n+\n static void link_alt_odb_entries(const char *alt, int len, int sep,\n \t\t\t\t const char *relative_base, int depth)\n {\n-\tstruct string_list entries = STRING_LIST_INIT_NODUP;\n-\tchar *alt_copy;\n-\tint i;\n \tstruct strbuf objdirbuf = STRBUF_INIT;\n+\tstruct strbuf entry = STRBUF_INIT;\n \n \tif (depth > 5) {\n \t\terror(\"%s: ignoring alternate object stores, nesting too deep.\",\n@@ -348,16 +376,13 @@ static void link_alt_odb_entries(const char *alt, int len, int sep,\n \t\tdie(\"unable to normalize object directory: %s\",\n \t\t objdirbuf.buf);\n \n-\talt_copy = xmemdupz(alt, len);\n-\tstring_list_split_in_place(&entries, alt_copy, sep, -1);\n-\tfor (i = 0; i < entries.nr; i++) {\n-\t\tconst char *entry = entries.items[i].string;\n-\t\tif (entry[0] == '\\0' || entry[0] == '#')\n+\twhile (*alt) {\n+\t\talt = parse_alt_odb_entry(alt, sep, &entry);\n+\t\tif (!entry.len)\n \t\t\tcontinue;\n-\t\tlink_alt_odb_entry(entry, relative_base, depth, objdirbuf.buf);\n+\t\tlink_alt_odb_entry(entry.buf, relative_base, depth, objdirbuf.buf);\n \t}\n-\tstring_list_clear(&entries, 0);\n-\tfree(alt_copy);\n+\tstrbuf_release(&entry);\n \tstrbuf_release(&objdirbuf);\n }\n \ndiff --git a/t/t5615-alternate-env.sh b/t/t5615-alternate-env.sh\nindex eec4137ca..69fd8f891 100755\n--- a/t/t5615-alternate-env.sh\n+++ b/t/t5615-alternate-env.sh\n@@ -68,4 +68,22 @@ test_expect_success 'access alternate via relative path (subdir)' '\n \tEOF\n '\n \n+# set variables outside test to avoid quote insanity; the \\057 is '/',\n+# which doesn't need quoting, but just confirms that de-quoting\n+# is working.\n+quoted='\"one.git\\057objects\"'\n+unquoted='two.git/objects'\n+test_expect_success 'mix of quoted and unquoted alternates' '\n+\tcheck_obj \"$quoted:$unquoted\" <<-EOF\n+\t$one blob\n+\t$two blob\n+'\n+\n+test_expect_success 'broken quoting falls back to interpreting raw' '\n+\tmv one.git \\\"one.git &&\n+\tcheck_obj \\\"one.git/objects <<-EOF\n+\t$one blob\n+\tEOF\n+'\n+\n test_done\n-- \n2.11.0.203.g6657065\n\n"},{"id":"307538","messageId":"20161212195355.znqlu44lgnke3ltc@sigill.intra.peff.net","threadId":"44664","inReplyTo":"20161212194929.bdcihf7orjabzb2h@sigill.intra.peff.net","subject":"[PATCH 2/2] tmp-objdir: quote paths we add to alternates","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-12T19:53:55Z","receivedAt":"2016-12-12T19:54:03Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"Commit 722ff7f87 (receive-pack: quarantine objects until\npre-receive accepts, 2016-10-03) regressed pushes to\nrepositories with colon (or semi-colon in Windows in them)\nbecause it adds the repository's main object directory to\nGIT_ALTERNATE_OBJECT_DIRECTORIES. The receiver interprets\nthe colon as a delimiter, not as part of the path, and\nindex-pack is unable to find objects which it needs to\nresolve deltas.\n\nThe previous commit introduced a quoting mechanism for the\nalternates list; let's use it here to cover this case. We'll\navoid quoting when we can, though. This alternate setup is\nalso used when calling hooks, so it's possible that the user\nmay call older git implementations which don't understand\nthe quoting mechanism. By quoting only when necessary, this\nsetup will continue to work unless the user _also_ has a\nrepository whose path contains the delimiter.\n\nSigned-off-by: Jeff King \n---\nJohannes, please let me know if I am wrong about skipping the test on\n!MINGW. The appropriate check there would be \";\" anyway, but I am not\nsure _that_ is allowed in paths, either.\n\n t/t5547-push-quarantine.sh | 19 +++++++++++++++++++\n tmp-objdir.c | 18 +++++++++++++++++-\n 2 files changed, 36 insertions(+), 1 deletion(-)\n\ndiff --git a/t/t5547-push-quarantine.sh b/t/t5547-push-quarantine.sh\nindex 1e5d32d06..6275ec807 100755\n--- a/t/t5547-push-quarantine.sh\n+++ b/t/t5547-push-quarantine.sh\n@@ -33,4 +33,23 @@ test_expect_success 'rejected objects are removed' '\n \ttest_cmp expect actual\n '\n \n+# MINGW does not allow colons in pathnames in the first place\n+test_expect_success !MINGW 'push to repo path with colon' '\n+\t# The interesting failure case here is when the\n+\t# receiving end cannot access its original object directory,\n+\t# so make it likely for us to generate a delta by having\n+\t# a non-trivial file with multiple versions.\n+\n+\ttest-genrandom foo 4096 >file.bin &&\n+\tgit add file.bin &&\n+\tgit commit -m bin &&\n+\tgit clone --bare . xxx:yyy.git &&\n+\n+\techo change >>file.bin &&\n+\tgit commit -am change &&\n+\t# Note that we have to use the full path here, or it gets confused\n+\t# with the ssh host:path syntax.\n+\tgit push \"$PWD/xxx:yyy.git\" HEAD\n+'\n+\n test_done\ndiff --git a/tmp-objdir.c b/tmp-objdir.c\nindex 64435f23a..b2d9280f1 100644\n--- a/tmp-objdir.c\n+++ b/tmp-objdir.c\n@@ -5,6 +5,7 @@\n #include \"string-list.h\"\n #include \"strbuf.h\"\n #include \"argv-array.h\"\n+#include \"quote.h\"\n \n struct tmp_objdir {\n \tstruct strbuf path;\n@@ -79,12 +80,27 @@ static void remove_tmp_objdir_on_signal(int signo)\n */\n static void env_append(struct argv_array *env, const char *key, const char *val)\n {\n-\tconst char *old = getenv(key);\n+\tstruct strbuf quoted = STRBUF_INIT;\n+\tconst char *old;\n \n+\t/*\n+\t * Avoid quoting if it's not necessary, for maximum compatibility\n+\t * with older parsers which don't understand the quoting.\n+\t */\n+\tif (*val == '\"' || strchr(val, PATH_SEP)) {\n+\t\tstrbuf_addch("ed, '\"');\n+\t\tquote_c_style(val, "ed, NULL, 1);\n+\t\tstrbuf_addch("ed, '\"');\n+\t\tval = quoted.buf;\n+\t}\n+\n+\told = getenv(key);\n \tif (!old)\n \t\targv_array_pushf(env, \"%s=%s\", key, val);\n \telse\n \t\targv_array_pushf(env, \"%s=%s%c%s\", key, old, PATH_SEP, val);\n+\n+\tstrbuf_release("ed);\n }\n \n static void env_replace(struct argv_array *env, const char *key, const char *val)\n-- \n2.11.0.203.g6657065\n"},{"id":"307545","messageId":"d83cd58f-9b52-cbc5-04dd-5aafe2822533@kdbg.org","threadId":"44664","inReplyTo":"20161212195355.znqlu44lgnke3ltc@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] tmp-objdir: quote paths we add to alternates","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2016-12-12T20:53:11Z","receivedAt":"2016-12-12T20:53:21Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 12.12.2016 um 20:53 schrieb Jeff King:\n> Johannes, please let me know if I am wrong about skipping the test on\n> !MINGW.\n\nThanks for being considerate. The !MINGW prerequisite is required for \nthe test as written.\n\n> The appropriate check there would be \";\" anyway, but I am not\n> sure _that_ is allowed in paths, either.\n\nThat was also my line of thought. I tested earlier today whether a file \nname can have \";\", and the OS did not reject it bluntly. Let me see \nwhether I can adjust the test case for Windows.\n\n-- Hannes\n\n"},{"id":"307554","messageId":"xmqqvauo7p0r.fsf@gitster.mtv.corp.google.com","threadId":"44664","inReplyTo":"20161212194929.bdcihf7orjabzb2h@sigill.intra.peff.net","subject":"Re: [PATCH 0/2] handling alternates paths with colons","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-12-12T22:37:08Z","receivedAt":"2016-12-12T22:37:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> So here are patches that do that. It kicks in only when the first\n> character of a path is a double-quote, and then expects the usual\n> C-style quoting.\n\nThe quote being per delimited component is what makes this fifth\napproach a huge win. \n\nAll sane components on a list-valued environment are still honored\nand an insane component that has either a colon in the middle or\nbegins with a double-quote gets quoted. As long as nobody used a\npath that begins with a double-quote as an element in such a\nlist-valued environment (and they cannot be, as using a non-absolute\npath as an element does not make much sense), this will be safe, and\na path with a colon didn't work with Git unaware of the new quoting\nrule anyway. Nice.\n\n\n\n"},{"id":"307587","messageId":"CACsJy8B52ZDRTUjGLqub_1wELtugv99xbDnBg1PX1LUTb6nVMQ@mail.gmail.com","threadId":"44664","inReplyTo":"20161212195222.rxnabok6amklt2zf@sigill.intra.peff.net","subject":"Re: [PATCH 1/2] alternates: accept double-quoted paths","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-12-13T11:30:15Z","receivedAt":"2016-12-13T11:30:52Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Dec 13, 2016 at 2:52 AM, Jeff King wrote:\n> Instead, let's treat names as unquoted unless they begin\n> with a double-quote, in which case they are interpreted via\n> our usual C-stylke quoting rules. This also breaks\n> backwards-compatibility, but in a smaller way: it only\n> matters if your file has a double-quote as the very _first_\n> character in the path (whereas an escape character is a\n> problem anywhere in the path). It's also consistent with\n> many other parts of git, which accept either a bare pathname\n> or a double-quoted one, and the sender can choose to quote\n> or not as required.\n\nAt least attr has the same problem and is going the same direction\n[1]. Cool. (I actually thought the patch was in and evidence that this\nkind of backward compatibility breaking was ok, turns out the patch\nhas stayed around for years)\n\n[1] http://public-inbox.org/git/%3C20161110203428.30512-18-sbeller@google.com%3E/\n-- \nDuy\n"},{"id":"307588","messageId":"20161213114414.masgfo7lf7e3utym@sigill.intra.peff.net","threadId":"44664","inReplyTo":"d83cd58f-9b52-cbc5-04dd-5aafe2822533@kdbg.org","subject":"Re: [PATCH 2/2] tmp-objdir: quote paths we add to alternates","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-13T11:44:15Z","receivedAt":"2016-12-13T11:44:25Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Dec 12, 2016 at 09:53:11PM +0100, Johannes Sixt wrote:\n\n> > The appropriate check there would be \";\" anyway, but I am not\n> > sure _that_ is allowed in paths, either.\n> \n> That was also my line of thought. I tested earlier today whether a file name\n> can have \";\", and the OS did not reject it bluntly. Let me see whether I can\n> adjust the test case for Windows.\n\nThe naive conversion is just:\n\ndiff --git a/t/t5547-push-quarantine.sh b/t/t5547-push-quarantine.sh\nindex 6275ec807..e195e168b 100755\n--- a/t/t5547-push-quarantine.sh\n+++ b/t/t5547-push-quarantine.sh\n@@ -33,8 +33,13 @@ test_expect_success 'rejected objects are removed' '\n \ttest_cmp expect actual\n '\n \n-# MINGW does not allow colons in pathnames in the first place\n-test_expect_success !MINGW 'push to repo path with colon' '\n+if test_have_prereq MINGW\n+then\n+\tpath_sep=';'\n+else\n+\tpath_sep=':'\n+fi\n+test_expect_success 'push to repo path with (semi-)colon separator' '\n \t# The interesting failure case here is when the\n \t# receiving end cannot access its original object directory,\n \t# so make it likely for us to generate a delta by having\n@@ -43,13 +48,13 @@ test_expect_success !MINGW 'push to repo path with colon' '\n \ttest-genrandom foo 4096 >file.bin &&\n \tgit add file.bin &&\n \tgit commit -m bin &&\n-\tgit clone --bare . xxx:yyy.git &&\n+\tgit clone --bare . xxx${path_sep}yyy.git &&\n \n \techo change >>file.bin &&\n \tgit commit -am change &&\n \t# Note that we have to use the full path here, or it gets confused\n \t# with the ssh host:path syntax.\n-\tgit push \"$PWD/xxx:yyy.git\" HEAD\n+\tgit push \"$PWD/xxx${path_sep}yyy.git\" HEAD\n '\n \n test_done\n\nDoes that work?\n\n-Peff\n"},{"id":"307589","messageId":"20161213115018.quulwlheycjtlsub@sigill.intra.peff.net","threadId":"44664","inReplyTo":"xmqqvauo7p0r.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH 0/2] handling alternates paths with colons","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-13T11:50:18Z","receivedAt":"2016-12-13T11:50:37Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Dec 12, 2016 at 02:37:08PM -0800, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > So here are patches that do that. It kicks in only when the first\n> > character of a path is a double-quote, and then expects the usual\n> > C-style quoting.\n> \n> The quote being per delimited component is what makes this fifth\n> approach a huge win. \n> \n> All sane components on a list-valued environment are still honored\n> and an insane component that has either a colon in the middle or\n> begins with a double-quote gets quoted. As long as nobody used a\n> path that begins with a double-quote as an element in such a\n> list-valued environment (and they cannot be, as using a non-absolute\n> path as an element does not make much sense), this will be safe, and\n> a path with a colon didn't work with Git unaware of the new quoting\n> rule anyway. Nice.\n\nWe do support non-absolute paths, both in alternates files and\nenvironment variables. It's a nice feature if you want to have a\nrelocatable family of shared repositories. I'd imagine that most cases\nstart with \"../\", though.\n\n-Peff\n"},{"id":"307590","messageId":"20161213115218.7arxxatus7qjdu2m@sigill.intra.peff.net","threadId":"44664","inReplyTo":"CACsJy8B52ZDRTUjGLqub_1wELtugv99xbDnBg1PX1LUTb6nVMQ@mail.gmail.com","subject":"Re: [PATCH 1/2] alternates: accept double-quoted paths","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-13T11:52:18Z","receivedAt":"2016-12-13T11:52:27Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Dec 13, 2016 at 06:30:15PM +0700, Duy Nguyen wrote:\n\n> On Tue, Dec 13, 2016 at 2:52 AM, Jeff King wrote:\n> > Instead, let's treat names as unquoted unless they begin\n> > with a double-quote, in which case they are interpreted via\n> > our usual C-stylke quoting rules. This also breaks\n> > backwards-compatibility, but in a smaller way: it only\n> > matters if your file has a double-quote as the very _first_\n> > character in the path (whereas an escape character is a\n> > problem anywhere in the path). It's also consistent with\n> > many other parts of git, which accept either a bare pathname\n> > or a double-quoted one, and the sender can choose to quote\n> > or not as required.\n> \n> At least attr has the same problem and is going the same direction\n> [1]. Cool. (I actually thought the patch was in and evidence that this\n> kind of backward compatibility breaking was ok, turns out the patch\n> has stayed around for years)\n> \n> [1] http://public-inbox.org/git/%3C20161110203428.30512-18-sbeller@google.com%3E/\n\nThanks for digging that up. As soon as I came up with the idea[1], I\nwanted to use the attr code as an example of a similar problem and\nsolution, but I couldn't find it in the code. Which makes sense if it\nwasn't merged.\n\nI do think it's a pretty reasonable approach in general, and would be OK\nfor the attributes code.\n\n-Peff\n\n[1] One could argue that I did not come up with the idea at all, but\n rather just remembered that somebody else had done so. :)\n"},{"id":"307644","messageId":"xmqq1sxb66t5.fsf@gitster.mtv.corp.google.com","threadId":"44664","inReplyTo":"CACsJy8B52ZDRTUjGLqub_1wELtugv99xbDnBg1PX1LUTb6nVMQ@mail.gmail.com","subject":"Re: [PATCH 1/2] alternates: accept double-quoted paths","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-12-13T18:08:06Z","receivedAt":"2016-12-13T18:08:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Duy Nguyen writes:\n\n> At least attr has the same problem and is going the same direction\n> [1]. Cool. (I actually thought the patch was in and evidence that this\n> kind of backward compatibility breaking was ok, turns out the patch\n> has stayed around for years)\n>\n> [1] http://public-inbox.org/git/%3C20161110203428.30512-18-sbeller@google.com%3E/\n\nSeeing that again, I see this in the proposed log message:\n\n Full pattern must be quoted. So 'pat\"t\"ern attr' will give exactly\n 'pat\"t\"ern', not 'pattern'.\n\nI cannot tell what it is trying to say. The code suggests something\nquite different, i.e. a line like this\n\n\t\"pat\\\"t\\\"ern\" attr\n\nwould tell us that a path that matches the pattern\n\n\tpat\"t\"ern\n\nis given 'attr'. \n\nThe log message may need to be cleaned up. The update by that\ncommit to the documentation looks alright, thoguh.\n\n"},{"id":"307645","messageId":"xmqqwpf34s5f.fsf@gitster.mtv.corp.google.com","threadId":"44664","inReplyTo":"20161213114414.masgfo7lf7e3utym@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] tmp-objdir: quote paths we add to alternates","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-12-13T18:10:04Z","receivedAt":"2016-12-13T18:10:16Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> The naive conversion is just:\n> ...\n> -# MINGW does not allow colons in pathnames in the first place\n> -test_expect_success !MINGW 'push to repo path with colon' '\n> +if test_have_prereq MINGW\n> +then\n> +\tpath_sep=';'\n> +else\n> +\tpath_sep=':'\n> +fi\n> ...\n> -\tgit clone --bare . xxx:yyy.git &&\n> +\tgit clone --bare . xxx${path_sep}yyy.git &&\n\nDon't you want to dq the whole thing to prevent the shell from\nsplitting this into two commands at ';'? The other one below is OK.\n\n> \n> \techo change >>file.bin &&\n> \tgit commit -am change &&\n> \t# Note that we have to use the full path here, or it gets confused\n> \t# with the ssh host:path syntax.\n> -\tgit push \"$PWD/xxx:yyy.git\" HEAD\n> +\tgit push \"$PWD/xxx${path_sep}yyy.git\" HEAD\n> '\n> \n> test_done\n>\n> Does that work?\n>\n> -Peff\n"},{"id":"307646","messageId":"xmqqshpr4s41.fsf@gitster.mtv.corp.google.com","threadId":"44664","inReplyTo":"20161213115018.quulwlheycjtlsub@sigill.intra.peff.net","subject":"Re: [PATCH 0/2] handling alternates paths with colons","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-12-13T18:10:54Z","receivedAt":"2016-12-13T18:11:02Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Mon, Dec 12, 2016 at 02:37:08PM -0800, Junio C Hamano wrote:\n>\n>> Jeff King writes:\n>> \n>> > So here are patches that do that. It kicks in only when the first\n>> > character of a path is a double-quote, and then expects the usual\n>> > C-style quoting.\n>> \n>> The quote being per delimited component is what makes this fifth\n>> approach a huge win. \n>> \n>> All sane components on a list-valued environment are still honored\n>> and an insane component that has either a colon in the middle or\n>> begins with a double-quote gets quoted. As long as nobody used a\n>> path that begins with a double-quote as an element in such a\n>> list-valued environment (and they cannot be, as using a non-absolute\n>> path as an element does not make much sense), this will be safe, and\n>> a path with a colon didn't work with Git unaware of the new quoting\n>> rule anyway. Nice.\n>\n> We do support non-absolute paths, both in alternates files and\n> environment variables. It's a nice feature if you want to have a\n> relocatable family of shared repositories. I'd imagine that most cases\n> start with \"../\", though.\n\nYes. I was only talking about the environment variable, as you can\ntell from my mention of \"colon\" there.\n"},{"id":"307648","messageId":"20161213181538.6gv4it4b33uhbuud@sigill.intra.peff.net","threadId":"44664","inReplyTo":"xmqqwpf34s5f.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH 2/2] tmp-objdir: quote paths we add to alternates","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-13T18:15:38Z","receivedAt":"2016-12-13T18:16:11Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Dec 13, 2016 at 10:10:04AM -0800, Junio C Hamano wrote:\n\n> > -\tgit clone --bare . xxx:yyy.git &&\n> > +\tgit clone --bare . xxx${path_sep}yyy.git &&\n> \n> Don't you want to dq the whole thing to prevent the shell from\n> splitting this into two commands at ';'? The other one below is OK.\n\nAfter expansion, I don't think the shell will do any further processing\nexcept for whitespace splitting. E.g.:\n\n $ debug() { for i in \"$@\"; do echo \"got $i\"; done; }\n $ sep=';'\n $ space=' '\n $ debug foo${sep}bar\n got foo;bar\n $ debug foo${space}bar\n got foo\n got bar\n\nI don't mind quoting it to make it more obvious, though.\n\n-Peff\n"},{"id":"307650","messageId":"20161213181755.wrgu6drm45v7xhnl@sigill.intra.peff.net","threadId":"44664","inReplyTo":"xmqqshpr4s41.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH 0/2] handling alternates paths with colons","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-13T18:17:55Z","receivedAt":"2016-12-13T18:18:02Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Dec 13, 2016 at 10:10:54AM -0800, Junio C Hamano wrote:\n\n> > We do support non-absolute paths, both in alternates files and\n> > environment variables. It's a nice feature if you want to have a\n> > relocatable family of shared repositories. I'd imagine that most cases\n> > start with \"../\", though.\n> \n> Yes. I was only talking about the environment variable, as you can\n> tell from my mention of \"colon\" there.\n\nRight, but we also support relative paths via environment variables. I\ndon't think that changes the conclusion though. I'm not convinced\nrelative paths via the environment aren't slightly insane in the first\nplace, given the discussion in 37a95862c (alternates: re-allow relative\npaths from environment, 2016-11-07). And they'd probably start with\n\"../\" as well.\n\n-Peff\n"},{"id":"307651","messageId":"xmqqbmwf4qn4.fsf@gitster.mtv.corp.google.com","threadId":"44664","inReplyTo":"20161213181755.wrgu6drm45v7xhnl@sigill.intra.peff.net","subject":"Re: [PATCH 0/2] handling alternates paths with colons","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-12-13T18:42:39Z","receivedAt":"2016-12-13T18:42:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Right, but we also support relative paths via environment variables. I\n> don't think that changes the conclusion though. I'm not convinced\n> relative paths via the environment aren't slightly insane in the first\n> place,\n\nSorry, a triple negation is above my head. \"relative paths in env\naren't insane\" == \"using relative paths is OK\" and you are not\nconvinced that it is the case, so you are saying that you think\nrelative paths in env is not something that is sensible?\n\n> given the discussion in 37a95862c (alternates: re-allow relative\n> paths from environment, 2016-11-07). And they'd probably start with\n> \"../\" as well.\n\nYeah. In any case, there is a potential regression but the chance\nis miniscule---the user has to have been using a relative path that\nbegins with a double-quote in the environment or in alternates file.\n"},{"id":"307652","messageId":"20161213184702.psvwwj4rj6dnknxf@sigill.intra.peff.net","threadId":"44664","inReplyTo":"xmqqbmwf4qn4.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH 0/2] handling alternates paths with colons","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-13T18:47:02Z","receivedAt":"2016-12-13T18:47:31Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Dec 13, 2016 at 10:42:39AM -0800, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > Right, but we also support relative paths via environment variables. I\n> > don't think that changes the conclusion though. I'm not convinced\n> > relative paths via the environment aren't slightly insane in the first\n> > place,\n> \n> Sorry, a triple negation is above my head. \"relative paths in env\n> aren't insane\" == \"using relative paths is OK\" and you are not\n> convinced that it is the case, so you are saying that you think\n> relative paths in env is not something that is sensible?\n\nI think relative paths in env have very flaky semantics which makes them\ninadvisable to use in general. That being said, when we broke even those\nflaky semantics somebody complained. So I consider a feature we _do_\nsupport, but not one I would recommend to people.\n\n-Peff\n"},{"id":"307658","messageId":"d9d2580c-a2e5-d9f3-1f56-6814b2b2285d@kdbg.org","threadId":"44664","inReplyTo":"20161212195355.znqlu44lgnke3ltc@sigill.intra.peff.net","subject":"[PATCH 3/2] t5547-push-quarantine: run the path separator test on Windows, too","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2016-12-13T19:09:31Z","receivedAt":"2016-12-13T19:09:50Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"To perform the test case on Windows in a way that corresponds to the\nPOSIX version, inject the semicolon in a directory name.\n\nTypically, an absolute POSIX style path, such as the one in $PWD, is\ntranslated into a Windows style path by bash when it invokes git.exe.\nHowever, the presence of the semicolon suppresses this translation;\nbut the untranslated POSIX style path is useless for git.exe.\nTherefore, instead of $PWD pass the Windows style path that $(pwd)\nproduces.\n\nSigned-off-by: Johannes Sixt \n---\nAm 12.12.2016 um 20:53 schrieb Jeff King:\n> Johannes, please let me know if I am wrong about skipping the test on\n> !MINGW. The appropriate check there would be \";\" anyway, but I am not\n> sure _that_ is allowed in paths, either.\n\nHere is a version for Windows. I'd prefer this patch on top instead\nof squashing it into yours to keep the $PWD vs. $(pwd) explanation.\n\nThe result is the same as yours in all practical matters; but this\nversion I have already tested.\n\n t/t5547-push-quarantine.sh | 14 ++++++++++----\n 1 file changed, 10 insertions(+), 4 deletions(-)\n\ndiff --git a/t/t5547-push-quarantine.sh b/t/t5547-push-quarantine.sh\nindex 6275ec807b..af9fcd833a 100755\n--- a/t/t5547-push-quarantine.sh\n+++ b/t/t5547-push-quarantine.sh\n@@ -33,8 +33,7 @@ test_expect_success 'rejected objects are removed' '\n \ttest_cmp expect actual\n '\n \n-# MINGW does not allow colons in pathnames in the first place\n-test_expect_success !MINGW 'push to repo path with colon' '\n+test_expect_success 'push to repo path with path separator (colon)' '\n \t# The interesting failure case here is when the\n \t# receiving end cannot access its original object directory,\n \t# so make it likely for us to generate a delta by having\n@@ -43,13 +42,20 @@ test_expect_success !MINGW 'push to repo path with colon' '\n \ttest-genrandom foo 4096 >file.bin &&\n \tgit add file.bin &&\n \tgit commit -m bin &&\n-\tgit clone --bare . xxx:yyy.git &&\n+\n+\tif test_have_prereq MINGW\n+\tthen\n+\t\tpathsep=\";\"\n+\telse\n+\t\tpathsep=\":\"\n+\tfi &&\n+\tgit clone --bare . \"xxx${pathsep}yyy.git\" &&\n \n \techo change >>file.bin &&\n \tgit commit -am change &&\n \t# Note that we have to use the full path here, or it gets confused\n \t# with the ssh host:path syntax.\n-\tgit push \"$PWD/xxx:yyy.git\" HEAD\n+\tgit push \"$(pwd)/xxx${pathsep}yyy.git\" HEAD\n '\n \n test_done\n-- \n2.11.0.55.g6a4dbb1\n\n"},{"id":"307662","messageId":"20161213191245.we6422xpapfgd2gt@sigill.intra.peff.net","threadId":"44664","inReplyTo":"d9d2580c-a2e5-d9f3-1f56-6814b2b2285d@kdbg.org","subject":"Re: [PATCH 3/2] t5547-push-quarantine: run the path separator test on Windows, too","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-13T19:12:45Z","receivedAt":"2016-12-13T19:13:06Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Dec 13, 2016 at 08:09:31PM +0100, Johannes Sixt wrote:\n\n> Am 12.12.2016 um 20:53 schrieb Jeff King:\n> > Johannes, please let me know if I am wrong about skipping the test on\n> > !MINGW. The appropriate check there would be \";\" anyway, but I am not\n> > sure _that_ is allowed in paths, either.\n> \n> Here is a version for Windows. I'd prefer this patch on top instead\n> of squashing it into yours to keep the $PWD vs. $(pwd) explanation.\n> \n> The result is the same as yours in all practical matters; but this\n> version I have already tested.\n\nYeah, I'm happy to have this on top. The patch itself looks obviously\ncorrect. Thanks!\n\n-Peff\n"},{"id":"307664","messageId":"xmqqinqn3a6c.fsf@gitster.mtv.corp.google.com","threadId":"44664","inReplyTo":"d9d2580c-a2e5-d9f3-1f56-6814b2b2285d@kdbg.org","subject":"Re: [PATCH 3/2] t5547-push-quarantine: run the path separator test on Windows, too","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-12-13T19:23:39Z","receivedAt":"2016-12-13T19:27:16Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> To perform the test case on Windows in a way that corresponds to the\n> POSIX version, inject the semicolon in a directory name.\n>\n> Typically, an absolute POSIX style path, such as the one in $PWD, is\n> translated into a Windows style path by bash when it invokes git.exe.\n> However, the presence of the semicolon suppresses this translation;\n> but the untranslated POSIX style path is useless for git.exe.\n> Therefore, instead of $PWD pass the Windows style path that $(pwd)\n> produces.\n>\n> Signed-off-by: Johannes Sixt \n> ---\n> Am 12.12.2016 um 20:53 schrieb Jeff King:\n>> Johannes, please let me know if I am wrong about skipping the test on\n>> !MINGW. The appropriate check there would be \";\" anyway, but I am not\n>> sure _that_ is allowed in paths, either.\n>\n> Here is a version for Windows. I'd prefer this patch on top instead\n> of squashing it into yours to keep the $PWD vs. $(pwd) explanation.\n>\n> The result is the same as yours in all practical matters; but this\n> version I have already tested.\n\nWill queue (I would wait for peff@ to say \"OK\", but I suspect he\nwould be OK in this case).\n\nThanks.\n\n\n> t/t5547-push-quarantine.sh | 14 ++++++++++----\n> 1 file changed, 10 insertions(+), 4 deletions(-)\n>\n> diff --git a/t/t5547-push-quarantine.sh b/t/t5547-push-quarantine.sh\n> index 6275ec807b..af9fcd833a 100755\n> --- a/t/t5547-push-quarantine.sh\n> +++ b/t/t5547-push-quarantine.sh\n> @@ -33,8 +33,7 @@ test_expect_success 'rejected objects are removed' '\n> \ttest_cmp expect actual\n> '\n> \n> -# MINGW does not allow colons in pathnames in the first place\n> -test_expect_success !MINGW 'push to repo path with colon' '\n> +test_expect_success 'push to repo path with path separator (colon)' '\n> \t# The interesting failure case here is when the\n> \t# receiving end cannot access its original object directory,\n> \t# so make it likely for us to generate a delta by having\n> @@ -43,13 +42,20 @@ test_expect_success !MINGW 'push to repo path with colon' '\n> \ttest-genrandom foo 4096 >file.bin &&\n> \tgit add file.bin &&\n> \tgit commit -m bin &&\n> -\tgit clone --bare . xxx:yyy.git &&\n> +\n> +\tif test_have_prereq MINGW\n> +\tthen\n> +\t\tpathsep=\";\"\n> +\telse\n> +\t\tpathsep=\":\"\n> +\tfi &&\n> +\tgit clone --bare . \"xxx${pathsep}yyy.git\" &&\n> \n> \techo change >>file.bin &&\n> \tgit commit -am change &&\n> \t# Note that we have to use the full path here, or it gets confused\n> \t# with the ssh host:path syntax.\n> -\tgit push \"$PWD/xxx:yyy.git\" HEAD\n> +\tgit push \"$(pwd)/xxx${pathsep}yyy.git\" HEAD\n> '\n> \n> test_done\n"},{"id":"307675","messageId":"xmqqoa0f1tg1.fsf@gitster.mtv.corp.google.com","threadId":"44664","inReplyTo":"20161213181538.6gv4it4b33uhbuud@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] tmp-objdir: quote paths we add to alternates","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-12-13T20:10:22Z","receivedAt":"2016-12-13T20:12:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Tue, Dec 13, 2016 at 10:10:04AM -0800, Junio C Hamano wrote:\n>\n>> > -\tgit clone --bare . xxx:yyy.git &&\n>> > +\tgit clone --bare . xxx${path_sep}yyy.git &&\n>> \n>> Don't you want to dq the whole thing to prevent the shell from\n>> splitting this into two commands at ';'? The other one below is OK.\n>\n> After expansion, I don't think the shell will do any further processing\n> except for whitespace splitting. E.g.:\n\nAh, my mistake. Staring at too many `eval`s does it to me.\n\nThanks.\n"},{"id":"307951","messageId":"CACsJy8BuLu+A8UBd4OOzQkcQOsWYo-jDi2+MKgH5ujvOSdOO8Q@mail.gmail.com","threadId":"44664","inReplyTo":"xmqq1sxb66t5.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH 1/2] alternates: accept double-quoted paths","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-12-17T07:56:30Z","receivedAt":"2016-12-17T07:57:06Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Dec 14, 2016 at 1:08 AM, Junio C Hamano wrote:\n> Duy Nguyen writes:\n>\n>> At least attr has the same problem and is going the same direction\n>> [1]. Cool. (I actually thought the patch was in and evidence that this\n>> kind of backward compatibility breaking was ok, turns out the patch\n>> has stayed around for years)\n>>\n>> [1] http://public-inbox.org/git/%3C20161110203428.30512-18-sbeller@google.com%3E/\n>\n> Seeing that again, I see this in the proposed log message:\n>\n> Full pattern must be quoted. So 'pat\"t\"ern attr' will give exactly\n> 'pat\"t\"ern', not 'pattern'.\n>\n> I cannot tell what it is trying to say.\n\nIt's another (bad) way of saying that quoting must start at the\nbeginning (so the closing quote must be at the end of pattern, i.e.\nthe whole pattern is quoted).\n\n> The log message may need to be cleaned up.\n\nYeah. Next time I'll write more or less \"Look at Jeff's commit, this\nis basically it\" when Stephan re-rolls sb/attr\n-- \nDuy\n"},{"id":"308222","messageId":"00b6235d-c1bc-30c2-6539-6c78c4ce9eb0@kdbg.org","threadId":"44664","inReplyTo":"d9d2580c-a2e5-d9f3-1f56-6814b2b2285d@kdbg.org","subject":"[PATCH 4/2] t5615-alternate-env: double-quotes in file names do not work on Windows","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2016-12-21T21:33:43Z","receivedAt":"2016-12-21T21:34:01Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Protect a recently added test case with !MINGW.\n\nSigned-off-by: Johannes Sixt \n---\n I don't remember why I did not notice this failure sooner.\n Perhaps I did, but then ran out of time to debug it...\n\n The patch should go on top of jk/quote-env-path-list-component.\n\n t/t5615-alternate-env.sh | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/t/t5615-alternate-env.sh b/t/t5615-alternate-env.sh\nindex 69fd8f8911..26ebb0375d 100755\n--- a/t/t5615-alternate-env.sh\n+++ b/t/t5615-alternate-env.sh\n@@ -79,7 +79,7 @@ test_expect_success 'mix of quoted and unquoted alternates' '\n \t$two blob\n '\n \n-test_expect_success 'broken quoting falls back to interpreting raw' '\n+test_expect_success !MINGW 'broken quoting falls back to interpreting raw' '\n \tmv one.git \\\"one.git &&\n \tcheck_obj \\\"one.git/objects <<-EOF\n \t$one blob\n-- \n2.11.0.79.gf6b77ca\n\n"},{"id":"308226","messageId":"20161221224222.6fn6irefmd6li6oa@sigill.intra.peff.net","threadId":"44664","inReplyTo":"00b6235d-c1bc-30c2-6539-6c78c4ce9eb0@kdbg.org","subject":"Re: [PATCH 4/2] t5615-alternate-env: double-quotes in file names do not work on Windows","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-21T22:42:22Z","receivedAt":"2016-12-21T22:45:56Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Dec 21, 2016 at 10:33:43PM +0100, Johannes Sixt wrote:\n\n> Protect a recently added test case with !MINGW.\n> \n> Signed-off-by: Johannes Sixt \n> ---\n> I don't remember why I did not notice this failure sooner.\n> Perhaps I did, but then ran out of time to debug it...\n> \n> The patch should go on top of jk/quote-env-path-list-component.\n> [...]\n> -test_expect_success 'broken quoting falls back to interpreting raw' '\n> +test_expect_success !MINGW 'broken quoting falls back to interpreting raw' '\n> \tmv one.git \\\"one.git &&\n> \tcheck_obj \\\"one.git/objects <<-EOF\n> \t$one blob\n\nHmph. I explicitly avoided a colon in the filename so that it would run\non MINGW. Is a double-quote also not allowed?\n\n-Peff\n"},{"id":"308239","messageId":"4e66fba1-d881-6a96-1e4d-da9c897353ac@kdbg.org","threadId":"44664","inReplyTo":"20161221224222.6fn6irefmd6li6oa@sigill.intra.peff.net","subject":"Re: [PATCH 4/2] t5615-alternate-env: double-quotes in file names do not work on Windows","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2016-12-22T06:13:08Z","receivedAt":"2016-12-22T06:13:14Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 21.12.2016 um 23:42 schrieb Jeff King:\n> On Wed, Dec 21, 2016 at 10:33:43PM +0100, Johannes Sixt wrote:\n>\n>> Protect a recently added test case with !MINGW.\n>>\n>> Signed-off-by: Johannes Sixt \n>> ---\n>> I don't remember why I did not notice this failure sooner.\n>> Perhaps I did, but then ran out of time to debug it...\n>>\n>> The patch should go on top of jk/quote-env-path-list-component.\n>> [...]\n>> -test_expect_success 'broken quoting falls back to interpreting raw' '\n>> +test_expect_success !MINGW 'broken quoting falls back to interpreting raw' '\n>> \tmv one.git \\\"one.git &&\n>> \tcheck_obj \\\"one.git/objects <<-EOF\n>> \t$one blob\n>\n> Hmph. I explicitly avoided a colon in the filename so that it would run\n> on MINGW. Is a double-quote also not allowed?\n\nIt is not allowed; that was my conclusion. But now that you ask, I'll \ndouble-check.\n\n-- Hannes\n\n"},{"id":"308259","messageId":"54ba9cff-b6f7-7660-261f-393cd5181da6@kdbg.org","threadId":"44664","inReplyTo":"4e66fba1-d881-6a96-1e4d-da9c897353ac@kdbg.org","subject":"Re: [PATCH 4/2] t5615-alternate-env: double-quotes in file names do not work on Windows","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2016-12-22T19:06:02Z","receivedAt":"2016-12-22T19:06:11Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 22.12.2016 um 07:13 schrieb Johannes Sixt:\n> Am 21.12.2016 um 23:42 schrieb Jeff King:\n>> Hmph. I explicitly avoided a colon in the filename so that it would run\n>> on MINGW. Is a double-quote also not allowed?\n>\n> It is not allowed; that was my conclusion. But now that you ask, I'll\n> double-check.\n\nOk, the point is that I get this error:\n\nmv: cannot move `one.git' to `\"one.git'\n\nI don't feel inclined to find out which of 'mv' or the Windows API or \nthe NTFS driver prevents the double-quotes and come up with a \nwork-around just to get the test to run in some form. Let's leave it at \nthe !MINGW prerequisite.\n\n-- Hannes\n\n"},{"id":"308269","messageId":"alpine.DEB.2.20.1612222237530.155951@virtualbox","threadId":"44664","inReplyTo":"54ba9cff-b6f7-7660-261f-393cd5181da6@kdbg.org","subject":"Re: [PATCH 4/2] t5615-alternate-env: double-quotes in file names do not work on Windows","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-12-22T21:38:44Z","receivedAt":"2016-12-22T21:39:07Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Hannes,\n\nOn Thu, 22 Dec 2016, Johannes Sixt wrote:\n\n> Am 22.12.2016 um 07:13 schrieb Johannes Sixt:\n> > Am 21.12.2016 um 23:42 schrieb Jeff King:\n> > > Hmph. I explicitly avoided a colon in the filename so that it would\n> > > run on MINGW. Is a double-quote also not allowed?\n> >\n> > It is not allowed; that was my conclusion. But now that you ask, I'll\n> > double-check.\n> \n> Ok, the point is that I get this error:\n> \n> mv: cannot move `one.git' to `\"one.git'\n> \n> I don't feel inclined to find out which of 'mv' or the Windows API or\n> the NTFS driver prevents the double-quotes and come up with a\n> work-around just to get the test to run in some form. Let's leave it at\n> the !MINGW prerequisite.\n\nDouble-quotes are not allowed in file names in Windows. NTFS would allow\nthem just fine.\n\nCiao,\nDscho\n"},{"id":"308276","messageId":"20161222221912.2q722cnrl2hnz6pi@sigill.intra.peff.net","threadId":"44664","inReplyTo":"54ba9cff-b6f7-7660-261f-393cd5181da6@kdbg.org","subject":"Re: [PATCH 4/2] t5615-alternate-env: double-quotes in file names do not work on Windows","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-22T22:19:12Z","receivedAt":"2016-12-22T22:19:19Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Dec 22, 2016 at 08:06:02PM +0100, Johannes Sixt wrote:\n\n> Am 22.12.2016 um 07:13 schrieb Johannes Sixt:\n> > Am 21.12.2016 um 23:42 schrieb Jeff King:\n> > > Hmph. I explicitly avoided a colon in the filename so that it would run\n> > > on MINGW. Is a double-quote also not allowed?\n> > \n> > It is not allowed; that was my conclusion. But now that you ask, I'll\n> > double-check.\n> \n> Ok, the point is that I get this error:\n> \n> mv: cannot move `one.git' to `\"one.git'\n> \n> I don't feel inclined to find out which of 'mv' or the Windows API or the\n> NTFS driver prevents the double-quotes and come up with a work-around just\n> to get the test to run in some form. Let's leave it at the !MINGW\n> prerequisite.\n\nThank you for double-checking (and sorry if my initial question was\nconfusing; I somehow missed the mention of dq in your subject line, and\njust read the message body).\n\nYour patch seems like the best solution.\n\n-Peff\n"}]}