Re: Possible git bug when working with Microsoft Mapped drives

[Jeff Hostetler <git@jeffhostetler.com>]

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