Re: git versus CVS (versus bk)

On Mon, 31 Oct 2005, Joel Becker wrote:

	In the CVS/Subversion world, this merge becomes a single commit
on the "main" line of development ("trunk", or whatever you call it).
The merge has no concept of the steps taken to create the change, just
the actual patch.  This has the disadvantage that you have to work hard
in the branch namespace to find the actual steps taken (the working
repository for the feature), but the advantage that a quick look does
not have to wade through fits and starts as the feature takes shape.

Note that I'm a big proponent of people cleaning up their private 
work-in-progress trees before merging.

In fact, I'll refuse to merge with too dirty a repository. It's ok to have 
some fixes for mistakes, but if you have a lot of ugly stuff, use git to 
first track the development, and then start a new branch that has the 
cleaned-up version in it.

quoted

So with the distributed model, you don't have to publicly humiliate 
yourself when you do something stupid. Similarly, you don't have to 

because that history will contain all your something stupids, plus your
fixes for them.

No, exactly because you do _not_ have to publicly humiliate yourself with 
showing what a nincompoop you are.

People should try things out, but they should clean up their worst 
mistakes too. Git allows both.

		Linus