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

[Junio C Hamano <gitster@pobox.com>]

Lars Hjemli <hjemli@gmail.com> writes:

>> Come to think of it, is there a reason why "for-each-repo" should
>> not be an extention to "submodule foreach"?  We can view this as
>> visiting repositories that _could_ be registered as a submodule, in
>> addition to iterating over the registered submodules, no?
>
> Yes, but I see some possible problems with that approach:
> -'git for-each-repo' does not need to be started from within a git worktree

True, but "git submodule foreach --untracked" can be told that it is
OK not (yet) to be in any superproject, no?

> -'git for-each-repo' and 'git submodule foreach' have different
> semantics for --dirty and --clean

That could be a problem.  Is there a good reason why they should use
different definitions of dirtyness?

> -'git for-each-repo' is in C because my 'git-all' shell script was
> horribly slow on large directory trees (especially on windows)

Your for-each-repo could be a good basis to build a new builtin
"submodule--foreach" that is a pure helper hidden from the end users
that does both; cmd_foreach() in git-submodule.sh can simply delegate
to it.

> All of these problems are probably solvable, but it would require
> quite some reworking of git-submodule.sh

Of course some work is needed, but we do not have to convert all the
cmd_foo in git-submodule.sh in one step.  For the purpose of
unifying for-each-repo and submodule foreach to deliver the
functionality sooner to the end users, we can go the route to add
only the submodule--foreach builtin, out of which we will get
reusable implementation of module_list and other helper functions we
can leverage later to do other cmd_foo functions.