Lars Hjemli <hjemli@xxxxxxxxx> 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. -- 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