Re: [RFC] Submodules in GIT

From: Shawn Pearce <spearce@spearce.org>
Date: Nov 28, 2006, 21:02 UTC
Message-ID: <20061128210211.GI28337@spearce.org>
In-Reply-To: <456C94E2.6010708@midwinter.com>

Steven Grimm <koreth@midwinter.com> wrote:

Show 9 quoted lines

> Andy Parkins wrote:
> >Unfortunately, during development, you've switched libsubmodule1 to 
> >branch "development", but supermodule isn't tracking libsubmodule1/HEAD 
> >it's tracking libsubmodule1/master.  Your supermodule commit doesn't 
> >capture a snapshot of the tree you're using.
> >  
>
> Or maybe not a merge, but worse, you'd *replace* the 
> previously committed master with what's in your dev branch.

Right, you would be replacing the prior branch of that submodule with the new submodule branch.

I think the safety valve you are looking for here is two things:

  * don't automatically update the submodule's HEAD into the
    supermodule's index.

  * make sure the submodule's HEAD is a fast-forward of the
    supermodule's index, with a --force option to force it
	anyway.

Otherwise the developer just has to know what he/she is doing. Today you can put stuff that isn't ready for prime-time into a repository on the wrong branch just by applying the wrong patch, or cherry-picking the wrong commit, etc... the user can (and will) make mistakes. But they can also easily recover from them by rewinding history and redoing it.

> On a related note, it would be great from a usability point of view if 
> there were a way to say "I always want to be on the same branch in all 
> submodules and the supermodule."

That's not really an issue.

A branch doesn't exist just because you checked-out the branch, or because you created it. A branch exists because there were two or more commits (B and C) which use the same parent (A) and two or more of those commits survive, e.g. they have refs which point to them (directly or indirectly) or they were merged into another commit which itself survives.

Therefore if the supermodule is on the "development branch" the submodules are also immediately on the same branch, because their HEADs are derived from whatever is stored in the supermodule's tree. And that tree is derived from whatever "development branch" means.

Really what you want/need is a special head in the submodule which acts as the "branch that corresponds to the supermodule". This probably should just be a naked SHA1 stored in HEAD, which is committable only because a supermodule exists in a higher level directory.

The fact that the submodule project has branches *at all* is totally irrelevant once you start to speak about that submodule within the supermodule, as its the supermodule which determines the branch of the submodule.

> But I think the Perforce-style 
> "compose a single workspace out of different bits of a larger project" 
> model is hugely useful

That's a mess.

You start to get into weird cases where the directory structure expected by the build process is no longer intact, because the user has sliced it apart in weird ways. And there's no single version which corresponds to that workspace as (if I recall correctly) you can pick different tags or branches at will. I believe that ClearCase has the same bug.

You also can't version that now spliced workspace, aside from taking the configuration file and putting that under version control too.

However I think the proposal on the table will support that to some degree, in that you can take any version of any repository and embed it at any directory of any other repository. This means you can for example embed the Linux kernel, glibc and gcc projects into a larger "embedded device" repository, but you cannot alter the structure of any of those three projects without making your own locally developed branch of them. Which is actually the correct thing to do as any subslicing of a repository is exactly that: a locally developed branch of that repository.