Jonathan Nieder <jrnie...@gmail.com> 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,
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html