Re: RFC: Subprojects

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Jan 15, 2006, 00:28 UTC
Message-ID: <46a038f90601141628n2ec32e8fy7fc23d8d7884c0f2@mail.gmail.com>
In-Reply-To: <7vk6d2fsu6.fsf@assigned-by-dhcp.cox.net>

On 1/15/06, Junio C Hamano <junkio@cox.net> wrote:

Show 12 quoted lines

> > The "get" rule for each sub-project could be something like:
> >
> >       git_sub-project:
> >               mkdir sub-project
> >               cd sub-project
> >               git-init-db
> >               git-fetch <fetch-options> <repository> <refspec>
> >               git-checkout <branch>
> >               $(MAKE) get_sub_components
>
> There lies a drake here --- <repository> is not the same for
> everybody.  It is not a big showstopper dragon, though.

Well, that /little complication/ applies to doing it in git too ;-) There's no way to tell how the dev doing the top level checkout has access to the subproject repos.

I am with gitzilla on this one. Let the projects have their own bootstraping mechanisms, using make, ant or whatever catches their fancy. One of the great things about git is that it doesn't assume that it's being used by all the projects in the world -- thanks to Linus' disregard for arbitrary metadata and to your git-cherry implementation, it's all about the content -- and so it interoperates great with Arch, SVN, CVS, etc.

Having intra-git subproject support assumes that the subprojects are all in git. Heh! That covers about 0.001% of reality out there. Per-project bootstraping scripts will use whatever tools they need for the checkout.

Automating the 'checkout' stage for git subprojects is trivial, and I'd argue not interesting enough to try and solve within git, specially when most subprojects are going to be using a different SCM anyway. And all the *interesting* operations (branch, commit, tag) are perhaps indeed interesting problems to solve, but definite misfeatures in a tool that tries to be sane and minimalistic.

IOWs, adding some repo metadata describing subprojects is the wrong thing to do, just like tracking patches via metadata would be the wrong thing to do. It's all about files -- which git handles masterfully.

cheers,

martin