Git pull throws the below error: fatal this operation must be run in a work tree

Question

Only one branch exists. I have already pushed files from my local system to remote repo.

At remote repo i am doing git pull How to fix fatal error: this operation must be run in a work tree

Answer 1

At remote repo i am doing git pull ...

More precisely, you have a bare repository (one created with --bare) on the server. Then, either in a hook (such as a post-receive hook) on the server, or by logging into the server, you are going into this bare repository and running git pull.

This fails, because git pull requires a work-tree in which to work. That's because git pull means:

1. run git fetch, then
2. run a second Git command.

The first command—git fetch—can be used in a bare repository. The second one, which is usually git merge, cannot be used in a bare repository. You can instruct Git to use git rebase instead of git merge, but that too cannot be used in a bare repository.

While there are other (rather complicated) ways to deal with this directly on the server, the usual best way is: don't do that. A server repository should simply serve: it's there to receive push operations, which put new commits into it, and it's there to service clone operations, which get all the commits out of it.

If you want to do something complicated, such as fetch from multiple Git repositories and merge various commits, do that in a clone. Once you have sorted out the result—some merges are complex and messy and need a lot of manual intervention, hence the need for a work-tree in which to do work—make a commit from the result, and push the commit to the server. The complex work happens in a regular (non-bare) repository, which has a human supervising it. The simple server-oriented stuff happens in a simple bare repository on the server.

Note that the whole point of a bare repository is that it acts as a simple recipient for git push. A non-bare repoistory, with its work-tree, may have someone doing work on it. If it were to receive a push while the human is working, the human's work would be out of sync with the underlying repository. When the human committed his or her work, that would, in effect, roll back the received push. The effect is roughly equivalent to using git revert with the -n option, except that when humans actually do use git revert -n, they know it, but when they unknowingly revert pushes, they don't know it: they have no way to know.