Re: git versus CVS (versus bk)

[Joel Becker <Joel.Becker@oracle.com>]

On Mon, Oct 31, 2005 at 08:18:49AM -0800, Linus Torvalds wrote:
> With git (or with BK, or any truly decentralized model), you just make 
> your own repo, do your development there, and you never need to ask for 
> permissions from the central repo people. If the development works out, 
> you just ask people to merge back. And if it doesn't, you don't even have 
> to tell people what a total failure you were.

	Actually, Linus, this provokes a question I've always wanted the
answer to.  I'm well aware of the centralized/distributed stuff you are
discussing, but there is policy regarding the distributed merges I've
never been quite clear on.
	When one does a feature branch, one creates a "throw-away"
repository.  They work on the feature, and when they are done, they
pull/push back to the main repository.  This pattern is pretty much
identical in both centralized in distributed environments, even if the
nuts-and-bolts are different.
	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.
	In the distributed world, a pull of the "feature" repository
pulls in all changes - the full history of the work.  This includes
aborted tries, rewritten pieces, bug fixes, etc.  Here, the main
repository has the detritus of the development process, but that also
contains the full context of the work.  It goes against your claim that:

> 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.
	But that's not how the kernel and git appear to work.  Many
developers have popularized dropping that context.  They take their
working repository, diff it against your mainline repository, and then
create a new repository that is merely your mainline plus one commit,
the patch of their changes.
	This violently breaks the model of "work in a new repository,
then have it pulled into the 'main' repository."  It has no real support
in the git/cogito command space (that I know of).  It does, however,
leave all the intermediate commits out of your tree, with only a feature
commit remaining.
	Where do you stand on this?  Would you rather see the full
history pulled?  Do you prefer the one-clean-patch approach?  If so, is
there any way to get a cogito/git command for it (git-pull-as-one?)?

Joel

-- 

"Drake!  We're LEAVING!"

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127