Jonathan Nieder <jrnie...@gmail.com> writes: > It seems like various commands are gaining --recurse-submodules options > taking different kinds of arguments: > > - clone takes --recurse-submodules=<pathspec> > - fetch takes --recurse-submodules=<mode> > - after this patch, diff takes --recurse-submodules=<mode> > > Is there a unifying principle? Can Documentation/gitsubmodules.txt > say a word or two about what kind of argument values the user should > expect to be accepted by these options?
I am not sure if the above is rhetorical. The only thing such a document can say about status-quo is that the user cannot make an educated guess, as there is no consistency. Some take an option to clarify which subset of submodules to act on, others take an option to specify what variant of operation to be made on the submodules. In the ideal world, the users ought to be able to give these two independently, i.e. "fetch" should be able to say "only fetch these submodules" with pathspec while "run the fetch in all of these submodules specified (with the pathspec) as necessary" with "on-demand" mode, for example. It may mean that it is too early to add "diff --recurse-submodules" as a synonym for "diff --submodule", before what we can do to improve the situation for commands that already take that "--recurse-submodules" option. A solution for _that_ problem might result in splitting it into two options (an option to select which submodule to recurse into, and another to specify the action that happens in these submodules)---we'd regret if we realize that the existing "diff --submodule" that specifies the action (i.e. how the changes in submodules are presented, not which submodules' changes are shown) does not match the one we choose for --recurse-submodules option (e.g. we may say --recurse-submodules is for selection, and a new --action-in-submodules is for action, in which case "diff"'s "--submodule" option is closer to the latter).
