Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > Tracing backwards: it would be really nice to be able to do > > git for-each-repo git grep -e foo -- '*.c' This is a very good example that shows the command that is run in the repositories found may want pathspecs passed, but at the same time, makes me realize that these repositories have to be fairly uniform for this command to be useful. For example, 'src/*.c' or 'inc/*.h' pathspecs wouldn't be useful unless majority if not all projects the loop finds follow that layout convention. This is not necessarily limited to pathspecs, of course. Unless they all have the 'next' branch "git for-each-repo checkout next" would not work, etc. etc. 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. 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? If these two are unified, then we do not have to even worry about which one deserves "git -a" more. -- 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