Hacker News new | comments | show | ask | jobs | submit login

Because you no longer have to think much before committing. You don't have to spend hours reviewing the code and having others look over the patch before you push it to the main tree: you can just commit it locally and go work on something else.

Then, later, you might get an idea on how to improve your previous change. You go and amend it. And so forth. Eventually, you have a set of changes that's ready to be committed and which you have used locally for long enough that you can tell it doesn't break anything obvious. Then, you go through the code review, and finally push the changes.

With a completely centralized system, you have one of the following going on:

A. You don't actually do code reviews before pushing changes, and trunk is broken half the time.

B. You wait all the time on your changes being reviewed, and you can't commit them until they have been.

C. You revert to tarballs and diffs for dealing with different changesets.

I was forcibly pushed into using git from svn, but now I'd never go back: its simply so much easier to say "OK, I'm done with this change, I'll commit it!" and not have to wait for everyone else to be in the office/online/available to look at the changes before I do so.

This is especially important when dealing with separate changesets that necessary depend on each other, where you can't merely make a new branch for the new change because it requires the old changes.

Thanks for the reply. That certainly explains some clear benefit. That's the first time somebody's laid out for me in that fashion.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact