clarification on git, central repositories and commit access lists

[Adam Treat]

Hi Linus,

I just watched your talk on git and wanted to ask for clarification on a few points.  Many of us in the KDE community are interested in git and some even contemplate using git as the official SCM tool in the future.  However, I think a few issues have been confused and want to see if you can clarify.

Your talk focused heavily on the evils of a central repository versus the benefits of a distributed model.  However, I wonder if what you actually find distasteful is not a central repository per se, but rather designing an SCM that relies upon *communication* with a central repository to do branching/merging or offline development.

After all, your repository acts as a de-facto central repository of the linux kernel in as much as everyone pulls from it.  Without such a central place to pull the linux kernel would not exist, rather what you'd have is a bunch of forks which perhaps merge with each other from time to time.

For any software project to exist as opposed to a bunch of forks I think you *have to have* a central repository from which everyone pulls, no?  Of course many branches might exist, but those branches must pull from a central repository if they want to share *at least some* common code.

A central repository is also necessary for projects like KDE to enable things like buildbots and commit mailing lists.  These tools are important to the way we work and provide for many eyes constantly reviewing changes to the codebase as well as regular regression testing across diverse platforms.  In the future, whether git or svn, I see no advantages in getting rid of a central repository from which everyone pulls.  I wonder whether you really disagree.

In your talk you also focus on the evils of commit access lists, comparing and contrasting with the web of trust the kernel uses where you have no commit access lists at all.  However, isn't the kernel model just a special case?  The linux kernel has a de-facto commit access list of one: you.

This might work well for the kernel, but I fail to see how this really reduces politics.  Many are still constantly pushing and arguing to merge their branches upstream into your repository.  Would having a central repository where you and all your trusted lieutenants push their changes really be very different?

The KDE community has a very large commit access list and it is quite easy to join.  Having a central git repository with a large set of committers would seem to map well with our community.  I fail to see any harm in this model.  The web of trust would still exist, it would just be much larger and more inclusive than the model the kernel uses.  I wonder if you disagree.

Another sticking point is the performance implications of a git repository managing something the size of the KDE project.  I understand the straightforward solution: just define content boundaries with a separate git repo for each submodule: kdelibs.git, kdebase.git, kdesupport.git, etc, etc.  And then have a super git repo with hooks that point to these submodules.  However, I think this leads to a few problems.

What if I want to make a commit to kdelibs that will require changes in other modules for them to compile.  I will no longer be able to make a single atomic commit with changes to multiple submodules, right?  Also, won't we lose history when moving files/content between submodules?  And how will we break up the existing history between all of these submodules?

Finally, a couple points...  CVS/SVN might be stupid and moronic, but I think it is good to note they are not nearly as bad as some other SCM's.  Many SCM's used by some of the largest codebases in the world are still lock-based.  If you think it is difficult to branch/merge using a central server, remember that some poor folks can't even *change a single file* without asking the central server for permission.

It is also good to note that a free distributed SCM was not available until recently.  The kernel community might have had a special deal with BitKeeper, but the same didn't apply to all open source projects AFAIK.  When KDE moved to svn it was the best tool for the job.  That might have changed when git became easier to use, but at the time it was simply too big of a barrier for new developers and too new.  And from what I understand git support on other platforms is a recent development.

Cheers,

Adam