Re: What's cooking in git.git (topics)

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:

quoted

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