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 and possibly earlier. Thus try to 
   find or newer somewhere.
   2. Clone the repository on --bare format with git clone --bare 
   foo.git bar.git
   3. Try checking out bar.git using
   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 and testing (wheezy) uses

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.



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, the client has, 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
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to