Git the inevitable?

I had been putting it off, but it looks like I'll have to dive into Git some more.

Peer pressure

I'm a big, big Mercurial fan (I think the command set is awesome and I think Git has some warts), but the ground up community drive and sense of urgency around Git is something else. I'll be using Mercurial for managing my own stuff and a few other codebases, but the social activity around Git I think means it'll be increasingly harder to function "from downstream" without knowing how to use it well. A few examples of things that have conspired to tip me over:

 - Jacob Kaplan Moss has served out a Git repository for Django. I've been managing local Django trunks via mercurial for a while now. Now I don't have to.
 - Scott Chacon's presentation (here's a PDF). Has the best explanation of how to map standard central models to DVCS I've seen. Scott also has a Git book on peepcode.
 - The Prags are going to ship a Git book. Prag books influence developers (their Subversion book was a godsend a few years back).

 - Ryan Tomayko likes it.
 - Google alledegly choosing git for Android. Assuming it's true (and it might not be, Perforce tools for modern Java IDEs are stellar), I wager Google code will support Git as a side-effect. Arguably DVCS is a better fit for that company's DNA than a central repository anyway.
 - git-svn seems to be far ahead of anything hg/svn related. This I think is the most important thing - it means Git will be the upgrade path to DVCS for Subversion repositories.

Finally, a long bet - automated deployment tools will be built on Git. Why? Well I think deployment is best modelled as a publishing problem and Git internally is closer to a versioned content management system than the other DVCSes (in particular the way it doesn't use deltas to manage files). Combine that with 

  • the pull/push features (publishing systems always need them)
  • multiway branch merging (which naturally supports the configuration-pulled-from-another-repository pattern)
  • it manages source code to begin with (doh!)

means (I think) someone eventually will see deployment as an extension of checkout/push instead of an entitrely separate workflow, and start writing command tooling around that. Also one thing a DVCS supports is end to end versioning by having the production systems (especially configuration) versioned in place. Let's not pretend otherwise - everyone has at sometime or another, patched a live server directly. Bad practice or no, when that happens a centralised VCS gives you no direction home - but a DVCS support bidirectional flow because the production server is just another branch.



    regarding the django-git repo.

    there has been a mercurial mirror of django-svn for a very long time at .

    i'm currently using mercurial, because i find that it does all that i need, with a nice and consistend command-set. git might be more powerful in certain areas, but i simply don't need that (the only thing i'm missing are in-repository branches).

    Git always seems to be more 'cool', with a bigger community, but there are also plenty of projects using mercurial, the big ones being mozilla or java for example (there's a full list at )

    also, the tradeoffs the git developers sometimes make seems to be quite strange for me (i wrote about it here , i'm not sure if it's still actual or not).

    @Regarding Google choosing Git for Android:

    IMVHO it is because large part of Android stack is Linux kernel, and 'canonical' Linux kernel version and almost all Linux kernel "trees" (repositories) are managed using Git.

    @About Mercurial vs. Git:

    IMVVVHO Mercurial is simpler than Git because it has less rich model to learn; this means some features are not available in natural way in Mercurial (it admittedly has better documentation than Git). I'm thinking here about multiple branches per repository and strange way Mercurial implemented tags, among others.

    Gabor, I agree with most of what you're saying (and I know about your hg repo, as I've pulled from it).

    "Git always seems to be more 'cool', with a bigger community, but there are also plenty of projects using mercurial,"

    I know about 'em. The point I'm making is that it's not just bloggers, it's tooling and information around Git seems to be growing at a faster rate than hg.

    Except that Google use Perforce. For Everything.


    sorry, i should have been more specific. i know about named branches. but i do not like them, because they 'contaminate' your history. in other words: in mercurial, named-branches are not simply pointers to changesets. in mercurial, named-branches are IN the changesets. so, if you ever create a named-branch called 'gabor', and create some changesets in it, then this named-branch-name ('gabor') will stay in the history forever.

    i would prefer more something like this "bookmark" concept (

    One of my friends who works on Android uses git for that, but he's working on the kernel:

    I assume they use the same p4 plus more for the rest of it. It'll be interesting to see what they promote when they open up the source to the rest of it. They want to encourage handset manufacturers and carriers to create their own versions of it so a DRCS makes sense. And perforce makes no sense for open source.

    > i would prefer more something like this "bookmark" concept

    But anyway branches are present in mercurial (I'm not talking about named branches), that's what you see typing 'hg heads'. They just don't have names.

    And yes, bookmarks would be nice to have.

    @About branches in Mercurial:

    IMHO *named* branches (to be able to refer to them easily locally) existing *outside commits* (so the names are purely local, not visible, and does not contaminate global branch namespace) is the sensible way to have multiple branches in single repository for distributed version control system.

    But perhaps I am a bit biased; I am Git user.

    Git is horrible.

    that is all.

    Seeing as you have to work with the evil that is Perforce there's even more reason to use Git. The git-p4 tool lets you easily push your git commits to your perforce repo without ever having to type "p4 edit", or any of it's other stupidity, again. It'll also pull in any changes that have been committed by others in perforce.