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