Distributed bug tracking

The local commit thing means that (a) you can use the version control system to checkpoint
states where you've done some good work, but it's currently broken as a whole, and you're
about to risk totally messing everything up; (b) you can commit your state before resolving
conflicts with other people's work, so you can retry resolving if you mess up in your first
attempt and lose all your work; (c) you can look at what you've committed and realize that
it's ugly, incomplete, or something like that, after you've put together exactly what you're
planning to send in but before you send it; (d) you can do a dozen related commits, each
self-contained, and as a set leading up to the last one, which adds a feature, and you can
deliver the set together; (e) before you submit a series, you can reorganize it into small,
clean commits that total the big chunk of work you've done.

My experience is that centralized systems lead to commits that each make all the changes
necessary to implement a feature, but touch a lot of different parts of the code, while
distributed systems lead to small focused commits, which are separate changes but all arrive
at once.

> Still nobody else can see the 
> code, so there is no peer review yet

Linus amongst others would argue that is a major benefit of DVCS.  Sometimes a programmer will
have an idea which they want to be able to play with without telling the whole world about it
- which is what happens if you create a branch in SVN. 

Good reasons for keeping code private, at least initially:

* The idea may turn out to be impractical or stupid.  In that case you won't upset anyone
because nobody else knew about it and you won't leave 'dead-end' branches lying around in the
main repository.
* People may appreciate the ability to work on something for a while without subjecting it to
criticism until they are ready.
* There may be competition within the project or in competing projects. 
* The code might not be suitable for inclusion in the main code base - it might be a
modification of the software to meet the needs of a specific company for example.  

In addition to secrecy, there is also the case where developers want a branch to handle their
specific needs which are not useful to anyone else.


> Doesn't this encourage big commits later on to the official/main 
> tree, which are too big to understand easily ?

Not necessarily - because users can easily browse the history of the merged branch and see the
individual changes which went into the final merge.    

One big practical advantage of course is speed.  Branching, merging and viewing history can be
very slow in SVN if the server is under load.  In git/bzr etc. creating a new branch is
instant and checking it out normally takes only a few seconds.  Merging is also trivial and
again takes only a few moments in most cases and it isn't affected by what is going on at the
remote end.  Being able to get a near-instant log is also very nice.  Having to wait two
minutes for "svn log" to fetch the history of a particular file is pretty frustrating.