Junio C Hamano wrote: > 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. It's not rhetorical: I really do want to find out what our plan is for the future of --recurse-submodules. One possibility (A) would be "accept pathspec everywhere", as you mentioned. For a command like fetch that already accepts <mode>, that is problematic and would involve a migration. If we already have to migrate fetch, migrating diff as well does not seem too bad. Another possibility (B) would be "accept pathspec in clone only". A clone is a bit of a special case in that it is setting up the set of active submodules; perhaps we want other commands to always respect that set of active submodules without a method for overriding and only acting on a subset. After all, "git checkout <branch>" doesn't have a way to only checkout <branch> on a subset of the worktree; why should "git checkout --recurse-submodules <branch>" be any different? When I think about it this way, I suspect that (B) will provide a better experience than (A), so this diff change doesn't seem like a step in the wrong direction. Except: it took me a long time to think this through. Some documentation really would help, since it would mean that the next person can understand what the *intention* behind these options are and save some time thinking through other not-chosen alternatives. Hmm? Thanks, Jonathan
