Git：无法创建符号链接（文件名太长）

Question

我已经将一个项目从 Linux 推送到 Bitbucket，然后将其克隆到 Windows 上。 原来有两个符号链接，在 Windows 上显示为文本文件。 因为我知道它们应该指向哪里，所以我用它们的目标文件副本替换它们，提交并推送。

现在，当我从他们的 Web 界面查看 Bitbucket 存储库时，它看起来还不错。 然而，我的 Unix 机器上的 git clone 给了我两条消息，例如：

error: unable to create symlink ... (File name too long)

并且以前是符号链接的两个文件不存在。 我尝试克隆到 /tmp/... 以获得更短的文件名，但得到了相同的结果。 这表明，Bitbucket 存储库出了点问题。 我尝试打开和关闭core.symlinks 。

我可以在没有符号链接的情况下生活，但我希望有一个工作存储库。 有没有人知道一种方法（除了重新创建存储库）？

Answer 1

这是一个不需要您返回并修复提交的解决方案。 毕竟，如果 repo 是远程的或共享的，这可能是不可行的。 它使用 core.symlinks=false。 你说你试过这个，但没有说什么时候。 您必须在结帐前执行此操作，普通克隆默认执行此操作。 因此，您必须使用 --no-checkout 选项进行克隆。

git clone --no-checkout the-repo tmp-clone-dir
cd tmp-clone-dir
git config core.symlinks false
git checkout
cp the-problem-file the-problem-file.bak # make a backup
git rm the-problem-file
git commit -m 'Removed problem file pretending to be a symlink' the-problem-file
mv the-problem-file.bak the-problem-file # restore the backup; now it will be of type file
git commit -m 'Added back the problem file - now with the correct type' the-problem-file
git push origin master
cd ..
\rm -rf tmp-clone-dir  # IMPORTANT

最后一步很重要，因为您不想在 core.symlinks=false 的 repo 中做更多的工作。 这只是自找麻烦。

以上假设您希望文件是文件而不是符号链接。 如果它是一个符号链接，那么您将在第一次提交后停止，删除 tmp-clone-dir 并返回到您的正常 repo checkout 以创建符号链接并提交它。

这种方法的好处是您不会破坏任何相关的克隆和分支，因为它保留了历史记录。 这样做的缺点是损坏的提交仍然存在，如果他们尝试使用那个特定的错误提交，将会给任何人带来问题。

Answer 2

我遇到了这个问题，这为我解决了：

git config core.symlinks false
git rm <problem-file>
git commit <problem-file>
git push
git config core.symlinks true

Answer 3

只要您更改了假符号链接文件的内容而不将其模式从符号链接更改为常规文件并提交了结果，您就制作了一个无法在具有真实符号链接的操作系统上提取的 blob，因为您有一个应该是符号链接但其内容太长而不能成为路径名的对象。 通过隐藏此问题，Web 界面对您没有任何帮助。

您可能必须备份到那个提交，修复它，然后重新提交它之后的所有内容。 git rebase -i会有所帮助，但它仍然可能并不容易，特别是如果您在文件处于这种虚假的符号链接但不是真正的符号链接状态时对文件进行了更多更改。

假设错误提交是abcdef123 ，您需要这样做：

git rebase -i 'abcdef123^'

这将使您进入带有提交列表的编辑器。 abcdef123应该在第一行。 在该行上，将pick更改为edit 。 如果有多个错误提交，请将它们全部更改为edit 。 保存并退出编辑器。

现在您将回到您提交错误文件的时间点。 这是你改变历史、纠正曾经出错的事情的机会。 检查提交

git show

并通过将原始符号链接路径名恢复到文件中并git add来撤消坏部分。 或者你真的可以用git rm正确地摆脱符号链接，然后创建一个新文件并git add 。 如果您选择第一个选项，请注意符号链接的内容只是路径名。 它不是文本文件 - 它最后没有换行符。 如果您使用添加换行符的文本编辑器对其进行编辑，则会有一个损坏的符号链接（指向名称中带有换行符的文件）。

完成git add后，将固定提交重新插入到历史记录中的位置：

git commit --amend
git rebase --continue

如果您将多个提交从pick更改为edit ，则必须对每个提交重复该过程。 最后的git rebase --continue会让你回到现在。

如果您在变基期间处于过去的提交中并且您发现整个提交是错误的（除了用它指向的文件的未修改内容替换符号链接之外，它什么也没做），那么您可以git rebase --skip而不是修改和继续。 如果您提前知道这将发生，您可以从git rebase -i列表中删除错误提交，而不是将其pick更改为edit 。

如果您有多个分支受到错误提交的影响，您将不得不为每个分支重复整个过程。 签出一个分支，运行git rebase -i直到完成（ git rebase --continue说“成功重新建立基础”），然后签出下一个分支并再次执行。

将来，当您在 Windows 和真实操作系统之间拆分开发工作时，您的 Windows 是否与 cygwin 一起工作。 在 cygwin 内部，符号链接是符号链接，你不能像以前那样把它们弄乱。

Answer 4

我对少量文件有同样的问题。 我通过使用git remove --cached <file>从存储库中删除它们来解决它，它不会删除我的源中的文件（不再是符号链接）。 删除所有内容后，git 会看到它们仍然存在，因此我可以使用git add . 然后将它们重新提交。现在 git 将它们视为普通文件。

Answer 5

如果您使用的是 bitbucket，还有一种更简单的方法。 由于现在bitbucket支持在线删除文件，您可以转到bitbucket上的repo，找到有问题的文件，按“编辑”按钮和“删除”附近的下拉按钮。

这将删除符号链接损坏的文件，并且您再次拥有一个工作目录。 如果这是一种可能性，它比手动重新定位和删除要快得多。

Answer 6

git config --global core.longpaths true

放这个，然后再试一次。 它会起作用的。