Git pull error: unable to create temporary sha1 filename

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

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.

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.

My issue was a permission problem

I went up directory then 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...

I've seen this error once and tracked it to a permissions problem. I couldn't find how it had been caused, but somehow git had run as a group that didn't have write permission for some object directory.

I didn't see any obvious reason for it in the code and hypothesized that it was an OS X permissions problem, presumably from some sloppy make or install.

I had a similar error, and it was not a permissions problem (I'm the only user of the repository), and none of the gc/repack techniques worked. Ultimately I just moved aside the old remote repository and pushed a new one. Fortunately it was quite small.

Liam

It should be noted that you need to fix the permissions on the repository that you're pushing to, not just your working one.