On Mon, Jan 28, 2013 at 6:45 PM, Junio C Hamano <gits...@pobox.com> wrote: > As to the pathspec limiting to affect the loop itself, not the > argument given to the command that is run, I don't think it is > absolutely needed; I am perfectly fine with declaring that > for-each-repo goes to repositories in all subdirectories without > limit, especially if doing so will make the UI issues we have to > deal with simpler.
Good (since the relative path of each repo will be exported to the child process, that process can perform path limiting when needed). > As to the "option to the command, not to the subcommand, -a option", > I have been assuming that it was a joke patch, but if "git -a grep" > turns out to be really useful, "submodule foreach" that iterates > over the submodules may also want to have such a short and sweet > mechanism. Between "for-each-repo" and "submodule foreach", I do > not yet have a strong opinion on which one deserves it more. > > 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 -'git for-each-repo' and 'git submodule foreach' have different semantics for --dirty and --clean -'git for-each-repo' is in C because my 'git-all' shell script was horribly slow on large directory trees (especially on windows) All of these problems are probably solvable, but it would require quite some reworking of git-submodule.sh -- larsh -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
