git is rapidly shaping up to be a wonderful source code control tool. I've been using it at the "bare metal" layer since it was created to do kernel work with, and played around with some of the other programs that use it to make it more "user friendly".

I'm using it to keep all of the different documentation I've written in the past (that used to be in a bk repository) and even use it to store my old, archived email tree (at 2.2Gb uncompressed, it isn't small). And I'm using it for my latest book work, as it makes working from any of my different computers a piece of cake (just update the tree and go.)

But for a lot of people, the way git handles branches is a bit strange. If you are one of them, take a look at this explanation from Linus on the git mailing list. It clears things up a lot and touches on the power that the different branch format contains within git itself.

It also shows the kind of support some open source projects can provide to just any user that happens to want to learn more and asks very good questions. Try doing that with a commercial product without spending a lot of money on support contracts...

Note. Please don't bombard me with things like, "but use distributed subversion", or "mecurial is so much better", or "arch is the only true way". That's fine, it's nice to see other SCMs get activly developed and get better, it's just that due to my kernel development work, I've grown to really like git as its workflow matches mine quite well.

posted Wed, 11 Jan 2006 in [/diary]