Git 拉取錯誤：無法創建臨時 sha1 文件名

Question

我有一個小的 git repo 設置，其唯一真正目的是能夠在多台機器（工作、家庭、筆記本電腦）上進行本地開發。 因此，我有一個分支，一旦我離開計算機，我就會提交/推送，一旦我在下一個坐下就拉動。 一直運行良好，到目前為止。 現在，當我打開我的“實時測試”機器時，我得到以下信息：

remote: Counting objects: 38, done.
remote: Compressiremote: ng objects: 100% (20/20), done.
remote: Total 20 (delta 17), reused 0 (delta 0)
error: unable to create temporary sha1 filename .git/objects/ed: File exists

fatal: failed to write object
fatal: unpack-objects failed

在網上搜索我能找到的唯一真正的答案如下： http : //marc.info/? l=git&m=122720741928774&w=2 基本上說明這是一個虛假的錯誤，位於一堆之上，因此什么也沒說關於真正有什么問題。

我該從哪里了解問題所在？

編輯：刪除本地副本並重新克隆

Answer 1

它在“ Re: Bug? git svn fetch: “無法創建臨時 sha1 文件名 /home/andres/git/public/crystal.g ”中提到：

重新打包存儲庫后，問題就消失了。 真的比較奇怪。

你試過重新打包嗎？

git-repack用於將當前不在“包”中的所有對象組合成一個包。 它還可用於將現有包重新組織成一個更高效的包。
包是對象的集合，單獨壓縮，應用增量壓縮，存儲在單個文件中，並帶有關聯的索引文件。
包用於減少鏡像系統、備份引擎、磁盤存儲等的負載。

您是否嘗試升級到最新版本的 Git？

您可以運行不同的命令來“清理”您的存儲庫，從最安全的到更激進的：

$ git-prune
$ git-gc --aggressive
$ git-repack
$ git-repack -a
$ git-prune-packed

---

正如“ Git 垃圾收集似乎不能完全工作”中所述， git gc --aggressive是不夠的。

最有效的組合是添加git repack ，還有git prune ：

git gc
git repack -Ad      # kills in-pack garbage
git prune           # kills loose garbage

Answer 2

無論如何，當我遇到這個問題時——但在提交時——我嘗試了git-repack和git-gc ，但都沒有奏效。 我被拒絕的錯誤權限，害得我chown遞歸整個回購協議我希望它是用戶，然后我可以提交/推/拉沒有問題。

Answer 3

當多個用戶提交到同一個存儲庫時，我看到了這個錯誤，由於ssh 和 umask導致組寫入權限問題

您可以通過在配置的 [core] 部分設置sharedrepository=true使新文件保留 g+w 模式：

cd /my/shared/repo.git
git repo-config core.sharedRepository true

# (might also need to "chmod -R g+wX ." for each 
# user that owns files in .git/objects)

編輯：

此方法僅適用於已存在的 repos。 您可以在創建存儲庫時立即完成： git --bare init --shared 。

Answer 4

我們遇到了同樣的問題，用戶 1 之前提交過，因此創建了 objects/ed 目錄並歸用戶 1 所有。由於用戶 1 的默認權限不允許用戶 2 寫入，因此用戶 2 無法提交。

git 根據需要將這些目錄創建為某種哈希桶，因此它們很可能由幾個不同的人擁有，根據他們的 umask 具有不同的權限。

我們解決了這個問題，首先 chgrping 由同一組擁有的所有目錄，然后用 g+w 對它們全部進行 chmodding，使它們可被組寫入，最后正確設置每個人的 umask，以便所有新創建的存儲桶也可被組寫入。

這是因為我們使用 ssh:// URL 從 git 簽出 - 我假設如果我們使用 git 網絡協議，它不會發生，因為 git 守護進程將具有一致的文件所有權。

Answer 5

就我而言，我在嘗試推送時遇到了這個問題。

dieter@dieter-dellD620-arch sugarcrmclient [master] git push origin
Counting objects: 16, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (10/10), done.
Writing objects: 100% (12/12), 3.91 KiB, done.
Total 12 (delta 1), reused 11 (delta 1)
error: unable to create temporary sha1 filename ./objects/7a: File exists

fatal: failed to write object
error: unpack failed: unpacker exited with error code
To gitosis@tiktak.kangaroot.net:sugarcrmclient.git
 ! [remote rejected] master -> master (n/a (unpacker error))
 ! [remote rejected] web -> web (n/a (unpacker error))
error: failed to push some refs to 'gitosis@tiktak.kangaroot.net:sugarcrmclient.git'

這不是許可問題。 git gc、git gc --agrressive、git repack 或 git prune 本地沒有幫助。 請注意錯誤如何說“解包器錯誤”，我認為這是關鍵，因為它暗示它在另一邊。 所以我去了（裸）存儲庫並在那里做了一個 git gc 。 然后我可以推得很好。

Answer 6

我在使用git push時候遇到這個問題

然后我運行git gc ，它起作用了。

從 git-gc(1) 手冊頁：

git-gc - 清理不必要的文件並優化本地存儲庫

Answer 7

我遇到了這個問題，感覺我已經嘗試了上述所有方法。 我以前見過這個，這是由於推送到 repo 的不同用戶之間的權限，但在這種情況下，每個人都在同一個用戶下推送，只是為了更好的衡量，我（在 repo 上）將所有內容都歸還給了正確的用戶和 group 和 chmodded u+w 和 g+w 以獲得良好的度量。 我仍然收到error: unable to create temporary sha1 filename ./objects/9a 。

我剛剛做了更多的調查，似乎確實有一些權限問題：在推送之前，在 repo（這是一個托管在服務器上的裸 repo）上，對象中的所有文件都具有-rw-rw-r--權限-rw-rw-r--設置，這正是您所期望的。 它們都歸同一個用戶和組所有。 推送失敗后，我可以搜索權限設置為-r--r--r-- ，即任何人都不可寫，並使用 bash 命令find . -perm 444 | xargs ls -l顯示它們的位置find . -perm 444 | xargs ls -l find . -perm 444 | xargs ls -l find . -perm 444 | xargs ls -l 。 這樣做給了我以下內容：

-r--r--r-- 1 ourusername ourgroupname    730 Nov  4 15:02 ./objects/46/346f550340bc0d3fec24ea42b25999161f8c7a
-r--r--r-- 1 ourusername ourgroupname    177 Nov  4 15:02 ./objects/4c/664ebbfad568de6101a52c01f5117654945d6d
-r--r--r-- 1 ourusername ourgroupname    730 Nov  4 14:36 ./objects/9e/3f572366da9fb319331dfd924ae35cf9fd00ae
-r--r--r-- 1 ourusername ourgroupname    175 Nov  4 14:36 ./objects/aa/f42d7ed706f1d2e4a0aa1c5eb184e17e917204

這些都是最近更改的文件（發布時間為 11 月 4 日 15:08）。 因此，看起來 git 正在更新/替換文件（給它們一個新的時間戳），更改進程中的權限，然后抱怨權限。 我完全被這里發生的事情難住了:(

Answer 8

如果其他人遇到此錯誤，我在跨越 windows-linux 鴻溝時遇到過。 似乎如果換行符格式轉換為 windows，在某些情況下您仍然可以提交，但是 git 然后轉換為 linux 格式。

因此，如果新行是唯一的更改，那么我們現在有兩個相同的連續提交。 由於提交哈希是從提交文件數據生成的，並且每個都具有相同的數據，因此它們最終具有相同的哈希。 至少在我的情況下，這就是“文件存在”所表明的。 Git整個人都糊塗了。

我通過在本地和中央存儲庫上執行git reset --hard修復它。

Answer 9

我的問題是權限問題

我上目錄然后 cp -R repo repo_copy

然后一切正常。

然后我去刪除 repo 和權限被拒絕，檢查權限和確定足夠的權限已經更改，我正在運行的用戶沒有寫訪問權限......

Answer 10

就個人而言，我在做 git push origin master 時遇到了這個問題。 我的解決方案是：在我的服務器上，我在包含我的存儲庫的目錄中使用 root 登錄並遞歸執行：

chown -hR MyGitUser MyRepo

一切正常

我只有一個 git 用戶，其他人通過發布他們的公鑰來連接 ssh。 如果您配置多個 git 用戶，則必須為每個用戶執行相同的操作。

Answer 11

嘗試了一些解決方案，但最終意識到我們的 git 服務器的磁盤沒有剩余空間。

Answer 12

嘗試在 heroku 上部署時遇到了這個問題。 原來我有一個 gem 將文件寫入 tmp/ 目錄，而 heroku 不喜歡那樣。 把文件拿出來，瞧，問題解決了。 請參閱： https : //devcenter.heroku.com/articles/read-only-filesystem

Answer 13

我最近遇到了這個問題，我嘗試了這個線程上的所有內容，但沒有成功。 我的 VPS 上還有大量磁盤空間，但結果證明由於沒有清理部署文件夾，我超出了 inode 限制（可能是由於我在處理它們之前包含了 100 個文件的 JS 庫）。

我刪除了大量舊部署，一切正常。

我意識到這有點邊緣情況，但如果所有其他方法都失敗了，請記住這一點。

Answer 14

我有一個類似的錯誤，這不是權限問題（我是存儲庫的唯一用戶），並且 gc/repack 技術都不起作用。 最終，我只是將舊的遠程存儲庫移到一邊並推送了一個新的存儲庫。 幸運的是，它很小。

利亞姆

Answer 15

應該注意的是，您需要修復要推送到的存儲庫的權限，而不僅僅是您的工作存儲庫。

Answer 16

更改用戶組 + 權限對我有用。 我注意到一些用戶的提交在不同的組下。 將所有更改為同一組可解決此問題。

Answer 17

在 sshfs 上工作時，我會遇到這樣的錯誤。 它會在卸載並再次安裝共享后自行修復。

Answer 18

我曾見過此錯誤並將其跟蹤為權限問題。 我找不到它是如何引起的，但不知何故 git 作為一個沒有某些對象目錄寫入權限的組運行。

我在代碼中沒有看到任何明顯的原因，並假設這是一個 OS X 權限問題，大概是由於一些草率的制造或安裝。

Answer 19

在 linux 服務器上工作到本地 mac - 我嘗試了上面的一些建議，但沒有成功。 重新啟動，然后它工作。

它不是一個真正合適的解決方案，但我認為它可能會幫助那里的人。