Re: RFC: Subprojects

From: A Large Angry SCM <gitzilla@gmail.com>
Date: Jan 14, 2006, 20:30 UTC
Message-ID: <43C95F69.7090200@gmail.com>
In-Reply-To: <Pine.LNX.4.64.0601141154590.13339@g5.osdl.org>

Linus Torvalds wrote:

Show 23 quoted lines

> 
> On Sat, 14 Jan 2006, A Large Angry SCM wrote:
>>So far I've not seen any convincing arguments why the sub-projects can not be
>>managed by the Makefile, or equivalent, of the super-project. Particularly
>>when the sub-projects have a life of their own.
> 
> Now, from a developer standpoint I actually agree with you. I find 
> sub-projects totally useless - I'm much happier just having separate 
> trees.
> 
> The advantage (as far as I can tell) of sub-projects is not that they are 
> easier to develop in, but that it's a total nightmare for the technical 
> _user_ to download ten different projects from ten different sites, and 
> configure them properly and install them in the right order, and keep them 
> up-to-date.
> 
> There are projects that I simply gave up even trying to track: I wasn't 
> interested in being a developer per se, but I _was_ interested in trying 
> to test and give feedback to the current development tree - but it was 
> just too damn confusing to get it working.
> 
> If I could have just done a "git clone <top-level>" to get it all, I'd 
> have been a much more productive user.

$ make get_sub_components

This can work with most any SCM (depending on your environment), is amazingly flexible, and does not require special support in the SCM.

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

Show 7 quoted lines

> 
> This is why I think sub-projects are more about "git checkout" and an 
> automated "git fetch" than anything else. Doing actual development etc you 
> can easily do one project at a time. "git diff" and "git commit" wouldn't 
> need any real ability to recurse into subprojects and try to make it 
> seamless. And if you do a "git pull" that needs to do anything but 
> fast-forward, you might as well resolve the sub-projects one by one.

And all of this can be done today, without changing git, with more flexibility, with Make rules.