Re: Possible git bug when working with Microsoft Mapped drives

> Could you maybe create an issue against GFW for this so that we don't
> forget about it?
>
> https://github.com/git-for-windows/git/issues
>
> Jeff
>
>
> On 7/18/22 5:55 PM, Paul Kinzelman wrote:
>> Thank you! Jeff was right on, but I didn't want to create extra noise
>> on the elist, so I replied just to him.
>>
>> His suggestion of the --no-hardlinks
>> caused it to work!
>>
>> Might be good to test to see if a drive letter is on a remote system
>> and do that automagically.
>>
>> On 7/18/2022 3:38 PM, brian m. carlson wrote:
>>> On 2022-07-18 at 20:46:44, Jeff Hostetler wrote:
>>>> On 7/18/22 4:28 PM, Paul Kinzelman wrote:
>>>>> I'm using git version 2.37.1.windows.1 and Windows 10
>>>>>
>>>>> I've got two systems which are miles apart and so are not on the same
>>>>> LAN, and I have connected them together using the ui.com VPN and M$
>>>>> RDP/TSclient. I mapped each system's C: drive to be accessed by the
>>>>> other system as Drive X: and I can transfer files back and forth
>>>>> initiated on each system.
>>>>>
>>>>> I can also see all the repository files on the source system, 
>>>>> including
>>>>> the tree of files under the .git directory. Note I had to unhide the
>>>>> .git folder so that I could see that folder from the other system.
>>>>>
>>>>> However, when I run 'git clone' on one system to get the 
>>>>> repository from
>>>>> the other system, git seems to think the repository on the other
>>>>> system is empty when it's not. As I said, I can even do a directory
>>>>> and see all the other files.
>>>> I can't duplicate your setup, so I'll just speculate out loud
>>>> here.  I have to wonder if the "X:" drive letters are tricking
>>>> Git to thinking that the remote instance is actually local and
>>>> Git is trying to use some shortcuts. (For example, it might
>>>> hardlink them rather than copy them on Linux.)
>>>>
>>>> So I'm wondering if "--no-local" or "--no-hardlinks" or using
>>>> a file URL rather than a pathname might make it behave differently.
>>> It may also be the case that the remote file system lacks some
>>> functionality that Git needs.  For example, Windows can support mapping
>>> HTTP DAV resources as drives, but the DAV protocol is incapable of
>>> providing certain operations that Git expects of a file system (Git
>>> roughly needs something that's POSIX compliant, but can paper over case
>>> insensitivity) and thus such a disk simply can't work with Git.
>>>
>>> This may end up looking like the file system is empty because, for
>>> example, the function to query directory contents may return an error.
>>> The contents may not actually be empty, but because they cannot be
>>> enumerated in the way Git needs them to be, it appears that way.
>>>
>>> Again, I don't know if this is the case here, but you're the second
>>> person recently to have seen problems with using RDP for this purpose.
>>> You may wish to try SFTP, which should work (at least it does for Unix
>>> systems), or possibly SMB/CIFS (which may or may not work, but I 
>>> believe
>>> it typically does).
>>