Git pull error: unable to create temporary sha1 filename

Question

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:

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=2 which basically states that this is a bogus error that's on top of the pile and thus says nothing about what really is wrong.

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

Edit: Removed the local copy and re-cloned

Answer 1

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

Answer 2

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

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

Did you try a repack ?

git-repack is 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.

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

You have different commands to 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 --aggressive is not sufficient on its own.

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

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

Answer 3

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

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

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.

Answer 4

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.

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.

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.

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.