By default, git includes a daemon utility to serve clients using the
git://protocol, so you don't even have to install anything extra. The one thing that may matter to you is that the default git daemon does not provide any authentication mechanism, so anybody on your network will be able to push/pull files onto a project. For a SOHO, this isn't a big deal, but in a corporate environment, you may want to look into something a bit more secure.
Our first order of the day then is to decide the directory we want to serve git project from on the server and start the git daemon. In this example, I will use
/usr/srcon the server. The command to run git daemon then is:
git daemon --reuseaddr --base-path=/usr/src --export-all --verbose --enable=receive-pack --detach --syslogThe
--export-allallows pull/clone to be issued by remote clients, regardless of whether a
git-daemon-export-okfile exists in the git directory. The
--enable=receive-packis required if you want to be able to
pushfrom a client, as it is disabled by default and you will get the error:
'receive-pack': service not enabled for './.git'. The rest of the options should be fairly explicit (if not, see the
git daemonpage. As you can see, these settings are as permissive as can be, which is probably what you want if you are starting with using git as a server.
Creating the server repository
With the daemon running (check your syslog or messages to confirm), we can now create the directory we want to be used as the origin on our server. Let's call it
root@git-server:~# cd /usr/src/ root@git-server:/usr/src# mkdir myproject root@git-server:/usr/src# cd myproject/ root@git-server:/usr/src/myproject# git init Initialized empty Git repository in /usr/src/myproject/.git/Note that the git people historically recommend creating project directory with a
.gitextension, but there doesn't seem to be much point to it.
Indiana Git and the Intuitiveness of Doom
At this stage, if you have existing files for your project, you have the choice of transferring them to the server and
git committhem, or first clone the empty directory on your client and then add the files there. With the latter being the most likely situation, this is what I will demonstrate, therefore (the following was done on Linux - if you are using Msys-git on Windows, see below):
user@git-client:~$ git clone git://git-server/myproject Cloning into myproject... warning: You appear to have cloned an empty repository. user@git-client:~$ cd myproject/ # in real life you would copy, add and commit existing project files there user@git-client:~/myproject$ touch README user@git-client:~/myproject$ git add README user@git-client:~/myproject$ git commit -m "added README" [master (root-commit) e3cb915] added README 0 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 READMESo far so good, but then:
user@git-client:~/myproject$ git push No refs in common and none specified; doing nothing. Perhaps you should specify a branch such as 'master'. Everything up-to-dateOK, googling around shows you need to add
origin masterto that first push, so:
user@git-client:~/myproject$ git push origin master Counting objects: 3, done. Writing objects: 100% (3/3), 208 bytes, done. Total 3 (delta 0), reused 0 (delta 0) remote: error: refusing to update checked out branch: refs/heads/master remote: error: By default, updating the current branch in a non-bare repository remote: error: is denied, because it will make the index and work tree inconsistent remote: error: with what you pushed, and will require 'git reset --hard' to match remote: error: the work tree to HEAD. remote: error: remote: error: You can set 'receive.denyCurrentBranch' configuration variable to remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into remote: error: its current branch; however, this is not recommended unless you remote: error: arranged to update its work tree to match what you pushed in some remote: error: other way. remote: error: remote: error: To squelch this message and still keep the default behaviour, set remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'. To git://git-server/myproject ! [remote rejected] master -> master (branch is currently checked out) error: failed to push some refs to 'git://git-server/myproject'Now that's even worse! What the heck?
Long story short, git has a design limitation that prevents it to update both the working directory structure (the user visible files such as 'README', .c/.h, etc.) and the index (the hashed nodes, that contain the same information plus details of the various changes the files went trough) at the same time, on the server. Yes, if they really wanted to, the git developers could easily work around that limitation by providing an option to automatically force a sync on the remote working dir from the index, when index changes have been pushed, but they have decided that, since there exists individual cases where such an option would cause harm, they might as well prevent everybody from doing so altogether, regardless of whether people might be fully aware of what they are doing and accept the consequences.
So this means that, as long as git sees the server git directory being checked out with the 'master' branch, which is the case by default even on an empty directory, as well as the client git repo also using the 'master' branch, which is also the default, it considers that the server repository has precedence (i.e. that there might exist uncommitted changes in the server repo, that have higher priority than any committed client ones), and therefore, will reject remote requests to update the index, such as a
To work around that then, you need to make sure that the server doesn't have the 'master' branch checked out locally, when you are issuing a
git pushfrom the client. Easiest way to do that is to check into a different branch, away from 'master', on the server, so if we just checkout onto a 'dummy' branch that we create (
-boption), git should be happy again. Let's try that:
root@git-server:/usr/src/myproject# git checkout -b dummy fatal: You are on a branch yet to be bornRight... And people ask me why I'm still not entirely convinced that git is the best invention since sliced bread. Yes, I'll be the first to say that it is usually miles better than the competition, and when it works, it's just brilliant, but quite frankly, there is such thing as intuitive, and as far as intuitive goes, there is still a lot of room for improvement with git.
As the error indicates, the problem this time is that our repo is bare. It doesn't even have a HEAD. Now, because we don't have all day to figure out each of git's numerous intricacies, we just take matters into our own hands and hook into the git index directly with:
root@git-server:/usr/src/myproject# git symbolic-ref HEAD refs/heads/dummyThis should ensure that git no longer sees us as potentially modifying the (still non-existing) 'master' branch on the server and stop bugging us.
Then, if you go back to the client:
user@git-client:~/myproject~ git push origin master Counting objects: 3, done. Writing objects: 100% (3/3), 208 bytes, done. Total 3 (delta 0), reused 0 (delta 0) To git://git-server/myproject * [new branch] master -> masterAt last, success!! From there on you should be able to use a naked
git pushon the client and roll.
If you later want to edit/modify the repo content on the server (the server working dir will remain empty even after a
push, because the working directory is no longer following the 'master' HEAD), you can do so by switching back to the 'master' branch with
git checkout master. Then an up to date version of what you have pushed should be in your server working dir. However, remember that, if you are planning to remotely
pushsome more, you need to use either
git checkout [-b] dummy(if you don't mind having a dummy branch created) or
git symbolic-ref HEAD refs/heads/dummy(if you don't want a branch) on the server when you are done, to prevent git from rejecting the operation. If you use the latter, be mindful that you will get a
warning: remote HEAD refers to nonexistent ref, unable to checkouterror (yes git, if it results in a failure, it is an error, not a warning), so you may have to go back to your server and set
symbolic-refto 'master' before cloning. And if you use the former, make sure that's you're working on the 'master' branch and not 'dummy' after cloning.
Yay, now we have a working git server, and more importantly, we know how to work around the various counter-intuitive git limitations to create repositories on it... Of course, that is, as long as you don't use msys-git on Windows 7...
What's wrong with git daemon and msys-git?
OK, so we are sorted out on Linux. How about we try the same thing on Windows 7 with msys-git?
user@WINDOWS ~ $ git clone git://git-server/myproject Cloning into myproject... remote: Counting objects: 8, done. remote: Compressing objects: 100% (4/4), done. remote: Total 8 (delta 0), reused 0 (delta 0) Receiving objects: 100% (8/8), done. user@WINDOWS ~ $ cd myproject/ user@WINDOWS ~/myproject (master) $ echo "test" > README user@WINDOWS ~/myproject (master) $ git add README warning: LF will be replaced by CRLF in README. The file will have its original line endings in your working directory. user@WINDOWS ~/myproject (master) $ git commit -m "edited README" [master warning: LF will be replaced by CRLF in README. The file will have its original line endings in your working directory. a0f27c3] edited README warning: LF will be replaced by CRLF in README. The file will have its original line endings in your working directory. 1 files changed, 1 insertions(+), 1 deletions(-)So far, so good. But then, if you issue
git pushthe command hangs forever:
user@WINDOWS ~/myproject (master) $ git push Counting objects: 5, done. Delta compression using up to 2 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3)On the server, the log doesn't seem to indicate that much is amiss:
Jul 7 16:22:23 git-server git-daemon: Connection from 188.8.131.52:51238 Jul 7 16:22:23 git-server git-daemon: Extended attributes (13 bytes) exist <host=git-server> Jul 7 16:22:23 git-server git-daemon: Request receive-pack for '/myproject'Congratulations! You've just encountered msys-git bug #457 for which no patch exists yet. If you want a workaround, you can either switch to using ssh (but then you need to sort out authentication, which, for a single-user internal-only VCS operation is a bit of an overkill) or share your repository with samba, and then add the following in the
[remote "origin"]section from
pushurl = file:////git-server/src/myprojectAs can be inferred the above simply forces git to use Samba rather than the git protocol for push operations. With this workaround in place, you are truly set to use a remote git server.
ADDON: The following script might be used as a very useful first commit for the server repository, as it helps toggle between the ability to commit files on the server and allowing client commits:
#!/bin/sh git branch | grep -q \* if [ $? -eq 0 ]; then git symbolic-ref HEAD refs/heads/dummy echo "Switched to fake branch 'dummy'" else git symbolic-ref HEAD refs/heads/master echo "Switched to branch 'master'" fi