One user can clone, the other cannot. Why?


we have a small development team, and about half a year ago we introduced version management by means of git.

I set up a bare remote repository, and each of the developers has his own local repository.

I put in the code and everything worked well for a while.

However, when I want to make a fresh clone, I get the warning:

warning: You appear to have cloned an empty repository.

While my colleague gets all the directories and files of the project with the same command. And if I request the log, I get

fatal: Not a git repository

Also, when I wish to see what has happened in the remote repository, I get

(11:19 lukas@login01 remoteRepository) > git log
fatal: bad default revision 'HEAD'

When my colleague does the same, he gets all the messages of the various commits.

We are both in the same user group that has read permissions to the remote repository.

I was able to interact properly with it in the past. I have also made commits to the repo.

However, I must have inadvertently messed something up that disables me to interact properly with the remote repository now but I have no idea what it could be. There is nothing about GIT in either of our environments that could indicate a difference…

Any ideas would be very welcome!

Hard to say without more information, can you please post the output of git remote -v on both setups? Typically this means that your local repository is not tracking the upstream repository. Here is an example where you can see that my “fork” of the repository is where I do all my work, I create pull requests “upstream”, and only allow pulling from the upstream.

$ git remote -v
origin (fetch)
origin (push)
upstream (fetch)
upstream no_push (push)

In this example we outline how users who do not have direct write access to repositories can contribute, sync their changes from upstream, and create a pull request to get the changes merged back in. While in many cases adding the extra steps to avoid pushing to the upstream is not neccesary (due to permission issues) you will run into projects that still expect you to use your fork even if you have write access.

I will be honest I have not managed a git server in over a decade, I am generally pretty happy with github and I am fine letting them managing those aspects of permissions and such. For more granular control of permissions I recalled using

Hi Majormoses,

thank you for taking the time to help me out.

My colleague where everything works fine gets, in his own local repo:

origin /quanta1/home/gtecton/remoteRepository (fetch)
origin /quanta1/home/gtecton/remoteRepository (push)

And I get exactly the same in my own:

origin /quanta1/home/gtecton/remoteRepository (fetch)
origin /quanta1/home/gtecton/remoteRepository (push)

But when I git pull in my own local:

Your configuration specifies to merge with the ref 'master'
from the remote, but no such ref was fetched.

When my colleague pulls just fine. However, when we git branch, we both get


plus he gets two additional branches he has made, while I have only the master.

Does that help?

P.S. The links were good reading material, for which my thanks, but they did not really provide an answer. The workflow was OK the way it was, and it all worked in the past.

Perhaps trying to fetch the origin will help?

git fetch origin master

If that does not help trying adding a -v option and post the output here.

1 Like

Both verbose and non verbose give me the same:

fatal: Couldn't find remote ref master
fatal: The remote end hung up unexpectedly

Our git config --list contain differences, though…

My colleague has


I have exactly that, but I have an additional:


Edit: If I look at it, I think it might be a permission error after all…

(11:52 lukas@login01 newLocal) > git push origin master
Counting objects: 2677, done.
Delta compression using up to 48 threads.
Compressing objects: 100% (2251/2251), done.
Writing objects: 100% (2677/2677), 31.39 MiB | 2.61 MiB/s, done.
Total 2677 (delta 914), reused 1447 (delta 344)
error: unable to resolve reference refs/heads/master: Permission denied
remote: error: failed to lock refs/heads/master
To /quanta1/home/gtecton/remoteRepository
 ! [remote rejected] master -> master (failed to lock)
error: failed to push some refs to '/quanta1/home/gtecton/remoteRepository'

So I will investigate that for the time being…

Second edit. I explicitly set checkout to master.

Now I can git log and get the list of commit messages. Much improve.

Git pull still gives me

Your configuration specifies to merge with the ref 'master'
from the remote, but no such ref was fetched.

and git ls-remote origin -v gives me an empty list, while a local git remote still returns

origin	/quanta1/home/gtecton/remoteRepository (fetch)
origin	/quanta1/home/gtecton/remoteRepository (push)

so it seems the remote repository was somehow affected… Or is that a wrong conclusion?

Solution was found.

All user but one (let us name him John) belong to a specific group.

All users but me also belong to a specific other group.

John made his very first commit, and his primary user group was the group of which all other users also were member, but I was not. All other users had the same group policy could access the files normally. However, I was the odd one out.

For some reason the permission error was drowned somewhere down the river.

I added myself to the group, and now I can operate everything as usual.

Best wishes!

1 Like

What does that mean

didnt understand none what you were saying