Thoughts on Git

[Gregg Bolinger]

I'll admit that I have a habit, good or bad, of looking into buzzy technology. Right now there is quite a bit of buzz around Git. If you don't know what Git is, go find out. I'm really looking for feedback from folks that have tried it or have also been reading about it, as I have.

I have a very small project that I work on about one evening a month. Its kind of my "try out buzzy things" project. I never put it in any kind of version control so I thought what the heck. I'll use Git. I played around with it locally for a while, not pushing to any kind of central repos or anything. I mean, that's one of the main points of Git is not having to commit over the network, which can be slow.

I then signed up for the free account at Github to see what the push cycle was like. I just don't know yet. To me there are 3 main aspects of version control that I think are most important.

1. Versioning - being able to roll back to previous releases, versions, what have you, is obviously a major aspect.
2. Backup - Having all the source code on a server that is being backed up daily just makes me feel all warm and fuzzy.
3. Getting other developers code easily - Grabbing the latest code from a repos is a breeze so I am always up to date with Johnny's latest work, assuming he checked it in.

With Git, you get that. The part that I am battling with is committing to a local repository, and often. When I get on a coding rampage its hard for me to stop what I am doing and commit code. With typical version control this makes some sense because depending on your network this can be slow. Ok, its not that slow. But it *is* slower than committing to my own machine.

Using Git I am supposed to commit smaller chunks and more often. Then when I would normally make commits as I do now I would push everything to the remote repos. I suppose this is just unlearning one habit and picking up another. And I am sure there are a lot more legitimate reasons for using something like Git.

So...who is using it? Do you like it? Why do you like it? Any advice on making the switch? Was it easy for you? Also, has anyone heard of any IDEA plugin in the works that supports Git? I don't mind the command line but if I didn't have to leave my IDE to do something I'd be happier.
[ July 09, 2008: Message edited by: Gregg Bolinger ]

[Vilmantas Baranauskas]

Disclaimer: I've never used GIT and do not plan to use it in the foreseeable future, but...

You may consider changing your habit of committing random changes very often. Try to develop and commit on "per-feature" basis and write useful comments on commit.

By "per-feature" I mean, fixed bug #xzy, commit, implemented this-and-that, commit, refactored this-old-code, commit.

When you commit per-feature, then commit log files become more meaningful and your working style becomes more clear as well.

[Gregg Bolinger]

Originally posted by Vilmantas Baranauskas:
By "per-feature" I mean, fixed bug #xzy, commit, implemented this-and-that, commit, refactored this-old-code, commit.

When you commit per-feature, then commit log files become more meaningful and your working style becomes more clear as well.

But what if the "feature" required me touching 20 files. How could the commit logs possibly be meaningful if I try and check in 20 files at once? I think that's a bad idea regardless of the version control system you are using. However, it does solidify an argument for Git since if you commit to your local repos often the commits are fast and then when the feature is complete, push to the server which would be similar to your feature complete commit but the log files are pushed to the server as well so all your messages are quite meaningful.

[Vilmantas Baranauskas]

If feature required change in 20 files, then all of these files should be committed with a single commit and single message, e.g (in subversion).:
svn commit -m "Fixed bug #4657."

This allows you to revert or merge this complete commit easily.

Long time ago I've read very good article explaining why commit-per-change is better than commit-per-file but I cannot find it.

[Gregg Bolinger]

Originally posted by Vilmantas Baranauskas:
If feature required change in 20 files, then all of these files should be committed with a single commit and single message, e.g (in subversion).:
svn commit -m "Fixed bug #4657."

This allows you to revert or merge this complete commit easily.

Long time ago I've read very good article explaining why commit-per-change is better than commit-per-file but I cannot find it.

Well, lets not get off on that road just yet. I still want this thread to be about Git and less about version control in general. We can always start a new thread to discuss this kind of stuff.

[Tim Holloway]

Well, a major selling point of git is that it's the repository of record for the Linux kernel and carries Linus Torvald's personal blessings as best suitable for what they need to do.

I haven't worked with git, but for a while I was doing Xen I did use Mercurial for a while.

By and large, however, the old standbys suffice for me. I'm still mostly CVS, though Subversion is where I'm more likely to file new projects.