Problem with cloning Git repository

F

Flying2012-06-15 20:41:14

git

Flying, 2012-06-15 20:41:14

I ran into an unpleasant problem when working with Git, unfortunately all attempts to find a solution on my own or on Google were unsuccessful, I hope for the help of the collective habrareason.

The situation is as follows:

There is a server (Linux Debian), Git 1.7.2 (the latest version from debian's stable branch) and gitolite 3 are installed on it. Apache / PHP / MySQL is also raised on this server to deploy test versions of sites, development which is conducted under Windows.

There are two repositories on the server running Gitolite. There are no problems with cloning one of them, repository cloning log (domain and repository names have been changed, but this is irrelevant):

Windows 7, Git 1.7.10 Linux Debian x64, Git 1.7.2.5
git clone [email protected]:project1 Cloning into 'project1'... remote: Counting objects: 4240, done. remote: Compressing objects: 100% (3301/3301), done. remote: Total 4240 (delta 970), reused 4153 (delta 911) Receiving objects: 100% (4240/4240), 4.96 MiB | 181 KiB/s, done. Resolving deltas: 100% (970/970), done.

git clone [email protected]:project1 Cloning into project1... remote: Counting objects: 4240, done. remote: Compressing objects: 100% (3301/3301), done. remote: Total 4240 (delta 970), reused 4153 (delta 911) Receiving objects: 100% (4240/4240), 4.96 MiB, done. Resolving deltas: 100% (970/970), done.

Strange things have been happening with the second project since yesterday:

Windows 7, Git 1.7.10 Linux Debian x64, Git 1.7.2.5 I highlighted the numbers so that you can see that they are different. The question is how can this be? At a glance, the difference between the commands in the operating system, the minor version of Git, and the user whose key is used for authorization. But with the same differences, the first repository is normally cloned. The problem started after yesterday, when trying to pull on the server (and it is done automatically through a hook in Gitolite), a conflict occurred. But, again, this was unlikely to affect cloning, especially since cloning works fine for a remote Windows client. Can anyone point me in the direction in which I should dig to solve this problem?
git clone [email protected]:project2 Cloning into 'project2'... remote: Counting objects: 4084, done. remote: Compressing objects: 100% (3213/3213), done. remote: Total 4084 (delta 747), reused 4002 (delta 710) Receiving objects: 100% (4084/4084), 303.93 MiB | 168 KiB/s, done. Resolving deltas: 100% (747/747), done.

git clone [email protected]:project2 Cloning into project2... remote: Counting objects: 3760, done. remote: Compressing objects: 100% (3137/3137), done. Receiving objects: 100% (3760/3760), 303.88 MiB | 13.81 MiB/s, done. Resolving deltas: 100% (537/537), done. remote: Total 3760 (delta 537), reused 3694 (delta 513) error: refs/remotes/origin/master does not point to a valid object! error: Trying to write ref refs/heads/master with nonexistant object 37f88348b734c899a7ca837dab947d69a8177a94 fatal: Cannot update the ref 'HEAD'.

Reply

Answer the question

In order to leave comments, you need to log in

2 answer(s)

N

nicolnx, 2012-06-15
@Flying

Just the other day we encountered a similar problem on github. Support replied:
I've just found the problem. Some external program has created two references in a non-standard reference path for your repository
: standard and confusion old Git clients. AFAIK, these references are created by Gerrit. I've manually removed those two references, and clones should work again, but if you continue using Gerrit, the problem will persist. The only workaround is updating your version of Git to the bleeding edge. Updated clients to 1.7.10 and the problem is gone.

S

sdevalex, 2012-06-15
@sdevalex

If the history is not important, then just re-create the repository. There can be a bunch of different problems and a bunch of solutions.