Git != A Git
April 15th, 2008 by bennyYeah its been a while, but hey, its what i do. A lot a lot has happened since the last post (I’m apparently not a loser, who knew?) but I’m going to be lazy and leave you guys hanging and talk about random crap.
So recently, I’ve been on a total nerderiffic mood recently. “But benny, aren’t you always a nerd?” Good point, but believe it or not its even worse than usual.
Since discovering http://open.blogs.nytimes.com, I’ve been reading a lot and the most recent thing that I’ve come upon is a version control system called ‘git‘. I found a google techtalk and also read somewhere that Ruby on Rails is moving over to git, i thought it was worth a look.
Anyway, after listening to him talk, some reading, and messing around with git, I’m convinced its the right vcs for me (and you) and I havent even tried it!. Here are two points really stand out to me and just make sense:
- Distributed and relatedly Local Commits - description here. Now, not having a central repository might seem weird at first, but if you think about it a bit, it kind of makes sense.
Having a centralized respository, as with subversion or CVS, means that any code you want to track will reside there. Thats all fine and dandy and I like that because there is a central place where my code resides. But what about the situation when you’re messing around with your own code and experimenting, but also want to keep track your changes. In svn or cvs, you would have to create a branch, track your changes there, and somewhere down the line, merged it all back together.
That, to me, seems very silly. I don’t see the need for my experimental changes, which I may very not use in the future, to be forever reside in the central repository. It dirties the repository and wastes space. I should be able to branch on my local repository, track my changes, and when the time comes, decide whether or not to merge them into my main branch.
But what if you want a “main” public repository that will have the de facto version of the code? That is also possible (and easy!) in git. If you do a quick google for “git public repository“, you find help in no time.
Linus also makes a valid point that if you’re disconnected, ie. on an airplane, there’s no reason why my revision control software shouldn’t be able to keep track of my code changes. Isn’t that the whole point of a VCS! In svn/cvs, the only way to commit changes is if you can access the repository, which can be extremely inconvenient. I want my vcs to track my changes, no matter where/how connected I am. period.
- Separate orthogonal changes - have you worked on a project where you were making two independent changes? No? Well, that’s ridiculous
Anyway, for the rest of the 99.9% of people who have, a problem with most VCSs is that it is either: an atomic commit of the working tree, or atomic commits based on files. Let me explain.
In svn, if you do aI stand corrected. I guess I haven’t used subversion (or forgot it :P) enough. whoopssvn status, it shows you all the files you have changed. If you have more than one logical change, like a new feature and a bug fix, you have to commit them at the same time (as far as I know, let me know if not!). So all the changes that you’ve made, whether they’re related or not, is committed. This doesn’t seem very logical to me. What if I wanted to put in the bug fix first before I polish the new feature a bit. I’m not sure how I would do it with SVN without some manual fiddling around.
This is partially solved by other VCSs, such as Perforce (what we use at work). In Perforce, there is an idea of “Changelists”. Changelists are lists where you can separate the files that you want to commit. Like in the example above, the files that are affected by the bug fix can go into one changelist, while the new feature can go into another one. Then I can commit the bug fix without having to commit the changes I made for the new feature.
But yes, there is even a problem with that! What if those two changes affect the same file? How can you commit the changes for the bug fix, without partially submitted some changes associate with the new feature? File level commits aren’t good enough.
Git to the rescue! Git allows you to pick and choose what content, not files you want to commit to the repository. Git lets you pick the changes you want to add to your index (which is like a changelist) before committing them. Controlling what content is committed, rather than the file, is much more logical to me.
There are many more things about git that are really pretty great, but those are the two that are most iimportant to me. Git’s popularity has been gaining momentum since Linus’ talk so I’m sure if you look around, you’ll find that a lot of people love a lot of different aspects of git, so I suggest you at least take a look at it if you’re using any type of source control.





