Re: RFC: Subprojects

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Jan 17, 2006, 16:45 UTC
Message-ID: <Pine.LNX.4.64.0601171122270.25300@iabervon.org>
In-Reply-To: <20060117140937.GI28365@pasky.or.cz>

On Tue, 17 Jan 2006, Petr Baudis wrote:

Show 9 quoted lines

> 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.

Think from a debugging standpoint. You know that the main project worked with a particular commit of the superproject. The bug you've found is related to the behavior of one of the subprojects in the the context of your superproject, but you don't know this. In order to reproduce the working version and search for the change that broken things, you need to be able to identify which commits of subprojects were used in each commit of the superproject; these are almost certainly not the latest commits on any branch of the subproject. And if you're going to want to debug things later, no commit of the superproject can just say to use the latest in the subproject. You don't know what you make a commit whether it will turn out to be a configuration that you'll want to recreate later.

Now it may be useful to have a tool to update all of the subprojects to the latest versions, similar in end-user usage to pulling repositories, but you still need to generate new commits when you do this, rather than reinterpreting the old commits with new content, so that you keep the history immutable. You also want to know when you've done this, so that you don't clone a tree that's working fine and build it only to find that the clone has fetched a new kernel version with different behavior without letting you know that anything has changed.

	-Daniel
*This .sig left intentionally blank*