Re: Why do git submodules require manual checkouts and commits?

From: skillzero@gmail.com <skillzero@gmail.com>
Date: May 19, 2008, 04:38 UTC
Message-ID: <2729632a0805182138s3e268cdbxd0d7c42bbcf01f84@mail.gmail.com>
In-Reply-To: <32541b130805160643y3bfe609et22b2d00627f98c04@mail.gmail.com>

On Fri, May 16, 2008 at 6:43 AM, Avery Pennarun <apenwarr@gmail.com> wrote:

Show 8 quoted lines

> The main reason the simple approach you suggested (just link to a
> branch instead of a particular commit) isn't good is that it doesn't
> guarantee you always get the same version every time.  If the
> supermodule links to submodule branch "foo" and makes supermodule
> commit 23abc918c, and someone later pushes to submodule branch "foo",
> then checking out commit 23abc918c in the supermodule would get the
> very latest submodule "foo", not the one you had when 23abc918c was
> created.  Thus all sorts of bad things could happen.

It seems like this could be handled by changing the way a commit is tracked such that it also includes the commit hash of the submodules. So for example, instead of refs/heads/master just being just a single commit hash, it would be a list:

[refs/heads/master]
       1033bb1ed64d1dbac9f93360e69402195386d145
       libfoo = a13dcb7f26a160d85038385b3024b700dec208d9
       libbar = 123123123dcb7f26a160d85038385b3024b700de

If I commit a change to libfoo, it updates libfoo's commit hash to the latest. If I do git pull on the supermodule, it recursively does git pull on all submodules and then updates refs/heads/master (or whatever branch you happen to be on) with the new commit hashes of the submodules.

If you checkout supermodule commit 1033bb1, it would look at the supermodule's refs/heads/master for 1033bb and see that libfoo was at a13dcb and libbar was at 123123 and it would then check out those commits, respectively.

If you branch the supermodule, it recursively branches the submodules with the same name, but using a namespace. Maybe super/<branch> similar to how origin/branch is use for remote branches.

If you push the supermodule, it would also recursively push the submodules using the URL specified when it was cloned (i.e. the one specified in the .gitsubmodules file).

What I'm trying to do is use git to manage multiple, large repositories that share a lot of code. I want to make things more sparse so independent pieces can be used standalone or included as submodules in other, larger projects.