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 1348148745 +0200
>
>
> committer Ramón Cahenzli 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.
