Re: Same test-path-utils behaves differently on different Windows systems

2013-10-10 Thread Sebastian Schuberth
Hi again,

the problem can also be reproduced in an easier way, independently of
mingwGitDevEnv and using the mingw_path function instead of
relative_path. If I install msysGit 1.8.4 from [1] and run
test-path-utils I get this on Windows Server 2008 R2 64-bit:

$ test-path-utils mingw_path /a/b/
a:/b/

But if I install [1] on my local Windows 8 64-bit I get:

$ test-path-utils mingw_path /a/b/
C:/msysgit/msysGit/a/b/

So the only obvious thing that changed is the Windows version, but I
find it hard to believe that this influences MSYS path mangling.

[1] 
http://msysgit.googlecode.com/files/msysGit-fullinstall-1.8.4-preview20130916.exe

-- 
Sebastian Schuberth


On Thu, Oct 10, 2013 at 2:13 PM, Sebastian Schuberth
sschube...@gmail.com wrote:

 Hi,

 for my mingwGitDevEnv project [1] I'm currently looking at the failing
 Git tests [2]. The first tests that fails is t0060-path-utils [3]:

 not ok 88 - relative path: / /a/b/ = ../../
 # test $(test-path-utils relative_path '/' '/a/b/') = '../../'

 not ok 91 - relative path: /x/y /a/b/ = ../../x/y
 # test $(test-path-utils relative_path '/x/y' '/a/b/') = '../../x/y'

 If I run test-path-utils relative_path '/' '/a/b/' on the server
 (running Windows Server 2008 R2) that perform the testing I indeed
 get:

 $ test-path-utils relative_path '/' '/a/b/'
 ../../C:/Jenkins/mingwGitDevEnv-test/workspace/mingwGitDevEnv
 $ pwd -W
 C:/Jenkins/mingwGitDevEnv-test/workspace/mingwGitDevEnv/git

 The funny thing is, if I run the exact same binary on my local Windows
 8 64-bit machine I get the expected result:

 $ test-path-utils relative_path '/' '/a/b/'
 ../../
 $ pwd -W
 C:/Jenkins/mingwGitDevEnv-test/workspace/mingwGitDevEnv/git

 So how can the exact same test-path-utils binary create different
 results fo the same arguments? I'd be very grateful for any insights.
 If you want to play around with it yourself, you can download the
 while Jenkins workspace as a ZIP at [4] (but note that it's almost 1
 GiB).

 It's probably also interesting to mention that t0060-path-utils did
 not yet fail in build 38 [5] and I'm currently in the process to find
 out what changed.

 [1] https://github.com/sschuberth/mingwGitDevEnv/
 [2] http://mingwgitdevenv.cloudapp.net/job/mingwGitDevEnv-test/42/
 [3] 
 http://mingwgitdevenv.cloudapp.net/job/mingwGitDevEnv-test/ws/test-results/t0060-path-utils.sh/*view*/
 [4] 
 http://mingwgitdevenv.cloudapp.net/job/mingwGitDevEnv-test/ws/mingwGitDevEnv/
 [5] http://mingwgitdevenv.cloudapp.net/job/mingwGitDevEnv-test/38/

 --
 Sebastian Schuberth
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Same test-path-utils behaves differently on different Windows systems

2013-10-10 Thread Johannes Sixt
Am 10.10.2013 17:52, schrieb Sebastian Schuberth:
 Hi again,
 
 the problem can also be reproduced in an easier way, independently of
 mingwGitDevEnv and using the mingw_path function instead of
 relative_path. If I install msysGit 1.8.4 from [1] and run
 test-path-utils I get this on Windows Server 2008 R2 64-bit:
 
 $ test-path-utils mingw_path /a/b/
 a:/b/
 
 But if I install [1] on my local Windows 8 64-bit I get:
 
 $ test-path-utils mingw_path /a/b/
 C:/msysgit/msysGit/a/b/

Interesting. I guess that you get consistent behavior when the first
path component is not merely a single letter, e.g., /foo/bar.

Do you have a drive a: configured somewhere in your MSYS environment on
the 2k8r2 machine? See /etc/fstab. Do you have a floppy drive in that
machine?

-- Hannes

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Same test-path-utils behaves differently on different Windows systems

2013-10-10 Thread Sebastian Schuberth
On Thu, Oct 10, 2013 at 7:57 PM, Johannes Sixt j...@kdbg.org wrote:

 test-path-utils I get this on Windows Server 2008 R2 64-bit:

 $ test-path-utils mingw_path /a/b/
 a:/b/

 But if I install [1] on my local Windows 8 64-bit I get:

 $ test-path-utils mingw_path /a/b/
 C:/msysgit/msysGit/a/b/

 Interesting. I guess that you get consistent behavior when the first
 path component is not merely a single letter, e.g., /foo/bar.

You're right! With /foo/bar on W2k8r2 I get

$ test-path-utils mingw_path /foo/bar/
C:/msysgit184/msysgit/foo/bar/

 Do you have a drive a: configured somewhere in your MSYS environment on
 the 2k8r2 machine? See /etc/fstab. Do you have a floppy drive in that
 machine?

Again you're correct. The W2k8r2 machine actually is a VM, providing a
floppy drive A:. So the obvious thing would be to replace /a/b/ with
/foo/bar/ in the tests, but that just masks the problem, or?

PS: I'm also quite unhappy about naming the function mingw_path. The
path mangling comes from MSYS, not MinGW, so if at all it should be
named msys_path. But as the code for the mingw_path function does
nothing either MSYS or MinGW related but just prints argv[2] as it was
passed to main() it should probably simply called print_path.

-- 
Sebastian Schuberth
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Same test-path-utils behaves differently on different Windows systems

2013-10-10 Thread Johannes Sixt
Am 10.10.2013 21:47, schrieb Sebastian Schuberth:
 So the obvious thing would be to replace /a/b/ with
 /foo/bar/ in the tests, but that just masks the problem, or?

The strange behavior is not a problem in Git, it is a problem of MSYS.
Using /foo/bar instead of /a/b in Git's test suite is a reasonable
work-around.

If you mean that you get ../../C:/something from the relative_path
computation, that *is* a problem in Git, which is addressed by the topic
jx/relative-path-regression-fix.

 PS: I'm also quite unhappy about naming the function mingw_path. The
 path mangling comes from MSYS, not MinGW, so if at all it should be
 named msys_path. But as the code for the mingw_path function does
 nothing either MSYS or MinGW related but just prints argv[2] as it was
 passed to main() it should probably simply called print_path.

You have a point here. If it were to change, echo_path would be my
preference.

-- Hannes

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Same test-path-utils behaves differently on different Windows systems

2013-10-10 Thread Sebastian Schuberth
On Thu, Oct 10, 2013 at 10:04 PM, Johannes Sixt j...@kdbg.org wrote:

 So the obvious thing would be to replace /a/b/ with
 /foo/bar/ in the tests, but that just masks the problem, or?

 The strange behavior is not a problem in Git, it is a problem of MSYS.
 Using /foo/bar instead of /a/b in Git's test suite is a reasonable
 work-around.

 If you mean that you get ../../C:/something from the relative_path
 computation, that *is* a problem in Git, which is addressed by the topic
 jx/relative-path-regression-fix.

Thanks for pointing out that topic to me. As it turn out, it already
has a commit to use /foo/bar instead of /a/b [1]. However, it again
mixes up MSYS with MinGW in several places. I'll reply to the patch
mails.

[1] 
https://github.com/gitster/git/commit/15b0ae73520895caffc2eb65732dbf618fb22c62

-- 
Sebastian Schuberth
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Same test-path-utils behaves differently on different Windows systems

2013-10-10 Thread Sebastian Schuberth
On Thu, Oct 10, 2013 at 10:04 PM, Johannes Sixt j...@kdbg.org wrote:

 PS: I'm also quite unhappy about naming the function mingw_path. The
 path mangling comes from MSYS, not MinGW, so if at all it should be
 named msys_path. But as the code for the mingw_path function does
 nothing either MSYS or MinGW related but just prints argv[2] as it was
 passed to main() it should probably simply called print_path.

 You have a point here. If it were to change, echo_path would be my
 preference.

I'll stick to print_path as it more closely resembles pwd, *print*
working directory.

-- 
Sebastian Schuberth
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html