Mark Levedahl <mlevedahl@xxxxxxxxx> writes: > As the command is required, while pathspec is optional, the latter > should require the option, not the former. How about... > > $ git submodule foreach [-l pathspec] 'command' > > or > > $ git submodule foreach [<pathspec> --] 'command' Neither would fly well. For all normal git command, pathspec comes after the double dash. And I think it is probably a mistake to think "the command is required" as anything holy. "submodule foreach" looks very much like an index aware "find". Perhaps we could even make the lack of 'command' to default to "echo its name", just like "find ." and "find . -print" are equivalent (I am not seriously suggesting this, though. Read on). Having said all that, I think you can have best of both worlds by doing something like this: - If you do not have -c 'command' or any option, then everything is command and you cannot limit with pathspecs. This is the original syntax. - If you do have options to "foreach", then -c 'command' string is the command, and perhaps the foreach subcommand will gain other options over time, including possible -- pathspec separator. The remainder of the command line after options are processed are pathspecs that limit the ls-files. I do not think it is a defect that we do not allow pathspec limited foreach subcommand. Teaching foreach to take pathspecs is an independent topic if somebody has such an itch. As a conclusion of this discussion, I think David's [1/2] is fine as-is. Thanks. -- 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
