git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
Sep 6, 2018, 21:12 UTC
Message-ID
<xmqqefe6z5ws.fsf@gitster-ct.c.googlers.com>
In-Reply-To
<20180905231258.GD120842@aiede.svl.corp.google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
Show 10 quoted lines
> 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).

Previous: Stefan BellerNext: Stefan Beller
Message 4 of 9 in “diff: allow --recurse-submodules as an synonym for --submodule”
  1. diff: allow --recurse-submodules as an synonym for --submoduleStefan Beller, Sep 5, 2018
  2. Jonathan NiederSep 5, 2018
  3. Stefan BellerSep 6, 2018
  4. Junio C HamanoSep 6, 2018
  5. Stefan BellerSep 6, 2018
  6. Jonathan NiederSep 7, 2018
  7. Junio C HamanoSep 7, 2018
  8. Martin ÅgrenSep 6, 2018
  9. diff: allow --recurse-submodules as an synonym for --submoduleStefan Beller, Sep 6, 2018

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.