Re: [PATCH v4 1/2] for-each-repo: new command used for multi-repo operations

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 4, 2013, 06:41 UTC
Message-ID: <7vip6860nu.fsf@alter.siamese.dyndns.org>
In-Reply-To: <5106ECB6.9010801@web.de>

Jens Lehmann <Jens.Lehmann@web.de> writes:

Show 29 quoted lines

> 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.