Re: [BUG] Colon in remote urls

From: Klaus Ethgen <klaus@ethgen.ch>
Date: Dec 10, 2016, 09:29 UTC
Message-ID: <20161210092928.jkaf2rwxhicafmxr@ikki.ethgen.ch>
In-Reply-To: <xmqqwpf8rkeq.fsf@gitster.mtv.corp.google.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello,

Am Fr den  9. Dez 2016 um 20:07 schrieb Junio C Hamano:

Show 9 quoted lines

> 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.

That is the first I hear and I really wonder about.

A colon a perfectly allowed character in POSIX filesystems.

Moreover, it was no problem before and was introduced as a problem just in that version. Even more, a pull (and so a clone I believe) of such a path is absolutely ok. Just the push fails.

Show 7 quoted lines

> > 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.

As I quote above, a colon is perfect common in POSIX filesystems. A backslash is at least uncommon and always needed to quote as it, most often, has special meaning to os/shell.

I cannot see why a tool (as git is) should decide what characters are "bad" and what are "good". If the filesystem beneath supports it...

By the way, I didn't find anywhere in git documentation that there are "bad" chars around.

Show 11 quoted lines

> 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.

I didn't get it, why is there a need to split? I mean, it is not possible to push to two locations at the same time, so why is there splitting at all?

Regards
   Klaus
- -- 
Klaus Ethgen                                       http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16            Klaus Ethgen <Klaus@Ethgen.ch>
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-----BEGIN PGP SIGNATURE-----
Comment: Charset: ISO-8859-1

iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAlhLyvIACgkQpnwKsYAZ 9qyBzgv9EzMEWrEgsTd1Z0gjpzpJlhpO8R2I7H4mGvEjlxoTXtUNwjvM+ojAYzaI F34IBRv9BCha+h7I6ccoaAsfmurz73lA1AKy1IFPrYAoxompYLomC9exY+8+ggdN G2uVbMTmiL+CxJGo0ItxmiQCcv7himVoyto70Dekc7se+panbzCq/vG4+Rz7pwRn sWnlKs0tQomi6QXbibo8992v4ECkAXzE2Xc/l5DvosSwNNPsqgdeeiNHEMDTbQq8 jqencfOruCfyMnQ0ejCaTWNbYY5SVUtfWikwta12jB06D1BgHTCRVKZCfhoHJx5+ Ffqj8uuiCJuZGQcopzJWiYU5X+SUHz7Ya+iA3VQOxNEKsGAZgq6QQqDcd0y9fyPt pzMAYo26GRioDiuQZzZ4CzA5eC0wWozv3oESsKLD5RsbWHV/9ODbpr7lHMW2TmUp H2vZhre1K/ZX2bODQByJoRNtDUqKvZmI6GsbXrvRAFKF4aCLByFIgcrZprmj++DH jlb25tjq =jOGb -----END PGP SIGNATURE-----