Friday, September 28, 2007

First impressions of git

So far, I like git a lot. My favorite feature is branches, and the goodies that come with that, such as git fetch, which pulls patches from a remote repository into a branch. I like using git add to flag files to commit more than the darcs "cherry picking", which is tedious and error-prone. I also like it how git status shows me any files which have not been added yet.

The gitk GUI, while not great, is a nice way to get an overview of what's going on with the repository.

Of course the best thing about git is the speed. The Linux Kernel developers use git, and they have a huge codebase with many developers. I'm confident that I've made the right choice by switching to git.

One thing I don't like about git is the complexity -- there are hundreds of commands and it certainly seems like the user interface could be simplified, for the common operations anyway. I'm slightly worried that the increased learning curve might be a hindrance to getting contributors in the future. However, having to wait 10 minutes to darcs push is a turn-off to contributing in itself.

3 comments:

Anonymous said...

If you like git cherry picking, you should have a look at git rebase -i (for --interactive). Interactive rebase allows you to edit, squash (combine), remove, and reorder existing patches on a branch.

About complexity... as all things that have a steep learning curve, you will find that git just get better and better as you learn more commands.

-Bart

Anonymous said...

Like any new utility these days, the more flags waving, the more defense given for their existence.

Not saying that git embodies this, but it seems that tools now expose so much as to always need a reference at hand.

Anonymous said...

Could a very small, simple, and useable subset of Git be abstracted with Factor words, as in the Factor interface sends command line arguments to a Git executable? Or would that be a waste of time compared with just learning Git?