Git basics: reversing the ‘git sucks’ effect

Posted by – 19/02/2009

I’ve been using git this last few days and I am still working on a workflow for my projects. Unfortunately, as others have noticed, git violates POLS is so many ways, it ends up being hard to get.

Creating a remote repository seems to be the first thing to bite a developer switching to git (mainly if coming from a centralized SCM). I have not decided which is the best way of doing it, but I’ve been using git-daemon via inetd and a path in my remote hosting holding all my repositories for public pulling, and ssh for pushing. Here is how to create it:

local$ ssh spectra@remotehost
remotehost$ mkdir /var/git/myproject.git
remotehost$ cd /var/git/myproject.git
remotehost$ git --bare init
remotehost$ logout
local$ cd myproject
local$ git remote add remotehost spectra@remotehost:/var/git/myproject.git
local$ git push remotehost master
otherlocal$ git clone git://remotelocal/myproject.git
otherlocal$ cd myproject
otherlocal$ git remote add remotehost spectra@remotehost:/var/git/myproject.git
(hack hack hack)
otherlocal$ git push remotehost master

Now everybody can pull your repository at git://remotehost/myproject.git and you can push and pull to it via ssh. Note that you have to setup git-daemon, which is pretty straight forward. I am using it as an inetd daemon, but you can use it as a standalone one. Debian has a package which does just that.

Now, some people think logging in a remote server just to create an empty repository is too much. Well… repositories are just .git directories. It happens that you can “push” for the first time by rsyncing your .git with a remote host:

local$ cd myproject
local$ rsync -a .git/ spectra@remotehost:/var/git/myproject.git
local$ git remote add remotehost spectra@remotehost:/var/git/myproject.git
(hack hack hack)
local$ git push remotehost master

(Apparently you can “push” using rsync every time, but it’s regarded as wiser to keep your – probably – crappy local repository commits separated from the public repository… otherwise commit messages like “Please, don’t use this code” are likely to pop up everywhere 🙂 ). Now, I don’t know if this have side effects, but it works 🙂

Another thing to notice is that git is more directed at pulling than pushing. This may be because of its designer: the way Linus works is by pulling changes from others’ repositories and not by letting others push’em into his one. And this is another violation of POLS for most of the people, who is used to “commit” their changes into some remote repository. Rather than that, people using git would expose their own repositories in order to have it pulled by others.

I also agree with most of the git critics wrt git commands… There’s a lot of examples – and I am not going deeper in this – but I think it was a bad choice calling “checkout” what git does when told to “checkout”, for instance. Yes, I know… different tools, different ways of seeing it… but everyone was already used to what centralized SCMs call their operations, and I think it would only help git adopting same names for the same operations, and inventing new ones for those proper of decentralized operations. Anyway, once you get it (and I have not completely got it yet), it seems all flow as expected. If this adaptation fails, there’s still Easy Git to the rescue!

One last thing that I think contribute to the “git sucks” effect: git-svn. This is a great tool, but it was built from git’s point of view… Given it’s intended as a glue for Subversion newcomers, it would benefit more from being built from svn’s point of view. This was mentioned by a colleague developer in my company, when he just couldn’t understand why one have to git svn rebase instead of a simple update. So git-svn also suffers of the “bad command naming habit” git do. Of course, that given that you came from this environment (I am sure git and git-svn makes perfect sense for Linus & cia 🙂 ). I have not tried yet, but yap seems to be targeted on providing an alternative to git-svn.

10 Comments on Git basics: reversing the ‘git sucks’ effect

  1. spectra says:


    I know about Mercurial’s better user interface, but most of my development is in Ruby, and a major portion of Rubyists are using git, so it’s just easier to learn git’s clumsy user interface…


    Yes… I see your point. But git user interface has evolved a long way (it was even worse)… So, let’s just hope it keeps getting better (or less worse, I should say?).


    Right… I took git-svn as a migration tool, but I see that it might be just another git tool for people stuck with svn. I still have to better understand DVCS… you’re probably ahead of me in this 😉

  2. spectra says:


    I am pretty sure I haven’t said that. I said:

    … git is more directed at pulling than pushing.

    By that I didn’t mean you should ssh to a remote site and pull stuff from your laptop… That scenario is actually a good use-case for push. Rather, I meant other people would be more confortable pulling from your repository than allowing you to push into theirs (I even speculate that git might be this way because Linus does just that).

    I also said git re-used command names from the “centralized SCM world” for different operations, and that that might be a problem for people doing the transition (myself included).

  3. spectra says:


    Right, maybe I am mistaken about git-svn, since I took it as a migration tool. Surely it fits more in the category “I love git but sadly I am stuck with svn for now” tool 😉

  4. matt says:

    theres another way of creating a remote repository:

    cd repo
    git clone --bare . /tmp/repo.git
    scp -r /tmp/repo.git matt@remote:/home/git
  5. ulrik says:

    Is git-svn a glue/help for subversion newcomers? Or just a power tool for git fanatics? 😉 I’m deep into the hacker/git-hardcore culture, and can’t stand DCVS without rebase, stash, internal branches etc

  6. aNaRcHy RuLeS says:

    Fuck the UI! Git repository is the best!

  7. raphael says:

    I am sure it’s not going to be easy to ‘reverse the git sucks effect’. Have you read ?

  8. Martin Geisler says:

    May I suggest you take a look at Mercurial? I’ve been using it for two years and compared to the Git tutorials I’ve read and the very little experimentation I’ve done, I find its commands more intuitive.

    With Mercurial you can clone a local repository to a remote repository over SSH:

    $ hg clone . ssh://spectra@remotehost/some/path

    You can then add an alias to .hg/hgrc for easy pushing in the future, something like

    default-push = ssh://spectra@remotehost/some/path

    if you want the newly created clone to be the default destination.

  9. I don’t think people who want to push their repos are too used to centralized SCMs. Pushing or mirroring my local repository is the only way I can make it accessible to others, since my laptop is (a) not always online, (b) has no fixed IP address, and© is often behind NAT. For the very same reason it can be hard to ssh into a remote server and git pull from your laptop.

  10. Thomas says:

    I thought git had a reasonable documentation. If the manual is tedious, the crash-course seems to work well and links to the manual section about setting up remote repositories. Sure, it has a certain tedium to it, but to be honest, the few times I had to do this it didn’t bother me. It’s certainly the easiest part of providing a repository with something of interest to others (compared to generating the content.) Also, I think you’re mistaken about git-svn. It is meant for people too used to git to use the svn client. If you want something to work like svn(1), “svn” is your choice.

Leave a Reply

Your email address will not be published. Required fields are marked *