Git 拉取错误：无法创建临时 sha1 文件名

Git pull error: unable to create temporary sha1 filename

提问by Ickmund

I've got a small git repo setup with the only real purpose to be able to develop locally on several machines (work, home, laptop). Thus I have one branch and I commit/push once I leave a computer, pull once I sit down at the next. Has worked fine, up to now that is. Now when I pull on my 'live test' machine, I get the following:

我有一个小的 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

Searching around the net the only real answer I could find was the following: http://marc.info/?l=git&m=122720741928774&w=2which basically states that this is a bogus error that's on top of the pile and thus says nothing about what really is wrong.

在网上搜索我能找到的唯一真正的答案如下：http: //marc.info/?l= git&m=122720741928774&w=2 基本上说明这是一个虚假的错误，位于一堆之上，因此什么也没说关于真正有什么问题。

Where do I go from here to find out what is wrong?

我该从哪里了解问题所在？

Edit: Removed the local copy and re-cloned

编辑：删除本地副本并重新克隆

采纳答案by aresnick

For what it's worth, when I had this problem—but when committing—I tried git-repackand git-gc, but neither worked. I got a permission denied error, which led me to chownthe entire repo recursively to the user I expected it to be, and I could then commit/push/pull with no problem.

值得一提的是，当我遇到这个问题时——但在提交时——我尝试了git-repack和git-gc，但都没有奏效。我收到了一个权限被拒绝的错误，这导致我chown将整个 repo 递归到我期望的用户，然后我可以毫无问题地提交/推/拉。

回答by VonC

It is mentioned in "Re: Bug? git svn fetch: "unable to create temporary sha1 filename /home/andres/git/public/crystal.g":

它在“ Re: Bug? git svn fetch: “无法创建临时 sha1 文件名 /home/andres/git/public/crystal.g”中提到：

After repackingthe repository the problem is gone. Really rather strange.

经过重新包装库中的问题已经一去不复返了。真的比较奇怪。

Did you try a repack ?

你试过重新打包吗？

git-repackis used to combine all objects that do not currently reside in a "pack", into a pack. It can also be used to re-organize existing packs into a single, more efficient pack.
A pack is a collection of objects, individually compressed, with delta compression applied, stored in a single file, with an associated index file.
Packs are used to reduce the load on mirror systems, backup engines, disk storage, etc.

git-repack用于将当前不在“包”中的所有对象组合成一个包。它还可用于将现有包重新组织成一个更高效的包。
包是对象的集合，单独压缩，应用增量压缩，存储在单个文件中，并带有关联的索引文件。
包用于减少镜像系统、备份引擎、磁盘存储等的负载。

And did you try to upgrade to the latest version of Git ?

您是否尝试升级到最新版本的 Git？

You have different commandsto run in order to "clean" your repository, from the safest to the more aggressive ones:

您可以运行不同的命令来“清理”您的存储库，从最安全的到更激进的：

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

---

---

As mentioned in "Git Garbage collection doesn't seem to fully work", a git gc --aggressiveis not sufficient on its own.

正如“ Git 垃圾收集似乎不能完全发挥作用”中所述，仅靠agit gc --aggressive是不够的。

The most effective combination would be adding git repack, but also git prune:

最有效的组合是添加git repack，但也包括git prune：

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

回答by conny

I've seen this error when multiple users commit to the same repository, resulting in group-write permission problems as a consequence of ssh and umask

当多个用户提交到同一个存储库时，我看到了这个错误，由于ssh 和 umask导致组写入权限问题

You can make new files retain the g+w mode by setting sharedrepository=truein the [core] section of config:

您可以通过sharedrepository=true在 config 的 [core] 部分设置来使新文件保留 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)

EDIT:

编辑：

This method is only applies to already existing repos. You can done right once on creation of the repository: git --bare init --shared.

此方法仅适用于已存在的 repos。您可以在创建存储库时立即完成：git --bare init --shared.

回答by Leigh Caldwell

We had the same problem where user 1 had previously committed, whereupon the objects/ed directory was created and owned by user 1. Because user 1's default permissions did not allow writing by user 2, user 2 could not commit.

我们遇到了同样的问题，用户 1 之前提交过，因此创建了 objects/ed 目录并归用户 1 所有。由于用户 1 的默认权限不允许用户 2 写入，因此用户 2 无法提交。

git creates these directories as hash buckets of some kind on demand, so it is quite possible for them to be owned by several different people with different permissions according to their umask.

git 根据需要将这些目录创建为某种哈希桶，因此它们很可能由几个不同的人拥有，根据他们的 umask 具有不同的权限。

We solved it by first chgrping all the directories to be owned by the same group, then chmodding them all with g+w so they were group writeable, and finally setting everyone's umask correctly so that all newly created buckets will also be group writeable.

我们解决了这个问题，首先 chgrping 由同一组拥有的所有目录，然后用 g+w 对它们全部进行 chmodding，使它们可被组写入，最后正确设置每个人的 umask，以便所有新创建的存储桶也可被组写入。

This is because we are using ssh:// URLs to check out from git - I assume if we were using the git network protocol it would not happen because the git daemon would have consistent file ownership.

这是因为我们使用 ssh:// URL 从 git 签出 - 我假设如果我们使用 git 网络协议，它不会发生，因为 git 守护进程将具有一致的文件所有权。

回答by Dieter_be

In my case, I had this issue when trying to push.

就我而言，我在尝试推送时遇到了这个问题。

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 [email protected]: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 '[email protected]:sugarcrmclient.git'

it was not a permission problem. git gc, git gc --agrressive, git repack or git prune locally did not help. Note how the error says "unpacker error", I think that's key, because it implies it's at the other side. So I went to the (bare) repository and did a git gc there. Then I could push fine.

这不是许可问题。git gc、git gc --agrressive、git repack 或 git prune 本地没有帮助。请注意错误如何说“解包器错误”，我认为这是关键，因为它暗示它在另一边。所以我去了（裸）存储库并在那里做了一个 git gc 。然后我可以推得很好。

回答by Max Williams

I'm having this problem and feel like i've tried all of the things above. I'd seen this before and it was due to permissions between different users pushing to the repo, but in this instance everyone pushes under the same user, and just for good measure i've (on the repo) chowned everything to the right user and group and chmodded u+w and g+w for good measure. I'm still getting error: unable to create temporary sha1 filename ./objects/9a.

我遇到了这个问题，感觉我已经尝试了上述所有方法。我以前见过这个，这是由于推送到 repo 的不同用户之间的权限，但在这种情况下，每个人都在同一个用户下推送，只是为了更好的衡量，我（在 repo 上）将所有内容都归还给了正确的用户和 group 和 chmodded u+w 和 g+w 以获得良好的度量。我还在得到error: unable to create temporary sha1 filename ./objects/9a。

I've just done a bit more investigation and there does seem to be something going on with permissions: before the push, on the repo (which is a bare repo hosted on a server), all files in objects have permissions of -rw-rw-r--set, which is what you'd expect. They are all owned by the same user and group. After the failed push, i can grep for files with the permissions set to -r--r--r--, ie not writable by anyone, and display their locations with the bash command find . -perm 444 | xargs ls -l. Doing that gives me the following:

我刚刚做了更多调查，似乎确实有一些权限问题：在推送之前，在 repo（这是托管在服务器上的裸 repo）上，对象中的所有文件都具有-rw-rw-r--set权限，其中是你所期望的。它们都归同一个用户和组所有。推送失败后，我可以 grep 获取权限设置为 的文件-r--r--r--，即任何人都不可写，并使用 bash 命令显示它们的位置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

These are all recently changed files (at time of posting it's Nov 4, 15:08). So, it looks like git is updating/replacing the files (giving them a new timestamp), changing the permissions in the process, then complaining about the permissions. I'm totally stumped as to what's going on here :(

这些都是最近更改的文件（发布时间为 11 月 4 日 15:08）。因此，看起来 git 正在更新/替换文件（给它们一个新的时间戳），更改进程中的权限，然后抱怨权限。我完全被这里发生的事情难住了:(

回答by Wen Qi

I encountered this problem when using git push

我在使用的时候遇到了这个问题 git push

Then I run git gc, it works.

然后我运行git gc，它的工作原理。

From git-gc(1) Manual Page:

从 git-gc(1) 手册页：

git-gc - Cleanup unnecessary files and optimize the local repository

git-gc - 清理不必要的文件并优化本地存储库

回答by patcon

If anyone else gets this error, I've come across it when working across the windows-linux divide. Seems that if newline formats get converted to windows, you can still commit in some circumstances, but git then converts to linux format.

如果其他人遇到此错误，我在跨越 windows-linux 鸿沟时遇到过。似乎如果换行符格式转换为 windows，在某些情况下您仍然可以提交，但是 git 然后转换为 linux 格式。

So if new lines were the only change, then we now had two identical commits in a row. Since commit hashes are generated from commit file data, and each had the same data, they ended up with the same hash. At least in my case, that's what the "File exists" indicates. Git got all confused.

因此，如果新行是唯一的更改，那么我们现在有两个相同的连续提交。由于提交哈希是从提交文件数据生成的，并且每个都具有相同的数据，因此它们最终具有相同的哈希。至少在我的情况下，这就是“文件存在”所表明的。Git整个人都糊涂了。

I fixed it by doing git reset --hardlocally and on the central repo.

我通过在git reset --hard本地和中央仓库上进行修复。

回答by patcon

My issue was a permission problem

我的问题是权限问题

I went up directory then cp -R repo repo_copy

我上目录然后 cp -R repo repo_copy

then everything worked again.

然后一切正常。

then I went to delete repo and permission denied, checked perms and sure enough perms had been changed that the user I was running as didn't have write access...

然后我去删除 repo 和权限被拒绝，检查权限和确定足够的权限已经更改，我正在运行的用户没有写访问权限......

回答by eso

Personally, I got this problem when I did a git push origin master. The solution for me was: On my server, I login with root in the directory that contains my repository and do recursively:

就个人而言，我在做 git push origin master 时遇到了这个问题。我的解决方案是：在我的服务器上，我在包含我的存储库的目录中使用 root 登录并递归执行：

chown -hR MyGitUser MyRepo

and all works fine

一切正常

I have only one git user and others connect with ssh by publishing their public key. If you configure several git users you have to do the same for each user.

我只有一个 git 用户，其他人通过发布他们的公钥来连接 ssh。如果您配置多个 git 用户，则必须为每个用户执行相同的操作。