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

Jens Lehmann [off-list ref] writes:

Am 28.01.2013 21:34, schrieb Junio C Hamano:
...

quoted

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.