This post originated from an RSS feed registered with Java Buzz by Bill de hÓra. Original Post: Git the inevitable? Feed Title: Bill de hÓra Feed URL: http://www.dehora.net/journal/atom.xml Feed Description: FD85 1117 1888 1681 7689 B5DF E696 885C 20D8 21F8 Latest Java Buzz Posts Latest Java Buzz Posts by Bill de hÓra Latest Posts From Bill de hÓra

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 cantral 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.

Versioning
 
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.