On Sat, Dec 10, 2016 at 10:29:28AM +0100, Klaus Ethgen wrote:
> > 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.
Sure, it's allowed, but it will cause problems due to other syntactic
conventions. Try putting "/usr/path:with:colons" into your $PATH
variable, for instance. Try rsyncing "xxx:yyy.git" somewhere.
Git does have heuristics for figuring out the difference between
"host:repo.git" as an SSH remote versus a local path, but they're not
foolproof.
> 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.
Sort of. This has always been a problem with the variables Junio
mentioned. The change in v2.11 is that the alternates subsystem is being
used in some cases where it wasn't before, which is surfacing this
limitation in more places.
> > 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?
Because the new quarantine feature[1] is built on top of the existing
alternates mechanism, which can have several sources.
I do think we should address this as a regression, but I think repo
names with colons are always going to suffer from some corner cases.
-Peff
[1] See 25ab004c5 and the commits leading up to it for more discussion
of what the new feature is, if you're curious.