tags:

views:

6704

answers:

7

Hi everyone,

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

+3  A: 

It is mentioned there:

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
VonC
A: 

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.

Paul
+11  A: 

FWIW, when I had this problem, but when committing. I tried git-repack and git-gc. Neither worked, but I got a permission denied error. I chowned the entire repo recursively to the user I expected it to be, and I could then commit/push/pull with no problem.

aresnick
Interesting variation on this - I was using git-daemon with one of my repositories for a while, then switched to local check ins/outs for some hook testing I wanted to do because git-daemon doesn't display hook stdio, and git-daemon was root run, whereas the local check-ins were owned by me. Hence the issue.
feoh
+1  A: 

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

+7  A: 

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.

Leigh Caldwell
+3  A: 

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.

conny
A: 

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.

Dieter_be