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

放這個，然后再試一次。 它會起作用的。