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 184.108.40.206 and possibly earlier. Thus try to
find 220.127.116.11 or newer somewhere.
2. Clone the repository on --bare format with 18.104.22.168: git clone --bare
3. Try checking out bar.git using 22.214.171.124
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 126.96.36.199 and testing (wheezy) uses 188.8.131.52.
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
> 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
> 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 184.108.40.206, the client has 220.127.116.11, 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?
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 email@example.com.
To unsubscribe from this group, send email to
For more options, visit this group at