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). -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
