Git 无法与 Ubuntu → Windows Samba 共享目录一起工作

我正在运行 Virtual Box Ubuntu VM，在其中设置了 git 存储库。然后我使用Samba创建一个共享文件夹并在smb.conf中进行以下配置

path = /home/allan/git_repo
valid users = allan
read only = no
hide dot files = no

当我导航到适当的网络位置时（\\192.168.65.101\git_repo）我在那里看到了我的所有文件和文件夹，包括我的 .git 文件夹，它似乎包含我需要的所有内容。

如果我导航到 bash 终端 (MINGW64) 中的网络位置，我发现它不被识别为 git 存储库。一个简单的命令，例如git rev-parse HEAD回报fatal: Not a git repository (or any of the parent directories): .git另一方面，向下导航子目录级别会导致某种识别（例如，我可以运行git rev-parse HEAD并得到有效的响应）。不过，有很多功能需要位于上层目录，所以我很困惑发生了什么以及如何解决这个问题。

确保不要在中执行 git 命令.git文件夹本身。

如果应该在父文件夹中执行.git/.

另外，请确保使用适用于 Windows 的最新版本的 Git，因为它有更好的支持\\... path.
也可以看看 ”git 尝试统计//HEAD搜索存储库时，导致 Cygwin 出现巨大延迟".

Git 2.24（2019 年第 4 季度）将认识到，在 Windows 上，现在允许像任何其他目录一样使用 UNC 共享的根级别。

See commit 5cf7b3b, commit e2683d5, commit d17f212 (24 Aug 2019) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit b57a88a, 30 Sep 2019)}

setup_git_directory()：正确处理UNC根路径

在文件共享的根目录中工作时（这仅在 Git Bash 和 Powershell 中可行，但在 CMD 中不行），报告当前目录时不带尾部斜杠。

这与 Unix 和标准 Windows 目录不同：两者/ and C:\以尾部斜杠报告为当前目录。

如果 Git 工作树位于那里，Git 还没有做好准备：
虽然它确实设法找到.git目录/文件，它返回顶级目录路径的长度one more比当前目录的长度，以及setup_git_directory_gently()那么会 返回未定义的字符串作为前缀。

实际上，这个未定义的字符串通常指向NUL字节，并不会造成太大伤害。不过，在真正涉及重现的极少数情况下（而且不可靠），报告的前缀可能是 Git 执行路径的后缀字符串。

进一步来说，git-for-windows/git第1320期报道git statusWindows 共享根目录下的 UNC 路径失败。

fatal: Not a git repository (or any of the parent directories): .git

Fix .git/UNC 共享根部的发现

Git 源代码库中一个非常常见的假设是offset_1st_component()对于相对路径返回 0，对于相对路径返回 1 以斜线开头的绝对路径。
换句话说，返回值要么是 0，要么是 dir 分隔符后面的点。

调用时不满足此假设offset_1st_component()例如在 Windows 上的 UNC 路径上，例如”//my-server/my-share".
在这种情况下，offset_1st_component()返回整个字符串的长度（这是正确的，因为剥离最后一个“组件”不会导致 有效目录），但返回值仍然不指向紧随dir分隔器。

这种假设最明显地体现在setup_git_directory_gently_1()函数，我们要在其中附加一个“.git" 组件并简单地假设已经有一个 dir 分隔符。
在上面给出的 UNC 示例中，这种假设是不正确的。

因此，Git 将无法处理 UNC 顶部的工作树 正确分享。

让我们通过专门针对这种情况添加一个目录分隔符来解决这个问题： 发现路径中没有第一个组件并且没有结束 在目录分隔符中？然后添加它。