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

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 2

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 3

I had this issue recently and I tried everything on this thread with no luck. There was plenty of disk space left on my VPS but it turned out that due to not cleaning out the deployments folder I had exceeded the inodes limit (probably due to the JS libs I was including with 100s of files before crunching them).

I deleted a load of old deployments and everything worked fine.

I realise this is a bit of an edge case but it's something to keep in mind if all else fails.

Answer 4

I had this problem when trying to deploy on heroku. Turns out I had a gem that wrote a file to the tmp/ directory and heroku didn't like that. Took the file out and voila, problem solved. See this: https://devcenter.heroku.com/articles/read-only-filesystem

Answer 5

I encountered this problem when using git push

Then I run git gc, it works.

From git-gc(1) Manual Page:

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

Answer 6

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.

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.

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

Answer 7

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:

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.

Answer 8

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.

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:

-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 :(

Answer 9

Working on linux server to local mac - I tried a few of the suggestions above with no luck. Rebooted and then it worked.

Its not really a proper solution but I though it might help someone out there.

Answer 10

Tried some of the solutions but eventually realized that the disk of our git server had no free space left.

Answer 11

I get errors like this when working over sshfs. It repairs itself after unmounting and then mounting the share again.

Answer 12

Changing user group + permission worked for me. I've noticed that some user's commits were under different group. Changing all to the same group fixed this problem.

Answer 13

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

Answer 14

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

Answer 15

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 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'

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.

Answer 16

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 17

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.

Answer 18

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...

Answer 19

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.