Git：无法创建符号链接（文件名太长） [英] Git: unable to create symlink (File name too long)

问题描述

我将一个项目从linux推到了bitbucked，然后在windows上克隆了它。结果发现有两个符号链接，它们在窗口上显示为文本文件。因为我知道他们应该指向哪里，所以我将它们替换为目标文件的副本，并进行提交和推送。

现在当我查看它时，butbucket存储库看起来没问题他们的网络界面。然而，在我的unix机器上的git克隆给了我两条消息，如：

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

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

我可以没有符号链接，但我想有一个可用的存储库。有人知道一种方式（除了重新创建存储库）吗？

解决方案

只要您更改伪符号链接的内容-file没有改变其模式从symlink到常规文件并提交结果，你做了一个blob，不能在具有真正符号链接的操作系统上提取，因为你有一个对象应该是一个符号链接，但其内容是太长，不能成为一个路径名。通过隐藏这个问题，Web界面并没有为你带来任何好处。

您可能需要备份到该提交，修复它并重新提交它后面的一切。 git rebase -i 会有所帮助，但它可能并不容易，尤其是如果在文件符号链接中进行了更多更改时假设坏的提交是 abcdef123 ，你需要这样做：

  git rebase -i'abcdef123 ^'
  

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

现在您将回到您提交错误文件的时间点。这是你改变历史的机会，把那些曾经出错的事情弄清楚。使用

  git show 
  

$ b检查提交
$ b

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

之后

  git commit --amend 
 git rebase --continue 
  

如果您更改从挑选到编辑多次提交，您必须为每个提交重复该过程。最后的 git rebase --continue 会让你回到现在。

如果你在过去提交在重新绑定期间，你会发现整个提交是不好的（除了用它指向的文件的未修改内容替换一个符号链接外，没有其他任何操作），那么你可以 git rebase --skip 而不是修改和继续。如果您事先知道会发生这种情况，那么您可以删除 git rebase -i 列表中的错误提交，而不是更改它的选择到 edit 。

如果您有多个分支受到错误提交s），你将不得不重复每个分支的整个过程。检查一个分支，运行 git rebase -i 来完成（当 git rebase --continue 说成功重新发布），然后检查下一个分支并再次执行。未来，在Windows和实际操作系统之间分割开发工作时，请执行Windows与cygwin一起工作。在cygwin里面，符号链接是符号链接，你不能像你那样搞乱它们。

I had pushed a project from linux to bitbucked and then cloned it on windows. Turns out there were two symlinks, which appeared as textfiles on windows. Since I knew where they should point to, I replaced them by copies of their destination files, committed and pushed.

Now the butbucket repository looks okay when I look it it from their web interface. However a git clone on my unix machine gives me two messages like:

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

and the two files, which were symlinks previously are absent. I tried cloning into /tmp/... to get shorter filenames, but got the same results. That suggests, that something went bad with the bitbucket repository. I tried core.symlinks on and off.

I can live without the symlinks, but I'd like to have a working repository. Does anybody know a way (other than recreating the repository)?

解决方案

As soon as you changed the content of a fake-symlink-file without also changing its mode from symlink to regular file and committed the result, you made a blob that can't be extracted on an OS with real symlinks, because you have an object that is supposed to be a symlink but its content is too long to be a pathname. The web interface is not doing you any favors by hiding this problem.

You're probably going to have to back up to that commit, fix it, and re-commit everything after it. git rebase -i will help, but it still might not be easy, especially if you've made more changes to the files while they were in this bogus symlink-but-not-really-a-symlink state.

Supposing that the bad commit is abcdef123, you need to do this:

git rebase -i 'abcdef123^'

which will put you in an editor with a list of commits. abcdef123 should be on the first line. On that line, change pick to edit. If there is more than one bad commit, change all of them to edit. Save and exit the editor.

Now you'll be back in the point in time where you committed the bad file. This is your chance to alter history, putting things right that once went wrong. Inspect the commit with

git show

and undo the bad part by restoring the original symlink pathname into the file and git adding it. Or you could really get rid of the symlink properly with git rm, then create a new file and git add that. If you choose the first option, be aware that the content of a symlink is just a pathname. It's not a text file - it doesn't have a newline on the end. If you edit it with a text editor that adds a newline, you'll have a broken symlink (pointing to a file with a newline in its name).

After you've done your git add, reinsert the fixed commit into its place in history:

git commit --amend
git rebase --continue

If you changed multiple commits from pick to edit you'll have to repeat that procedure for each one. The final git rebase --continue will bring you back to the present.

If you are at a past commit during the rebase and you discover that the whole commit is bad (it did nothing else besides replacing a symlink with the unmodified content of the file it points to), then you can git rebase --skip instead of amending and continuing. If you know ahead of time that this is going to happen, you can just delete the bad commit from the git rebase -i list instead of changing its pick to edit.

If you have multiple branches affected by the bad commit(s), you will have to repeat the whole procedure for each branch. Check out a branch, run the git rebase -i to completion (which is when git rebase --continue says "Successfully rebased"), then check out the next branch and do it again.

In the future, when splitting your development work between Windows and a real OS, do your Windows work with cygwin. Inside cygwin, symlinks are symlinks and you can't mess them up like you did.

这篇关于Git：无法创建符号链接（文件名太长）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！