After hours of debugging with the help of charon and canton7 on the Freenode #git channel, we found one solution for this:
1. The problem only happens on 1.7.2.5 and possibly earlier. Thus try to find 1.7.10.4 or newer somewhere. 2. Clone the repository on --bare format with 1.7.10.4: git clone --bare foo.git bar.git 3. Try checking out bar.git using 1.7.2.5 4. Observe that everything works fine now (!) Note that local cloning works (git clone /blah/foo.git foo) but using file:/// or SSH protocols does *not*. So if cloning from a local path works for you, that doesn't mean you fixed the repository, you need to try through file:/// or SSH. All of this is mostly relevant to Debian, since Debian stable (squeeze) at this time uses 1.7.2.5 and testing (wheezy) uses 1.7.10.4. I have a copy of the broken repository and might be able to put together a list of all the (many, many!) things we tried to get to the actual root of the problem if anyone is interested. But in general, cloning to a new bare repository with a much newer git version could fix the issue for you. Cheers, Ramón On Thursday, September 20, 2012 4:56:42 PM UTC+2, Ramón Cahenzli wrote: > > Hi all, > > I have an issue cloning a repository's master branch on any new machine. > Machines that had an old clone of the same repository have no problem with > the master branch. > > When cloning, I get the fatal error "Trying to write ref refs/heads/master > with nonexistant object 38eca7173be01a36ef03ebcf75732eba32e4038d" and git > immediately deletes the target directory of the clone. However, all objects > seem to be transmitted: > > remote: Counting objects: 45900, done. > remote: Compressing objects: 100% (14129/14129), done. > remote: Total 45900 (delta 30836), reused 44791 (delta 30042) > Receiving objects: 100% (45900/45900), 52.81 MiB | 18.27 MiB/s, done. > Resolving deltas: 100% (30836/30836), done. > error: refs/remotes/origin/master does not point to a valid object! > error: Trying to write ref refs/heads/master with nonexistant object > 38eca7173be01a36ef03ebcf75732eba32e4038d > fatal: Cannot update the ref 'HEAD'. > > And when we look at the repository on the server, the object is there: > > Output of ls -l ./objects/38/eca7173be01a36ef03ebcf75732eba32e4038d > > -r--r----- 1 gitolite gitolite 191 Sep 20 15:45 > ./objects/38/eca7173be01a36ef03ebcf75732eba32e4038d > > > Output of git cat-file -p 38eca7173be01a36ef03ebcf75732eba32e4038d > > tree 8edd1a6a3d9b309402edcde6f49526400a0ac487 > > > parent 846c4b22ea89475cb70ca0bfe1e67b84f4118c0c > > > author Ramón Cahenzli <censored> 1348148745 +0200 > > > committer Ramón Cahenzli <censored> 1348148745 +0200 > > > > > > ApiGen: No need to check for new versions. > > > The git version on the server is 1.7.10.4, the client has 1.7.2.5, both on > Debian. We use gitolite 2.3 for those repositories, from Debian wheezy. We > haven't had issues like this on either GitHub or with plain SSH-based repos > (as in, no gitolite), so this might in fact be a gitolite issue, but > perhaps there is something obvious I'm missing? > > Cheers, > > Ramón > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To view this discussion on the web visit https://groups.google.com/d/msg/git-users/-/VsWm1acgstQJ. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.