Re: [BUG] Colon in remote urls

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 9, 2016, 19:07 UTC
Message-ID: <xmqqwpf8rkeq.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20161209152219.ehfk475vdg4levop@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

> (One other option is to just declare that the quarantine feature doesn't
> work with colons in the pathname, but stop turning it on by default. I'm
> not sure I like that, though).

I think we long time ago in 2005 have declared that a colon in a directory name would not work for Git repositories because of things like GIT_CEILING_DIRECTORIES, GIT_ALTERNATE_OBJECT_DIRECTORIES; so I do not think we terribly mind that direction.

> Here's a rough idea of what the quoting solution could look like. It
> should make your case work, but I'm not sure what we want to do about
> backwards-compatibility, if anything.

Yes, obviously it robs from those with backslash in their pathnames to please those with colons; we've never catered to the latter, so I am not sure if the trade-off is worth it.

I can see how adding a new environment variable could work, though. A naive way would be to add GIT_ALT_OBJ_DIRS that uses your quoting when splitting its elements, give it precedence over the existing one (or allow to use both and take union as the set of alternate object stores) and make sure that the codepaths we use internally uses the new variable. But if the quarantine codepath will stay to be the only user of this mechanism (and I strongly suspect that will be the case), the new environment could just be pointing at a single directory, i.e. GIT_OBJECT_QUARANTINE_DIRECTORY, whose value is added without splitting to the list of alternate object stores, and the quarantine codepath can export that instead.