{"thread":{"id":"57832","subject":"Bug Report: fetch.recurseSubmodules doesn't affect git pull as otherwise stated in the git config docs","startedAt":"2022-05-02T14:42:47Z","lastAt":"2022-05-10T00:57:15Z","messageCount":7,"participants":["Huang Zou","Philippe Blain","Glen Choo"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"454719","messageId":"CAFnZ=JNE_Sa3TsKghBPj1d0cz3kc6o91Ogj-op8o6qK8t9hPgg@mail.gmail.com","threadId":"57832","inReplyTo":null,"subject":"Bug Report: fetch.recurseSubmodules doesn't affect git pull as otherwise stated in the git config docs","fromName":"Huang Zou","fromEmail":"huang.zou@schrodinger.com","sentAt":"2022-05-02T14:42:33Z","receivedAt":"2022-05-02T14:42:47Z","isPatch":false,"sender":{"key":"huang.zou@schrodinger.com","avatar":null},"body":"Thank you for filling out a Git bug report!\nPlease answer the following questions to help us understand your issue.\n\nWhat did you do before the bug happened? (Steps to reproduce your issue)\n1) Set the following configs:\n git config submodule.recurse true\n git config fetch.recurseSubmodules false\n2) On a repo with submodules, run:\ngit pull\n\nWhat did you expect to happen? (Expected behavior)\ngit pull doesn't recursively fetch submodules\n\nWhat happened instead? (Actual behavior)\nSubmodules are fetched recursively\n\nWhat's different between what you expected and what actually happened?\nSubmodules are fetched recursively\n\nAnything else you want to add:\ngit fetch works as intended. The documentation for fetch.recurseSubmodules\nstates that \"This option controls whether git fetch (and the underlying\nfetch in git pull)\" so I would naturally expect git pull to behave the same\nas git fetch\n\n\n\n[System Info]\ngit version:\ngit version 2.36.0\ncpu: x86_64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nfeature: fsmonitor--daemon\nuname: Darwin 19.6.0 Darwin Kernel Version 19.6.0: Tue Aug 24 20:28:00 PDT\n2021; root:xnu-6153.141.40~1/RELEASE_X86_64 x86_64\ncompiler info: clang: 12.0.0 (clang-1200.0.32.29)\nlibc info: no libc information available\n$SHELL (typically, interactive shell): /usr/local/bin/bash\n\n\n[Enabled Hooks]\npre-commit\n\nThanks,\nHuang\n"},{"id":"454889","messageId":"fc492627-c552-10ec-b30c-820299241278@gmail.com","threadId":"57832","inReplyTo":"CAFnZ=JNE_Sa3TsKghBPj1d0cz3kc6o91Ogj-op8o6qK8t9hPgg@mail.gmail.com","subject":"Re: Bug Report: fetch.recurseSubmodules doesn't affect git pull as otherwise stated in the git config docs","fromName":"Philippe Blain","fromEmail":"levraiphilippeblain@gmail.com","sentAt":"2022-05-05T23:57:53Z","receivedAt":"2022-05-05T23:58:49Z","isPatch":false,"sender":{"key":"levraiphilippeblain@gmail.com","avatar":"https://avatars.githubusercontent.com/u/44212482?v=4"},"body":"Hi Huang,\n\nLe 2022-05-02 à 10:42, Huang Zou a écrit :\n> Thank you for filling out a Git bug report!\n> Please answer the following questions to help us understand your issue.\n> \n> What did you do before the bug happened? (Steps to reproduce your issue)\n> 1) Set the following configs:\n>  git config submodule.recurse true\n>  git config fetch.recurseSubmodules false\n> 2) On a repo with submodules, run:\n> git pull\n> \n> What did you expect to happen? (Expected behavior)\n> git pull doesn't recursively fetch submodules\n> \n> What happened instead? (Actual behavior)\n> Submodules are fetched recursively\n> \n> What's different between what you expected and what actually happened?\n> Submodules are fetched recursively\n> \n> Anything else you want to add:\n> git fetch works as intended. The documentation for fetch.recurseSubmodules\n> states that \"This option controls whether git fetch (and the underlying\n> fetch in git pull)\" so I would naturally expect git pull to behave the same\n> as git fetch\n\nI did not try to reproduce, but I took a look at the code and I think I understand\nwhat happens. \n\nWhen 'git pull' invokes 'git fetch', it does so by specifically using the '--recurse-submodules'\nflag, see [1]. It sends either 'yes', 'no' or 'on-demand' as value, depending on the value\nof the local variable 'recurse_submodules'. This variable is initialized to the config value\nof 'submodule.recurse' in 'git_pull_config' [2], called at [3], and then overwritten by the value given\nexplicitely on the command line [4], parsed at [5].\n\nSo when 'git fetch' runs when called by 'git pull', it always receive the \n'--recurse-submodules' flag, and thus any config for fetch.recurseSubmodules is ignored\n(since explicit command line flags always have precedence over config values).\n\nSo one way to fix this would be to also parse 'fetch.recurseSubmodules' in 'git_pull_config',\nand send the correct value to the 'git fetch' invocation... Or simpler, call 'git fetch' with\n'--recurse-submodules-default' [9] instead...\n\n[sidenote]\nI'm thought for a while that it was maybe not a good idea to change the behaviour\nin your specific situation. If you have 'submodule.recurse'\nset to true and 'fetch.recurseSubmodules' set to false, and if the code is changed so that indeed\n'git pull' does not fetch recursively, then the code will still try to update the submodule working\ntrees after the end of the operation (merge or rebase), see the end of 'cmd_pull' [6], [7]. This  is\nOK, because if there are new submodule commits referenced by the superproject and they were not fetched because the \nfetch was not recursive, then the call to 'git submodule update' in update_submodules/rebase_submodule\nshould fetch them, so no problem there.\n[/sidenote]\n\nThe bug also exists in other configurations, i.e. you could have 'submodule.recurse' \nset to 'false' or 'true' and 'fetch.recurseSubmodules' set to 'true' or 'on-demand' and then again\nthe 'git fetch' invocation would ignore the config value.  \n\nSo maybe a good way forward would be to change the flag to '--recurse-submodules-default' \nwhen invoking 'git fetch', so that the following configurations work as expected:\n   - submodule.recurse=false / fetch.recurseSubmodules=true       (should fetch)\n   - submodule.recurse=false / fetch.recurseSubmodules=on-demand  (should fetch if needed)\n   - submodule.recurse=true  / fetch.recurseSubmodules=on-demand  (should fetch if needed)\n   - submodule.recurse=true  / fetch.recurseSubmodules=false      (should not fetch)\n\nI hope that helps.\nCheers,\n\nPhilippe.\n\n[1] https://github.com/git/git/blob/f5aaf72f1b5aeb3b77bccabce014ea2590e823e2/builtin/pull.c#L539-L551\n[2] https://github.com/git/git/blob/f5aaf72f1b5aeb3b77bccabce014ea2590e823e2/builtin/pull.c#L366-L369\n[3] https://github.com/git/git/blob/f5aaf72f1b5aeb3b77bccabce014ea2590e823e2/builtin/pull.c#L996\n[4] https://github.com/git/git/blob/f5aaf72f1b5aeb3b77bccabce014ea2590e823e2/builtin/pull.c#L122-L125\n[5] https://github.com/git/git/blob/f5aaf72f1b5aeb3b77bccabce014ea2590e823e2/builtin/pull.c#L1002\n[6] https://github.com/git/git/blob/f5aaf72f1b5aeb3b77bccabce014ea2590e823e2/builtin/pull.c#L1144-L1155\n[7] https://github.com/git/git/blob/f5aaf72f1b5aeb3b77bccabce014ea2590e823e2/builtin/pull.c#L624-L648\n[8] https://git-scm.com/docs/git-config#Documentation/git-config.txt-fetchrecurseSubmodules\n[9] https://git-scm.com/docs/git-fetch#Documentation/git-fetch.txt---recurse-submodules-defaultyeson-demand\n"},{"id":"454955","messageId":"kl6lbkwa8h5n.fsf@chooglen-macbookpro.roam.corp.google.com","threadId":"57832","inReplyTo":"fc492627-c552-10ec-b30c-820299241278@gmail.com","subject":"Re: Bug Report: fetch.recurseSubmodules doesn't affect git pull as otherwise stated in the git config docs","fromName":"Glen Choo","fromEmail":"chooglen@google.com","sentAt":"2022-05-06T21:50:28Z","receivedAt":"2022-05-06T21:50:45Z","isPatch":false,"sender":{"key":"glencbz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/58092771?v=4"},"body":"Philippe Blain <levraiphilippeblain@gmail.com> writes:\n\n> Hi Huang,\n>\n> Le 2022-05-02 à 10:42, Huang Zou a écrit :\n>> Thank you for filling out a Git bug report!\n>> Please answer the following questions to help us understand your issue.\n>> \n>> What did you do before the bug happened? (Steps to reproduce your issue)\n>> 1) Set the following configs:\n>>  git config submodule.recurse true\n>>  git config fetch.recurseSubmodules false\n>> 2) On a repo with submodules, run:\n>> git pull\n>> \n>> What did you expect to happen? (Expected behavior)\n>> git pull doesn't recursively fetch submodules\n>> \n>> What happened instead? (Actual behavior)\n>> Submodules are fetched recursively\n>> \n>> What's different between what you expected and what actually happened?\n>> Submodules are fetched recursively\n>> \n>> Anything else you want to add:\n>> git fetch works as intended. The documentation for fetch.recurseSubmodules\n>> states that \"This option controls whether git fetch (and the underlying\n>> fetch in git pull)\" so I would naturally expect git pull to behave the same\n>> as git fetch\n>\n> I did not try to reproduce, but I took a look at the code and I think I understand\n> what happens. \n>\n> When 'git pull' invokes 'git fetch', it does so by specifically using the '--recurse-submodules'\n> flag, see [1]. It sends either 'yes', 'no' or 'on-demand' as value, depending on the value\n> of the local variable 'recurse_submodules'. This variable is initialized to the config value\n> of 'submodule.recurse' in 'git_pull_config' [2], called at [3], and then overwritten by the value given\n> explicitely on the command line [4], parsed at [5].\n>\n> So when 'git fetch' runs when called by 'git pull', it always receive the \n> '--recurse-submodules' flag, and thus any config for fetch.recurseSubmodules is ignored\n> (since explicit command line flags always have precedence over config values).\n\nThanks for looking into this! This seems to agree with my reading of the\ncode. I haven't tried to reproduce it either, but the code looks\nobviously incorrect.\n\n> So one way to fix this would be to also parse 'fetch.recurseSubmodules' in 'git_pull_config',\n> and send the correct value to the 'git fetch' invocation... Or simpler, call 'git fetch' with\n> '--recurse-submodules-default' [9] instead...\n\nDespite having touched this code fairly recently, I had to do quite a\nrereading to refresh myself on how this works. If I _am_ reading this\ncorrectly, then I think we actually want to set `--recurse-submodules`\nand not `--recurse-submodules-default`.\n\nThe short story is that the two are not equivalent - when figuring out\n_which_ submodules to fetch (we determine on a submodule-by-submodule\nbasis; we don't just say \"should we fetch all submodules?\"),\n`--recurse-submodules-default` gets overrided by config values, but\n`--recurse-submodules` does not.\n\nThe longer story (which I think is quite difficult to explain, I am also\na little confused) is that in a recursive fetch,\n`--recurse-submodules-default` is the value of the parent's (we'll call\nit P) `--recurse-submodules`. This only matters when a process, C1, has\nto pass a value for `--recurse-submodules` to its child, C2. The\nprecedence order is:\n\n- C1's --recurse-submodules | fetch.recurseSubmodules |\n  submodule.recurse\n- C2's submodule entry in C1's .git/config\n- C2's entry in C1's .gitmodules\n- C1's --recurse-submodules-default (aka P's --recurse-submodules)\n\nSpecifically, in code:\n\n  static int get_fetch_recurse_config(const struct submodule *submodule,\n              struct submodule_parallel_fetch *spf)\n  {\n    // Glen: passed in from builtin/fetch, which parses\n    //  --recurse-submodules, fetch.recurseSubmodules, submodule.recurse\n    if (spf->command_line_option != RECURSE_SUBMODULES_DEFAULT)\n      return spf->command_line_option;\n\n    if (submodule) {\n      // ...\n      // Glen: fetch configuration from .gitmodules\n      int fetch_recurse = submodule->fetch_recurse;\n\n      key = xstrfmt(\"submodule.%s.fetchRecurseSubmodules\", submodule->name);\n      if (!repo_config_get_string_tmp(spf->r, key, &value)) {\n        // Glen: fetch configuration from .git/config\n        fetch_recurse = parse_fetch_recurse_submodules_arg(key, value);\n      }\n      // ...\n    }\n\n    // Glen: --recurse-submodules-default\n    return spf->default_option;\n  }\n\nSo `--recurse-submodules-default` really wasn't meant for anything other\nthan \"fetch\" invoking itself in a superproject-submodule setting.\n\nOf course, I could be entirely wrong and I should just write up a test\ncase :). I hope to send one soon.\n\n> [sidenote]\n> I'm thought for a while that it was maybe not a good idea to change the behaviour\n> in your specific situation. If you have 'submodule.recurse'\n> set to true and 'fetch.recurseSubmodules' set to false, and if the code is changed so that indeed\n> 'git pull' does not fetch recursively, then the code will still try to update the submodule working\n> trees after the end of the operation (merge or rebase), see the end of 'cmd_pull' [6], [7]. This  is\n> OK, because if there are new submodule commits referenced by the superproject and they were not fetched because the \n> fetch was not recursive, then the call to 'git submodule update' in update_submodules/rebase_submodule\n> should fetch them, so no problem there.\n> [/sidenote]\n\nI think the bigger question to ask is \"what is the intended effect of\n'submodule.recurse = true' and 'fetch.recurseSubmodules = false'?\". I\nthink it is not surprising to think that recursive worktree operations\nmight fail if the submodule commits weren't fetched.\n\nPerhaps this is just a performance optimization? i.e. after fetching in\nthe superproject, the user wants to skip the rev walk that discovers new\nsubmodule commits.\n"},{"id":"454956","messageId":"b4d7600e-ed4e-b4b3-262a-a69818c25365@gmail.com","threadId":"57832","inReplyTo":"kl6lbkwa8h5n.fsf@chooglen-macbookpro.roam.corp.google.com","subject":"Re: Bug Report: fetch.recurseSubmodules doesn't affect git pull as otherwise stated in the git config docs","fromName":"Philippe Blain","fromEmail":"levraiphilippeblain@gmail.com","sentAt":"2022-05-06T22:24:32Z","receivedAt":"2022-05-06T22:24:39Z","isPatch":false,"sender":{"key":"levraiphilippeblain@gmail.com","avatar":"https://avatars.githubusercontent.com/u/44212482?v=4"},"body":"Hi Glen!\n\nLe 2022-05-06 à 17:50, Glen Choo a écrit :\n> Philippe Blain <levraiphilippeblain@gmail.com> writes:\n> \n>> Hi Huang,\n>>\n>> Le 2022-05-02 à 10:42, Huang Zou a écrit :\n>>> Thank you for filling out a Git bug report!\n>>> Please answer the following questions to help us understand your issue.\n>>>\n>>> What did you do before the bug happened? (Steps to reproduce your issue)\n>>> 1) Set the following configs:\n>>>  git config submodule.recurse true\n>>>  git config fetch.recurseSubmodules false\n>>> 2) On a repo with submodules, run:\n>>> git pull\n>>>\n>>> What did you expect to happen? (Expected behavior)\n>>> git pull doesn't recursively fetch submodules\n>>>\n>>> What happened instead? (Actual behavior)\n>>> Submodules are fetched recursively\n>>>\n>>> What's different between what you expected and what actually happened?\n>>> Submodules are fetched recursively\n>>>\n>>> Anything else you want to add:\n>>> git fetch works as intended. The documentation for fetch.recurseSubmodules\n>>> states that \"This option controls whether git fetch (and the underlying\n>>> fetch in git pull)\" so I would naturally expect git pull to behave the same\n>>> as git fetch\n>>\n>> I did not try to reproduce, but I took a look at the code and I think I understand\n>> what happens. \n>>\n>> When 'git pull' invokes 'git fetch', it does so by specifically using the '--recurse-submodules'\n>> flag, see [1]. It sends either 'yes', 'no' or 'on-demand' as value, depending on the value\n>> of the local variable 'recurse_submodules'. This variable is initialized to the config value\n>> of 'submodule.recurse' in 'git_pull_config' [2], called at [3], and then overwritten by the value given\n>> explicitely on the command line [4], parsed at [5].\n>>\n>> So when 'git fetch' runs when called by 'git pull', it always receive the \n>> '--recurse-submodules' flag, and thus any config for fetch.recurseSubmodules is ignored\n>> (since explicit command line flags always have precedence over config values).\n> \n> Thanks for looking into this! This seems to agree with my reading of the\n> code. I haven't tried to reproduce it either, but the code looks\n> obviously incorrect.\n> \n>> So one way to fix this would be to also parse 'fetch.recurseSubmodules' in 'git_pull_config',\n>> and send the correct value to the 'git fetch' invocation... Or simpler, call 'git fetch' with\n>> '--recurse-submodules-default' [9] instead...\n> \n> Despite having touched this code fairly recently, I had to do quite a\n> rereading to refresh myself on how this works. If I _am_ reading this\n> correctly, then I think we actually want to set `--recurse-submodules`\n> and not `--recurse-submodules-default`.\n> \n> The short story is that the two are not equivalent - when figuring out\n> _which_ submodules to fetch (we determine on a submodule-by-submodule\n> basis; we don't just say \"should we fetch all submodules?\"),\n> `--recurse-submodules-default` gets overrided by config values, but\n> `--recurse-submodules` does not.\n> \n> The longer story (which I think is quite difficult to explain, I am also\n> a little confused) is that in a recursive fetch,\n> `--recurse-submodules-default` is the value of the parent's (we'll call\n> it P) `--recurse-submodules`. This only matters when a process, C1, has\n> to pass a value for `--recurse-submodules` to its child, C2. The\n> precedence order is:\n> \n> - C1's --recurse-submodules | fetch.recurseSubmodules |\n>   submodule.recurse\n> - C2's submodule entry in C1's .git/config\n> - C2's entry in C1's .gitmodules\n> - C1's --recurse-submodules-default (aka P's --recurse-submodules)\n> \n> Specifically, in code:\n> \n>   static int get_fetch_recurse_config(const struct submodule *submodule,\n>               struct submodule_parallel_fetch *spf)\n>   {\n>     // Glen: passed in from builtin/fetch, which parses\n>     //  --recurse-submodules, fetch.recurseSubmodules, submodule.recurse\n>     if (spf->command_line_option != RECURSE_SUBMODULES_DEFAULT)\n>       return spf->command_line_option;\n> \n>     if (submodule) {\n>       // ...\n>       // Glen: fetch configuration from .gitmodules\n>       int fetch_recurse = submodule->fetch_recurse;\n> \n>       key = xstrfmt(\"submodule.%s.fetchRecurseSubmodules\", submodule->name);\n>       if (!repo_config_get_string_tmp(spf->r, key, &value)) {\n>         // Glen: fetch configuration from .git/config\n>         fetch_recurse = parse_fetch_recurse_submodules_arg(key, value);\n>       }\n>       // ...\n>     }\n> \n>     // Glen: --recurse-submodules-default\n>     return spf->default_option;\n>   }\n> \n> So `--recurse-submodules-default` really wasn't meant for anything other\n> than \"fetch\" invoking itself in a superproject-submodule setting.\n> \n> Of course, I could be entirely wrong and I should just write up a test\n> case :). I hope to send one soon.\n\nOK so it's more complicated than I thought (I'm not surprised :P). Thanks for \nthe details.\n\nThe other thing I thought about, is that even if '--recurse-submodules-default'\nworked as I thought it did when I wrote this, it would still not be the right\nthing to change builtin/pull to invoke 'git fetch' with it instead, since then\na user invoking e.g. 'git pull --recurse-submodules=false', who has 'fetch.recurseSubmodules=true',\nwould not get a recursive fetch, since the internal fetch would prioritise 'fetch.recurseSubmodules=true',\nbut that's contrary to user expectation that command-line flags override config, always...\nSo whatever is done to fix this, we might need to keep track of where 'recurse_submodules'\nwas set from, either the command-line or the config.\n\n> \n>> [sidenote]\n>> I'm thought for a while that it was maybe not a good idea to change the behaviour\n>> in your specific situation. If you have 'submodule.recurse'\n>> set to true and 'fetch.recurseSubmodules' set to false, and if the code is changed so that indeed\n>> 'git pull' does not fetch recursively, then the code will still try to update the submodule working\n>> trees after the end of the operation (merge or rebase), see the end of 'cmd_pull' [6], [7]. This  is\n>> OK, because if there are new submodule commits referenced by the superproject and they were not fetched because the \n>> fetch was not recursive, then the call to 'git submodule update' in update_submodules/rebase_submodule\n>> should fetch them, so no problem there.\n>> [/sidenote]\n> \n> I think the bigger question to ask is \"what is the intended effect of\n> 'submodule.recurse = true' and 'fetch.recurseSubmodules = false'?\".\n\nYes, I agree that it would be nice if Huang clarified that as I'm not sure\neither of the use case.\n\n> I\n> think it is not surprising to think that recursive worktree operations\n> might fail if the submodule commits weren't fetched.\n\nYes, if ever 'merge' and 'rebase' are taught to obey 'submodule.recurse'\n(if only I had time to work on that!), then all hell would break loose\nif submodule commits were not fetched when these operations start.\n\n> \n> Perhaps this is just a performance optimization? i.e. after fetching in\n> the superproject, the user wants to skip the rev walk that discovers new\n> submodule commits.\n> \n\n\nCheers,\nPhilippe.\n"},{"id":"455019","messageId":"CAFnZ=JO15s=nXSNSDNeMvS98M49HxZ6N6EfNxP6v7-46i6dDNw@mail.gmail.com","threadId":"57832","inReplyTo":"b4d7600e-ed4e-b4b3-262a-a69818c25365@gmail.com","subject":"Re: Bug Report: fetch.recurseSubmodules doesn't affect git pull as otherwise stated in the git config docs","fromName":"Huang Zou","fromEmail":"huang.zou@schrodinger.com","sentAt":"2022-05-09T16:24:38Z","receivedAt":"2022-05-09T16:24:53Z","isPatch":false,"sender":{"key":"huang.zou@schrodinger.com","avatar":null},"body":"Hi Glen & Philippe,\n\nThanks for taking the time to look into this!\n\n> > I think the bigger question to ask is \"what is the intended effect of\n> > 'submodule.recurse = true' and 'fetch.recurseSubmodules = false'?\".\n>\n> Yes, I agree that it would be nice if Huang clarified that as I'm not sure\n> either of the use case.\n\n> > Perhaps this is just a performance optimization? i.e. after fetching in\n> > the superproject, the user wants to skip the rev walk that discovers new\n> > submodule commits.\n> >\n\nSo the use case here is just performance optimization. My team has\nover 10 submodules and I do not deal with most of them. I want to be\nable to pull the latest changes quickly (fetching submodules adds ~13\nseconds when there are no new commits to a pull that would otherwise\ntake ~1 second). I want my working tree to be clean after\npulls/checkouts. So checkouts and other commands that update my commit\nHEAD should still recursively update submodules (hence\nsubmodule.recurse is true). Although, I may be naively assuming that\nfetches can be avoided if I only care about the commit referenced in\nthe submodule link. If that isn't the case, then the more practical\nuse-case would be  'submodule.recurse = true' and\n'fetch.recurseSubmodules = on-demand', so at least submodules are only\nfetched when there are changes.\n\nThe other use-case here, which I should have probably included in my\noriginal report, is `git pull` currently also recurse into *inactive\nsubmodules*. i.e. submodules that are not set in \"submodule.active\".\nIf my submodules are not active, and not initialized, then git should\nnot fetch commits in those submodules regardless of the settings in\nfetch.recurseSubmodules\n\nI hope this helps clear up a few things!\n\nThanks,\nHuang\n"},{"id":"455065","messageId":"kl6l5yme8epc.fsf@chooglen-macbookpro.roam.corp.google.com","threadId":"57832","inReplyTo":"CAFnZ=JNE_Sa3TsKghBPj1d0cz3kc6o91Ogj-op8o6qK8t9hPgg@mail.gmail.com","subject":"Re: Bug Report: fetch.recurseSubmodules doesn't affect git pull as otherwise stated in the git config docs","fromName":"Glen Choo","fromEmail":"chooglen@google.com","sentAt":"2022-05-09T23:32:31Z","receivedAt":"2022-05-09T23:32:45Z","isPatch":false,"sender":{"key":"glencbz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/58092771?v=4"},"body":"Huang Zou <huang.zou@schrodinger.com> writes:\n\n> Thank you for filling out a Git bug report!\n> Please answer the following questions to help us understand your issue.\n>\n> What did you do before the bug happened? (Steps to reproduce your issue)\n> 1) Set the following configs:\n>  git config submodule.recurse true\n>  git config fetch.recurseSubmodules false\n> 2) On a repo with submodules, run:\n> git pull\n>\n> What did you expect to happen? (Expected behavior)\n> git pull doesn't recursively fetch submodules\n>\n> What happened instead? (Actual behavior)\n> Submodules are fetched recursively\n>\n> What's different between what you expected and what actually happened?\n> Submodules are fetched recursively\n>\n> Anything else you want to add:\n> git fetch works as intended. The documentation for fetch.recurseSubmodules\n> states that \"This option controls whether git fetch (and the underlying\n> fetch in git pull)\" so I would naturally expect git pull to behave the same\n> as git fetch\n>\n>\n>\n> [System Info]\n> git version:\n> git version 2.36.0\n> cpu: x86_64\n> no commit associated with this build\n> sizeof-long: 8\n> sizeof-size_t: 8\n> shell-path: /bin/sh\n> feature: fsmonitor--daemon\n> uname: Darwin 19.6.0 Darwin Kernel Version 19.6.0: Tue Aug 24 20:28:00 PDT\n> 2021; root:xnu-6153.141.40~1/RELEASE_X86_64 x86_64\n> compiler info: clang: 12.0.0 (clang-1200.0.32.29)\n> libc info: no libc information available\n> $SHELL (typically, interactive shell): /usr/local/bin/bash\n>\n>\n> [Enabled Hooks]\n> pre-commit\n>\n> Thanks,\n> Huang\n\nI've sent a fix at [1] :) I intended for the patch to be sent in reply\nto this thread, but I clearly don't know how to use GitGitGadget\ncorrectly. Whoops\n\n[1] https://lore.kernel.org/git/pull.1262.git.git.1652138854255.gitgitgadget@gmail.com/\n"},{"id":"455070","messageId":"66468ef0-663f-7088-1c2a-1e2b46925a64@gmail.com","threadId":"57832","inReplyTo":"kl6l5yme8epc.fsf@chooglen-macbookpro.roam.corp.google.com","subject":"Re: Bug Report: fetch.recurseSubmodules doesn't affect git pull as otherwise stated in the git config docs","fromName":"Philippe Blain","fromEmail":"levraiphilippeblain@gmail.com","sentAt":"2022-05-10T00:57:10Z","receivedAt":"2022-05-10T00:57:15Z","isPatch":false,"sender":{"key":"levraiphilippeblain@gmail.com","avatar":"https://avatars.githubusercontent.com/u/44212482?v=4"},"body":"Hi Glen,\n\nLe 2022-05-09 à 19:32, Glen Choo a écrit :\n> Huang Zou <huang.zou@schrodinger.com> writes:\n> \n> I've sent a fix at [1] :) I intended for the patch to be sent in reply\n> to this thread, but I clearly don't know how to use GitGitGadget\n> correctly. Whoops\n\nYeah, this is not supported by GitGitGadget (yet?). So it's not you :P\n\nPhilippe.\n"}]}