Re: [PATCH] diff: allow --recurse-submodules as an synonym for --submodule

[Junio C Hamano <gitster@pobox.com>]

Jonathan Nieder <jrnieder@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).