RFC: Making submodules "track" branches

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jun 7, 2010, 23:29 UTC
Message-ID: <AANLkTilBQPHgkCLJ7ppNo5TwC9Bdmqo-OMRpaDFwbQPd@mail.gmail.com>

On Fri, May 21, 2010 at 16:10, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

Show 54 quoted lines

> Add a $toplevel variable accessible to `git submodule foreach`, it
> contains the absolute path of the top level directory (where
> .gitmodules is).
>
> This makes it possible to e.g. read data in .gitmodules from within
> foreach commands. I'm using this to configure the branch names I want
> to track for each submodule:
>
>    git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'
>
> For a little history: This patch is borne out of my continuing fight
> of trying to have Git track the branches of submodules, not just their
> commits.
>
> Obviously that's not how they work (they only track commits), but I'm
> just interested in being able to do:
>
>    git submodule foreach 'git pull'
>
> Of course that won't work because the submodule is in a disconnected
> head, so I first have to connect it, but connect it *to what*.
>
> For a while I was happy with this because as fate had it, it just so
> happened to do what I meant:
>
>    git submodule foreach 'git checkout $(git describe --all --always) && git pull'
>
> But then that broke down, if there's a tag and a branch the tag will
> win out, and I can't git pull a branch:
>
>    $ git branch -a
>    * master
>      remotes/origin/HEAD -> origin/master
>      remotes/origin/master
>    $ git tag -l
>    release-0.0.6
>    $ git describe --always --all
>    release-0.0.6
>
> So I figured that I might as well start tracking the branches I want
> in .gitmodules itself:
>
>    [submodule "yaml-mode"]
>        path = yaml-mode
>        url = git://github.com/yoshiki/yaml-mode.git
>        branch = master
>
> So now I can just do (as stated above):
>
>    git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'
>
> Maybe there's a less painful way to do *that* (I'd love to hear about
> it). But regardless of that I think it's a good idea to be able to
> know what the top-level is from git submodule foreach.

This patch is getting merged to next as per the June 2 What's cooking in Git post.

But I wonder how evil it would be to expand this this idea to allow the porcelain to track branches instead of commits at the porcelain level.

That /could/ work like this. The tree format would be exactly the same, i.e. bound to a specific commit:

    $ git ls-tree HEAD | grep subthing
    160000 commit 37469ca3fae264e790e4daac0fa8f2ddf8039c93  subthing

*But*, the user could add some new submodule.*.* config key/values that specify what branch the module should track and whether 'git pull' on the master project should also pull new changes (from the 'newstuff' branch) into the submodule:

    [submodule "subthing"]
        path = subthing
        url = git://github.com/avar/subthing.git
        branch = newstuff
        update-on-pull = true

Coupled with .gitignore this would allow for SVN-like externals that always track the latest version of upstream, but it'd all be done on the porcelain side.

The checked out copy wouldn't match the commit in the tree, but the user could still git add && git commit it to record the new commit in the master repository history.

The lack of this ability seems to be a fairly common complaint about submodules in Git, that you always have to do something in the parent project to update the submodules, even if you don't care about specific revisions, or the ability to roll back.

I couldn't find a prior discussion of this on the list, maybe this has been beaten to death already.