I had been putting it off, but it looks like I'll have to dive into Git some more.
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.