When you're the origin repo in git, how do you do a local pull?

Question

I have a server where I set up a Git repository. From my clients, I can execute

git pull origin

and

git push origin

and my changes are correctly pushed/pulled to the remote Git server. I also need the ability to checkout the project on the server itself. I did not use init --bare when I set it up, because I explicitly wanted to have a working copy on the server as well.

When I run git pull, however, I get a message fatal: Where do you want to fetch from today?. How can I check out the latest changes into my local working copy on the server?

Answer 1

I guess there is not remote set.

With git remote add <remotename> <address> you can add a remote repository. <remotename> is just the name you give it, and addresss is the url to the repository you want to pull from.

Answer 2

Fixing a working copy to match the latest changes pushed

git checkout HEAD

Might be what you're looking for.

The pushes from the client change the index and not the working files, so you have working files that are unchanged while the git recording of things has moved ahead. In order to just wipe the working files in favor of the latest incarnation, you have the checkout the latest version that got pushed up to the server.

...Edit:

Using two non-bare repositories

I just realized that I gave you the information to understand the problem (index changes implicitly but working files only change explicitly), but not necessarily the best way to fix it. Here is what I have done in the past, and what I suggest if you don't want to get a central bare repository involved:

On the server:

git branch staging
git checkout staging

On the client machine:

Hack away at some changes in master, then push to the server.

On the server: git rebase master (explicitly updating your staging branch to match the updated index.)

Finally if you want to make changes from on the server (bugfixes, what have you), you will want to sync those changes up to master as well, which you can do by:

On the server:

Commit changes made on the staging branch.
git rebase master
git checkout master
git rebase staging
git checkout staging

And there you go, every commit in master will be in staging, and every commit that was made in the staging branch will be the latest commits in master.

That kind of workflow should work out for you even with a non-bare central repository. Essentially you're leaving the server's master branch bare, and making the staging branch the working copy for the server.

Using a central bare repo is cleaner

Generally, despite that 2 points in the network seem simplest, having a "centralized" bare repository is often simpler, it allows you to always both push and pull to that location without having to really think about it. I also recommend the benefits of the web code visualization you can get from github.com for this reason (free for open source stuff, I use it for everything that I do these days).

Answer 3

You say that:

I did not use init --bare when I set it up, because I explicitly wanted to have a working copy on the server as well.

Let's assume that this repo is located on the server at $REPO_DIR.

Do you want to open a shell on the server, cd to $REPO_DIR and edit the code there? If so, then you don't need to pull from any remote. This is the master copy of the repository. You can simply edit the code in place and then git add . and git commit.

If you want to create a local copy of this repo, say at /home/user/my_repo, then you need to cd to /home/user and run git clone $REPO_DIR. This creates the remote reference which will allow you to push to and pull from $REPO_DIR. Then when you are done with your changes, you can push them to the remote.