Re: RFC: Subprojects
- From
Petr Baudis <pasky@suse.cz>
- Date
- Jan 17, 2006, 14:09 UTC
- Message-ID
- <20060117140937.GI28365@pasky.or.cz>
- In-Reply-To
- <7vfynnfkc8.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Tue, Jan 17, 2006 at 07:18:47AM CET, I got a letter where Junio C Hamano <junkio@cox.net> said that...
Show 22 quoted lines
> Here again I am thinking aloud, remembering the earlier example > of an embedded linux project that ships with linux-2.6 and > gcc-4.0, along with its own README and Makefile at the toplevel > and src/ for its own sources. The tools at the tip of "pu" > should be able to let you do the following: > > $ git cat-file commit $such_toplevel_commit > tree $tree > parent $parent > bind $primarysub / > bind $linuxsub linux-2.6/ > bind $gccsub gcc-4.0/ > author A U Thor <author@example.com> 1137392543 -0800 > commmitter A U Thor <author@example.com> 1137392543 -0800 > > An example. > > where $tree is the object name of the whole tree (no "gitlink" > object), $primarysub and $linuxsub are the object names of > commit objects for the primary subproject (which sits at the > rootlevel) and another subproject (which sits at linux-2.6/ > subdirectory).
I perhaps missed this in the thread, but is it really so useful to bind the subprojects to specific commits? If you care about reproducing specific configuration, all you have to do is tag and seek recursively - and even having a separate tiny git branch tracking just a single file listing the commit ids of subprojects seems more elegant to me than just forcing the specific commit ids. In the general case, I think it most usually goes "this project#branch, the latest commit you can get", so I'm not really convinced that you are optimizing for the right case at all.
-- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ Of the 3 great composers Mozart tells us what it's like to be human, Beethoven tells us what it's like to be Beethoven and Bach tells us what it's like to be the universe. -- Douglas Adams