On Thu, Jul 16, 2020 at 11:03:22AM +0000, Paul D. Smith wrote: > I believe there is a subtle bug in Git that can mean that a "git add" fails, complaining that "fatal: <filename>: '<filename>' is outside repository at '//<server>/<share>/<directory> /' > > It may be possible to reproduce this with simpler steps, but this is what I have that fails. > > 1. A Git repo on system <server> below directory <directory> that can be reached via the Windows share <share> > 2. On a second system, perform "net use z: file://%3cserver%3e/%3cshare>" > 3. Now you can "cd /d z:\<directory>" and run "git status" quite happily > 4. At this point I can also so this: > a. "cd /d z:" then "git add <z:\some-changed-file>" > i. Note the drive letter prefixing the full-filename > 5. Now do a subst or a net use as follows: > a. subst v: z:\directory > b. net use w: file://%3cserver%3e/%3cshare%3e/%3cdirectory> > 6. You can do both of these > a. "cd /d v:" then "git status" > b. "cd /d w:" then "git status" > 7. However both of these FAIL: > a. "cd /d v:" then "git add <v:\some-changed-file>" > b. "cd /d w:" then "git add <w:\some-changed-file>" > i. Note the drive letter prefixing the full-filename > 8. Performing the above requests WITHOUT the drive letter prefixing the filename works! > > I assume that this is supposed to work and there is some subtle error merging the repository root and the filename-with-drive-prefix. > > Regards, > Paul D.Smith. > Thanks for reporting your issue. It's good to get well-written reports like this. As a general note, this is specific to the "Git for Windows" project, and issues can be reported there: https://github.com/git-for-windows/git More specific, I could reproduce the issue without using a network: C: cd Users/tb mkdir 200719-git-test-subst cd 200719-git-test-subst git init echo FILE >FILE.txt Now I can use git add C:\Users\tb\200719-git-test-subst\FILE.txt That surborised me a little bit, since an absolute path name was given to Git. However, Git is able to figure out, that C:\Users\tb\200719-git-test-subst\FILE.txt is the same as FILE.txt as you can see running git ls-files The file names (and path components) in Git are always tracked "relative". Relative to the root of the Git repo. And here Git translates "C:\Users\tb\200719-git-test-subst\FILE.txt" into "FILE.txt" In that sense, drive letters are not trackesd at all, you can clone that repo to any drive letter, or even to a network share. If I now use subst T: C:\Users\tb\200719-git-test-subst I can use the same repo under T:\ file/path names are still relative, so if you change into T:\ and run git ls-files you will still see FILE.txt Now mixing those 2 does not work. Git is unable to figure out the "T:\" is the same as "C:\Users\tb\200719-git-test-subst" In general, different drive letters host different file systems, so Git assumes that they don't point to the same directory. Adding this functionality may be possible, I don't know the Windows APIs good enough. But: That will cost sone time (in terms of development) and give a run-time penalty for Git itself for many Git invocations. It may even open up for security issues, since the "check if X: is the same as Y:" needs to be done in one step, and the the operation needs to be done in the next step, opening a small timing window, where bad things may happen. This was my limited view on how things work, there may be details missed (or wrong).
