On Fri, May 21, 2010 at 16:10, Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote:
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html