Solution 1: unstable, easiestThis *usually* works:
git clone -v https://myrepo.git Cloning into 'myrepo-1'... Password for 'https://email@example.com': POST git-upload-pack (174 bytes) remote: Counting objects: 2287, done. remote: Compressing objects: 100% (1276/1276), done. remote: Total 2287 (delta 1340), reused 1692 (delta 883) Receiving objects: 100% (2287/2287), 53.37 MiB | 632 KiB/s, done. Resolving deltas: 100% (1340/1340), done.Or another when, when pulling from a repo:
remote: Counting objects: 53, done. remote: Compressing objects: 100% (28/28), done. remote: Total 28 (delta 23), reused 2 (delta 0) Unpacking objects: 100% (28/28), done.The problem is that nothing is updated on the disk. I have tried using -v in order to obtain more information about what is going on, but I never get more than shown above. I am using Git over HTTPS with the HTTPS proxy well configured - so this should not be an issue.
After un-finished clone, I have noticed, that the objects directory inside the .git directory actually changed it's size quite a lot. So it seems, that the objects are well received but never written to the actual branch. That might sound like a user-rights issue. But I am admin on the machine and I have access write rights on the folder. So for now, I don't know the cause of this problem. I have simple solution to overcome this issue. What I do to fix the repository is quite straightforward:
$ git fsck Checking object directories: 100% (256/256), done. Checking objects: 100% (2187/2187), done. dangling commit da575f887db63ccf97f37f9cf96316307398db82Git fsck always founds one dangling commit. It is a utility which checks the integrity of the object database. Here the dangling commit is a commit which is not used by any branch. To fix the issue I can just merge the commit with the current branch.
$git merge da575f887db63ccf97f37f9cf96316307398db82And everything works just fine...