Adventures in git

I’m sure this isn’t news to a lot of you, but git is seriously cool.

I just discovered it this past week (after hearing a little about it once in a while since it started in 2005). I was mostly happy with Subversion (SVN) and CVS (before that)… but git is just way cooler due to its distributed nature, among other nifty things. It’s extremely fast, has easy tagging and branching, features amazing merging and patch management, and the repositories it makes take up very little disk space too. Also, due to being distributed (and having excellent management features), it makes working on a custom branch — even when offline — not only possible, but a total breeze compared to most other SCM / version control software.

People have also made git work pretty well with other software of its kind, most notably CVS and SVN so that one can work in git locally and publish changes to more traditional repositories.

Starting the adventure

My own foray in using git initially started just the other week when Nat was telling me all about it. I decided to take the plunge into git this past Friday.

To familiarize myself with this new version control software, I imported a project I am currently working on into a git repository (building up versions from pieces of snapshots I made at different stages), and worked on learning the basics through some pretty nice tutorials.

Benefits, already!

Using git seriously paid off. Late Friday evening, I upgraded some upstream software I had been using and it broke my project… I knew it must’ve been a simple one line change, but I didn’t know where exactly. This was, of course, right before I left the office for the three-day-weekend.

On Saturday, I wanted to get things working again — including all the new upstream changes (you know, bug fixes and what-not), but I did not have a ‘Net connection. Thankfully, it turns out git came to the rescue, due to its distributed nature.

Essentially, using git meant that I had my own little (very) compact repository with all of my changes, so I could check out old versions of files, examine changes, look at differences between my own tagged “releases”, and commit any change I wanted — all locally, without a centralized server or any sort of network connection.

Voila! I found the problem… it was, indeed, a simple one liner that made assumptions that weren’t true on my system. I fixed it, committed the change, and had everything working once again… all on my laptop, without access to the outside world.

My deciding to play around with this new version control system turned out to be quite fortuitous and timely. I really don’t know how I would’ve tracked down and fixed the simple, hiding show-stopping bug (especially without a network connection) so quickly and easily otherwise.

git more info…

If git sounds interesting to you, I’d suggest you check out the following:

git-ting to the point

It does take a short while to wrap one’s head around git (and make it second nature), especially if you’ve used CVS or SVN for so long, but the benefits make it totally worth investigating and trying out.

Tags: , , ,

8 Responses to “Adventures in git”

  1. While I haven’t used Git much yet, I was disappointed to see that a lack of good support on Windows took Git out of contention for use in the Mozilla version control shoot-out (they’ve gone with Mercurial for now, with plans to re-consider in a year or so). I think the same issue kept GIT from being considered for the Pidgin project (they’ve gone with Monotone). Both projects (Pidgin and Mozilla) seem to have come to the conclusion that distributed is better than centralized, but the choice isn’t so obvious even after you’ve settled on distributed.

    While all of this competition between version control systems probably has benefits, I’m really hoping to see a shake-down that leaves us with one major system as the defacto VCS for open-source software. The CVS/SVN split isn’t too bad, considering how similar they are to use, but figuring out Monotone for one project, Mercurial for another, Bazaar for another, and GIT for another can become a significant hurdle to participation in free/open-source projects.

    Good to hear about your experiences with GIT though.

    While we’re discussing version control systems, it’s worth noting that they are good! The statement is ridiculously obvious for anyone who’s worked on a software project, but version control can also have a significant benefit for visual designers as well. VCS is critical for managing all of the icons, sizes, formats, and changes in a project like Tango or the Gnome icon themes. It’s just as helpful for managing source files (Inkscape SVG, Photoshop PSD, Gimp .xcf, etc.).

    Also, I think we pixel-nerds are going to have to give up the G-I-T acronym we’ve been using for Gnome-Icon-Theme.

  2. garrett says:

    Steven: I agree fully.

    I’m exploring git with the intention of using it for other projects in the future. When I told Jakub of my experiences with it, he replied that he’s happy with Subversion. It does work, and work pretty well (especially when compared to CVS).

    It is quite nice that we have options. What is really needed is some desktop framework that enable any app to have version control, either locally or remotely. I think something like git could do the job for the backend; it just needs some good UI in the file manager, graphics editing programs, document suites, and — well — why not everything else? (:

    git’s Windows support has gotten better (as in, exists now), but it’s still not as nice as on a *NIX (especially Linux). What a surprise, really, considering who made the system in the first place! jk (:

    Seriously, though, the more cross-platform something like this is, the better it is for everyone to use. Not everything needs to be cross-platform, but the more things are, the more people are using open source software. The more people are using open source software, the more likely they are to switch to an open source operating system that has all the open source apps they’re used to. (But you know this *g*)

    Still, not everyone has the luxury of choice when it comes to their operating system (company mandates, crucial only-works-on-windows-or-mac software, and technical hurdles are all still real reasons). Sometimes it’s also the necessity of making such great cross-platform software too. (Yay for Firefox,, Inkscape, Gimp, etc., etc.)

    The git / git naming convention is a little bit of a problem. If we change it, we should probably consider changing the Tango Icon Theme as well, as it’s not exactly P.C. (although, neither is “the Gimp”).

    Perhaps we can use French. “Thème d’icône de GNOME”. Nah.

  3. GIT and Mercurial are very similar as they were developed both by kernel developer (Linus and Matt Mackall) at the same time, both taking the good lessons from monotone (changesets identified by cryptographic hashes) but aiming to be fast. In fact both are very fast, sometimes with different tradeoff for different usecases (GIT has faster checkout, mercurial faster diff and annotate).

    The article by Keith Packard said that mercurial is not very robust relying on truncate() which is supposedly full of bugs but, as Matt said in, the usage of truncate() in mercurial is very simple and safe (not counting that truncate bugs are now mostly fixed 🙂

    So the choice between Mercurial and GIT is mostly a question of feelings: while GIT is more like Perl (There is more than one way to do it), Mercurial is more like Python (There should be one—and preferably only one—obvious way to do it). Of course, being written in Python, this is only a coincidence 😉

  4. Andy Wingo says:

    I’m sure people have mentioned this to you, but the benefits you describe are not specific to git; most modern distributed version control systems have them. You should check out the others before settling on one 🙂

  5. garrett says:

    Andy: Yeah, BitKeeper has had things like this for a while. I’ll look at others too, although git has a lot of community traction now, and it’s quite nice. Switching from CVS to SVN was nice, and for many of the things I work on at Novell, using git is much nicer than SVN.

    Looking at bzr, Mercurial, monotone, etc. for future endeavors will be useful too.

    My main point of the post is that distributed version control systems are awesome and saved me a lot of extra work and frustration. I used git in particular, but as you point out, pretty much any good distributed version control software would also have worked.

  6. Dscho says:

    Emanuele: as with Python, there are many ways to do the same thing in Mercurial. It is an Urban Myth, which is purported over and over again that Python allows you to do one thing only one way. Somehow, by this repetition, people seem to believe it. But that does not make that more true.

    As for Git, there are only a few things which you (the user) can properly do in several ways. Yeah, many things can be done using the low-level programs which are meant for Git. But then, you can edit _anything_ with a hex editor. Even with Mercurial or CVS.

    Especially with the recent UI enhancements in Git, I don’t see at all how Mercurial should be simpler.

  7. Dean says:

    You should check out monotone. I’ve used it quite a bit. Although it has its limitations, it’s far more useful than others I’ve tried.

  8. […] Linuxart » Blog Archive » Adventures in git (tags: svn tools git) […]

Leave a Reply