Re: [PATCH 6/7] git-submodule: multi-level module definition

["Ping Yin" <pkufranky@gmail.com>]

On Fri, Mar 14, 2008 at 1:56 AM, Ping Yin <pkufranky@gmail.com> wrote:

>  In the no "--module-name" form, the path parameter may be not the real
>  submodule path, and it just acts as the filter for real submodule paths.
>  While in the "--module-name" form, the name parameter must be the logical
>  name, and the real paths corresponding to the logical name may be neither
>  a submodule path nor even existent.
>
>  This patch handles such a path for different subcommands as follows.
>
>   - status: Output 0{40} as the sha1. Doing this can remind the user to
>    add the path as submodule or delete the path from .gitmodules.
>   - update: Skip that path and issue a "Not a submodule" warning

Sometime it's useful to also update (or clone) the non-submodule
instead of "Not as submodule" warning. So we can add a --force option
to allow this kind of behaviour.

There are cases that we want to clone a group of repositories in batch.

One way is to put all urls and paths of these repositories in
.gitmodules which form a submodule group, for example "all", and then
run "git submodule --module-name update --force all" which will clone
all the repositories in batch even if they are not submodules yet.

Another way is use the "git submodule --module-name recurse clone"
(recurse patch series sent many days ago but not accept yet). But this
needs some discuss since we have no place for the module group name
"all" as the argument.

There may be other ways. i don't know which way is better and don't
care much now. What i care is whether the submodule subcommand should
operate on the non-submodule path.

More precisely, with --module-name, we can designate a group of names
by a logical group name. However, some paths corresponding to these
names may not be submodules yet. So should the submodule subcommands
(especially update for now) operate on these paths?

-- 
Ping Yin