On Sat, Nov 07, 2015 at 01:45:27PM -0500, Jeff King wrote:
> On Sat, Nov 07, 2015 at 12:11:29PM +0000, Adam Dinwoodie wrote:
>
> > Specifically, I'm seeing t5813 subtests 9-13 and 15-19 failing. This happens
> > with a clean build straight from the Git source tree (git clean -dfx && make
> > configure && ./configure && make && cd t && ./t5813-proto-disable-ssh.sh) as
> > well as builds using the Cygwin packaging paraphernalia.
>
> What does the output of "./t5813-proto-disable-ssh.sh -v -i" show?
>
> It seems strange that it would fail only on Cygwin; this code doesn't
> really use any platform-dependent features. It's also weird that it
> fails _only_ for ssh, and _only_ on the tests that are using "ssh://"
> URLs are not "host:path" syntax.
Ah! I thought I'd checked that already, but looking at the output now I
can see what's going wrong. Cutting down to the relevant error:
ssh: remote git-upload-pack '//home/Adam/vcs/Cygwin-Git/git-2.6.2-1.x86_64/build/t/trash directory.t5813-proto-disable-ssh/remote/repo.git' fatal: '//home/Adam/vcs/Cygwin-Git/git-2.6.2-1.x86_64/build/t/trash directory.t5813-proto-disable-ssh/remote/repo.git' does not appear to be a git repository
Note the '//' at the start of the path -- on most *nix systems '//' is
effectively identical to '/'. On Cygwin, however, '//' is used to
access Windows UNC paths: what Windows calls "\\server\share", Cygwin
calls "//server/share". If you replace the '//' with '/' you get the
locatoin of the repository; but here Cygwin is looking for the
repository in a share called "Adam" on a network server called "home"...
I suspect the correct fix here is to fix whatever's causing Git to
generate a path with that '//'. If nobody else gets to it soon
(probably on the order of a week before I'll get the chance), I'll go
code diving and submit a patch.
> I tried building on Linux with the Cygwin build knobs found in
> config.mak.uname, but I couldn't get it to fail. I also wondered if the
> test was doing something with the shell that might not be portable, but
> I don't see anything interesting.
If I recall correctly, the correct interpretation of '//' isn't defined
in POSIX, so whatever's causing that path to be generated is the bit
that's not fully portable. It looks as though t5813 throwing this up is
just a coincidence rather than it being particularly related to the
function those tests are actually testing.
Adam
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html