Re: git versus CVS (versus bk)

From: Linus Torvalds <torvalds@osdl.org>
Date: Oct 31, 2005, 21:35 UTC
Message-ID: <Pine.LNX.4.64.0510311323090.27915@g5.osdl.org>
In-Reply-To: <20051031195010.GM11488@ca-server1.us.oracle.com>

On Mon, 31 Oct 2005, Joel Becker wrote:

Show 8 quoted lines

> 
> 	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.

Show 5 quoted lines

> > 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