Re: RFC: Subprojects

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Jan 16, 2006, 05:06 UTC
Message-ID: <Pine.LNX.4.64.0601152248030.25300@iabervon.org>
In-Reply-To: <46a038f90601141628n2ec32e8fy7fc23d8d7884c0f2@mail.gmail.com>

On Sun, 15 Jan 2006, Martin Langhoff wrote:

Show 25 quoted lines

> On 1/15/06, Junio C Hamano <junkio@cox.net> wrote:
> > > 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.

But most of the content of the project that started this thread is the revisions of the subprojects. Sure, it could all be done in the build system, but then it becomes impractical to manage. Git could refuse to support tracking the executable bit on files, or what directories things are in, and we could tell people to use their build systems to set these things, but it would make the tool impractical to use. We want to track some metadata, because it's actually important; what we don't want to track is the metadata that is local to the particular working tree. That's why we track only one executable bit, not a full set of permissions; it's a matter of local policy who can interact with the files in a working tree, but it's part of the content whether a file is executable.

So the problem with handling subprojects with the build system is that it is too tempting to use the revision control system directly on the subproject, at which point the thing you're developing and testing isn't at all what other people will get if they check out your commit. You want "git status" to report it as an uncommitted change if you have a different revision of the subproject than your previous commit had, and it can't tell if this information is buried in the build system.

I like Linus's proposal: which revision of which project goes where is part of the content, while how you manipulate data for that project is a matter of local policy, and is not tracked, although it might be a good idea to let project provide overridable defaults (so that, if you're a random member of the general public and don't have a special method for accessing the repository, you don't have to track it down yourself).

The tricky question is whether we should permit the "subproject" objects to specify a revision that isn't a hash, for use in identifying revisions of subprojects in other systems.

	-Daniel
*This .sig left intentionally blank*