Jens Lehmann <Jens.Lehmann@xxxxxx> writes:
> Am 28.01.2013 21:34, schrieb Junio C Hamano:
> ...
>> I was imagining that "foreach --untracked" could go something like this:
>>
>> * If you are inside an existing git repository, read its index to
>> learn the gitlinks in the directory and its subdirectories.
>>
>> * Start from the current directory and recursively apply the
>> procedure in this step:
>>
>> * Scan the directory and iterate over the ones that has ".git" in
>> it:
>>
>> * If it is a gitlinked one, show it, but do not descend into it
>> unless --recursive is given (e.g. you start from /home/jens,
>> find /home/jens/proj/ directory that has /home/jens/proj/.git
>> in it. /home/jens/.git/index knows that it is a submodule of
>> the top-level superproject. "proj" is handled, and it is up
>> to the --recursive option if its submodules are handled).
>>
>> * If it is _not_ a gitlinked one, show it and descend into it
>> (e.g. /home/jens/ is not a repository or /home/jens/proj is
>> not a tracked submodule) to apply this procedure recursively.
>>
>> Of course, without --untracked, we have no need to iterate over the
>> readdir() return values; instead we just scan the index of the
>> top-level superproject.
>
> Thanks for explaining, that makes tons of sense.
There is a small thinko above, though, and I'd like to correct it
before anybody takes the above too seriously as _the_ outline of the
design and implements it to the letter.
The --recursive option should govern both a tracked submodule and an
untracked one. When asking to list both existing submodules and
directories that could become submodules, you should be able to say
$ git submodule foreach --untracked
to list the direct submodules and the directories with .git in them
that are not yet submodules of the top-level superproject, but the
latter is limited to those with no parent directories with .git in
them (other than the top-level of the working tree of the
superproject). With
$ git submodule foreach --untracked --recursive
you would see submodules and their submodules recursively, and also
directories with .git in them (i.e. candidates to become direct
submodules of the superproject) and the directories with .git in
them inside such submodule candidates (i.e. candidates to become
direct submodules of the directories that could become direct
submodules of the superproject) recursively.
If we set things up this way:
mkdir -p a/b c/d &&
for d in . a a/b c c/d
do
git init $d &&
( cd $d && git commit --allow-empty -m initial )
done &&
git add a &&
( cd a && git add b )
The expected results for various combinations are:
* "git submodule foreach" would visit 'a' and nothing else;
* "git submodule foreach --recursive" would visit 'a' and 'a/b';
* "git submodule foreach --untracked" would visit 'a' and 'c'; and
* "git submodule foreach --untracked --recursive" would visit all four.
--
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