Re: [PATCH v1/RFC 1/1] 'git clone <url> C:\cygwin\home\USER\repo' is working (again)

From: Steven Penny <svnpenn@gmail.com>
Date: Nov 27, 2018, 06:20 UTC
Message-ID: <CAAXzdLWtDw09umyr23qZkv2jQ6_mTeFXbktgb-f6S2w6Zf1Egg@mail.gmail.com>
In-Reply-To: <xmqqlg5ft7pe.fsf@gitster-ct.c.googlers.com>

On Mon, Nov 26, 2018 at 11:23 PM Junio C Hamano wrote:

Show 6 quoted lines

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

while it is true that "C:" and similar do not have a bearing on a path being absolute versus relative, it does have a bearing on what drive the entry is to be found.

That is to say "C:\tmp\file.txt" does not equal "D:\tmp\file.txt".

Starting with an absolute path like "C:\tmp\file.txt", after stripping that would yield "\tmp\file.txt" or "/tmp/file.txt". Starting with a relative path like "C:tmp\file.txt", after stripping that would yield "tmp\file.txt" or "tmp/file.txt".

However in all cases we have lost the concept of what drive the file is located on, and Windows will assume the file exists on the current drive.

So I would expect "git clone URL D:\tmp" to fail if the current directory is on "C:". Upon testing cross drive clones work fine though with this patch, so maybe the drive is added back at another place in the code.