hoi :)

On Fri, Apr 20, 2007 at 09:31:42PM +0200, Sam Ravnborg wrote:
> On Fri, Apr 20, 2007 at 04:14:01AM -0700, Junio C Hamano wrote:
> > 
> > Making git.git the first guinea pig has a unique bootstrapping
> > problem involved, however.  These kind of changes in git.git
> > itself has to wait at least until what we have in 'next' today
> > is in everybody's hands.  Otherwise, people who want to use git
> > for their real work need to first grab a tarball snapshot that
> > has the plumbing subproject support, and then update to
> > 'master', because we are still too fast moving for any distro
> > binary packaged version to be satisfactory solution for people
> > who want to have all the bells and whistles.  Also, I cannot
> > have subproject in git.git until kernel.org starts running git
> > with subproject support -- otherwise nobody can clone or pull
> > from git.git X-<.
> 
> The bootstrapping issue could be fixed by having a separate
> git-subproject.git on kernel.org.
> 
> But I see no easy solution for the requireent for kernel.org to
> a new git (and I doubt kernel.org sysadmin is too keen to
> update to a next-based git).

Well, it only needs to be new enough to understand enough of
submodules so that it can play the server part.
So once we are in that part to be stable we can merge it to master,
so that kernel.org can use it.
Full submodule support should then mature until the next major version
after which git.git could use it itself.

-- 
Martin Waitz