Re: [PATCH v1/RFC 1/1] 'git clone <url> C:\cygwin\home\USER\repo' is working (again)
From: Junio C Hamano <hidden>
Date: 2018-11-27 05:23:17
Steven Penny [off-list ref] writes:
If you strip the drive, you can still navigate within the same drive:
$ cd 'C:\Users'
$ pwd
/cygdrive/c/Users
$ cd '\Windows'
$ pwd
/cygdrive/c/Windows
but you can no longer traverse drives:
$ cd '\Testing'
sh: cd: \Testing: No such file or directory
Sorry, but I fail to see the point the last example wants to make.
If it were
$ cd /cygdrive/d/Testing
$ cd /cygdrive/c/Users
$ cd ../../d/Testing
and the last step fails, then I would suspect it would make sense to
treat /cygdrive/$X exactly like how we would treat $C:, because
$ cd C:Users
$ cd ../D:Testing
would not make sense, either, which is an indication that these two
are quite similar. On the other hand, if "cd ../../d/Testing" above
does not fail and does what non-DOS users would expect, then that
strongly argues that treating /cygdrive/$X any specially is a mistake.
So a good first question for me would be: why are we stripping "C:" or similar in the first place?
Sorry, but I do not see the connection to this question and the above example. The reason why we strip C: is because the letter that comes after that colon determines if we are talking about absolute path (in other words, the current directory does not play a role in determining which directory the path refers to), unlike the POSIX codepath where it is always the first letter in the pathname. C:\Users is a directory whose name is Users at the top level of the C: drive. C0\Users tells us that in the current directory, there is a directory whose name is C0 and in it, there is a filesystem entity whose name is Users. So the colon that follows an alpha (in this case, C:) is quite special, compared to other letters (in this example, I used '0' to contrast its effect with ':'). So it is very understandable why we want to have has_dos_prefix() and skip_dos_prefix().
I would say these could be merged into a "win.h" or similar. Cygwin typically leans toward the "/unix/style" while MINGW has been more tolerant of "C:\Windows\Style" and "C:/Mixed/Style" paths, i dont see that changing.
I'd defer to Windows folks to decide if a unified win.h is a good idea. Thanks.