> If that’s what your are trying to do, ‘git submodule foreach’ [1] seems like a better way to go.
> For example I have an alias ‘st-sub’ that calls git status in the superproject and then recursively in the submodules:
>
> $ cat ~/.gitconfig | grep st-sub
> st-sub = !git status "$@" && git sub foreach --recursive git status "$@"
I have almost the same aliases :)
s = status --short --branch
subfor="submodule foreach --recursive"
subs="!f() { git subfor git s \"$@\";}; f"
recs="!f() { git s \"$@\"; git subs \"$@\";}; f"
But in practice I often want to run commands only in *changed* submodules.
For instance with the above 'git subs' yields a lot of non informative
messages like:
Entering 'non/changed/submodule'
## master...origin/master
(and git foreach --quiet) removes the first line but not the second.
This is also useful for an alias like 'recursive_commit' where I only want
to commit changed submodules, to not get a lot of messages like
nothing to commit, working tree clean.
So I wrote a script that parses the output of 'git status --porcelain=v2'
and run a command only in changed submodules (where I can specify if
changed means 'C', 'M' or 'U'). Except that I did not think about unseting
GIT_DIR and stumbled into this bug (I am sorry I went a bit on a wild chase
in this mailing list but I had already spent quite some time in trying to
find a minimal exemple, I first thought that my program had a parsing bug).
Now that I think about it, I probably also could do that with 'git
submodule foreach', by testing 'git diff --no-ext-diff [--cached] --quiet'
first before running the subcommand. This would give me the 'M' submodules,
but it is not clear to me how I could test for 'C' changed submodules with
this method.
--
Damien Robert
http://www.normalesup.org/~robert/pro
