{"thread":{"id":"52099","subject":"Issue: \"Could not access submodule\" error when pulling recursively with Git 2.22.0","startedAt":"2019-10-23T07:22:17Z","lastAt":"2021-01-01T15:43:52Z","messageCount":4,"participants":["Aleksey Mikhaylov","SZEDER Gábor","Johannes Schindelin","Philippe Blain"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"384680","messageId":"AM5PR0902MB1953988602B657C3D0BB9B17A36B0@AM5PR0902MB1953.eurprd09.prod.outlook.com","threadId":"52099","inReplyTo":null,"subject":"Issue: \"Could not access submodule\" error when pulling recursively with Git 2.22.0","fromName":"Aleksey Mikhaylov","fromEmail":"almikhailov@plesk.com","sentAt":"2019-10-23T07:22:12Z","receivedAt":"2019-10-23T07:22:17Z","isPatch":false,"sender":{"key":"almikhailov@plesk.com","avatar":null},"body":"PROBLEM DESCRIPTION\n\n\"Could not access submodule\" error when pulling recursively with Git 2.22.0.\nThis issue causes if there is submodule in submodule.\n\nAt first, we reported this problem for Git for Windows:\nhttps://github.com/git-for-windows/git/issues/2361\nBut we received the answer that it was reproduced on Linux too.\n\nAlso, the same problem is described here: \nhttps://gitlab.com/gitlab-org/gitlab/issues/27287\n\nSTEPS TO REPRODUCE\n\nPlease use my simple test repository to reproduce the problem:\nhttps://github.com/agmikhailov/example2361.git\n\nIt is just an empty repository with one submodule (https://github.com/agmikhailov/example2361M1.git) \nand one submodule of submodule (https://github.com/agmikhailov/example2361M2.git):\n\ngit clone https://github.com/agmikhailov/example2361.git\ncd example2361/\ngit submodule init\ngit submodule update\ngit pull --recurse-submodules=true\n\nACTUAL RESULT\n\n\"git --recurse-submodules=true\" command fails with message \"Could not access submodule\":\n\n$ git --recurse-submodules=true\nFetching submodule example2361M1\nCould not access submodule 'example2361M2'\n\nEXPECTED RESULT\n\nAll submodules are successfully updated by \"git --recurse-submodules=true\" command.\n\nADDITIONAL INFORMATION\n\nGit version 2.20.1 does not have this problem. \nSo we had to downgrade Git to work with submodules.\n\nBest regards,\n--\nAleksey\n\n"},{"id":"384686","messageId":"20191023100449.GH4348@szeder.dev","threadId":"52099","inReplyTo":"AM5PR0902MB1953988602B657C3D0BB9B17A36B0@AM5PR0902MB1953.eurprd09.prod.outlook.com","subject":"Re: Issue: \"Could not access submodule\" error when pulling recursively with Git 2.22.0","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2019-10-23T10:04:49Z","receivedAt":"2019-10-23T10:04:56Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Wed, Oct 23, 2019 at 07:22:12AM +0000, Aleksey Mikhaylov wrote:\n> \"Could not access submodule\" error when pulling recursively with Git 2.22.0.\n> This issue causes if there is submodule in submodule.\n\n> Please use my simple test repository to reproduce the problem:\n> https://github.com/agmikhailov/example2361.git\n> \n> It is just an empty repository with one submodule (https://github.com/agmikhailov/example2361M1.git) \n> and one submodule of submodule (https://github.com/agmikhailov/example2361M2.git):\n> \n> git clone https://github.com/agmikhailov/example2361.git\n> cd example2361/\n> git submodule init\n\nAccording to the docs of 'git submodule init', it \"initializes the\nsubmodules recorded in the index\".  Therefore, it can only initialize\nthe submodule in 'example2361M1', because at this point we have no\nidea that there is a nested submodule in there.\n\n  $ git submodule init\n  Submodule 'example2361M1' (https://github.com/agmikhailov/example2361M1.git) registered for path 'example2361M1'\n\n> git submodule update\n\nThis command clones 'example2361M1':\n\n  $ git submodule update --recursive\n  Cloning into '/tmp/example2361/example2361M1'...\n  Submodule path 'example2361M1': checked out '6a9be24a1c0ebd44d91ae4dcf1fd62580b936540'\n\nOnly at this point can we finally see that there is a nested\nsubmodule, and can initialize and clone it with:\n\n  $ cd example2361M1\n  $ git submodule init\n  Submodule 'example2361M2' (https://github.com/agmikhailov/example2361M2.git) registered for path 'example2361M2'\n  $ git submodule update\n  Cloning into '/tmp/example2361/example2361M1/example2361M2'...\n  Submodule path 'example2361M2': checked out '9ed39cf1fe0a8cf34e72d2e7ebff1ea9d4a63ac1'\n\n> git pull --recurse-submodules=true\n\nAnd after that:\n\n  $ cd ../..\n  $ git pull --recurse-submodules=true\n  Fetching submodule example2361M1\n  Fetching submodule example2361M1/example2361M2\n  Already up to date.\n\n\n> ACTUAL RESULT\n> \n> \"git --recurse-submodules=true\" command fails with message \"Could not access submodule\":\n> \n> $ git --recurse-submodules=true\n> Fetching submodule example2361M1\n> Could not access submodule 'example2361M2'\n> \n> EXPECTED RESULT\n> \n> All submodules are successfully updated by \"git --recurse-submodules=true\" command.\n> \n> ADDITIONAL INFORMATION\n> \n> Git version 2.20.1 does not have this problem. \n> So we had to downgrade Git to work with submodules.\n\nThe behavior was indeed different with v2.20.1, but that version\ndidn't show the behavior you expected.  When running your commands\nwith v2.20.1 I get:\n\n  $ ~/src/git/bin-wrappers/git pull --recurse-submodules=true\n  Fetching submodule example2361M1\n  Already up to date.\n  $ find example2361M1/example2361M2/\n  example2361M1/example2361M2/\n\nSo while that 'git pull' didn't error out, it didn't even look at the\nnested submodule, which is still uninitialized and empty.\n\nFWIW, bisecting shows that the behavior changed with commit\na62387b3fc, but, unfortunately, the commit message doesn't seem to be\nvery helpful to me, but perhaps others with more experience with\nsubmodules can make something out of it.\n\ncommit a62387b3fc9f5aeeb04a2db278121d33a9caafa7\nAuthor: Stefan Beller <sbeller@google.com>\nDate:   Wed Nov 28 16:27:55 2018 -0800\n\n    submodule.c: fetch in submodules git directory instead of in worktree\n    \n    Keep the properties introduced in 10f5c52656 (submodule: avoid\n    auto-discovery in prepare_submodule_repo_env(), 2016-09-01), by fixating\n    the git directory of the submodule.\n    \n    Signed-off-by: Stefan Beller <sbeller@google.com>\n    Signed-off-by: Junio C Hamano <gitster@pobox.com>\n\n submodule.c | 10 ++++++++--\n 1 file changed, 8 insertions(+), 2 deletions(-)\n\n\n"},{"id":"384857","messageId":"nycvar.QRO.7.76.6.1910251415560.46@tvgsbejvaqbjf.bet","threadId":"52099","inReplyTo":"20191023100449.GH4348@szeder.dev","subject":"Re: Issue: \"Could not access submodule\" error when pulling recursively with Git 2.22.0","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-10-25T12:41:22Z","receivedAt":"2019-10-25T12:41:48Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Gábor,\n\nOn Wed, 23 Oct 2019, SZEDER Gábor wrote:\n\n> On Wed, Oct 23, 2019 at 07:22:12AM +0000, Aleksey Mikhaylov wrote:\n> > \"Could not access submodule\" error when pulling recursively with Git 2.22.0.\n> > This issue causes if there is submodule in submodule.\n>\n> > Please use my simple test repository to reproduce the problem:\n> > https://github.com/agmikhailov/example2361.git\n> >\n> > It is just an empty repository with one submodule (https://github.com/agmikhailov/example2361M1.git)\n> > and one submodule of submodule (https://github.com/agmikhailov/example2361M2.git):\n> >\n> > git clone https://github.com/agmikhailov/example2361.git\n> > cd example2361/\n> > git submodule init\n>\n> According to the docs of 'git submodule init', it \"initializes the\n> submodules recorded in the index\".  Therefore, it can only initialize\n> the submodule in 'example2361M1', because at this point we have no\n> idea that there is a nested submodule in there.\n>\n>   $ git submodule init\n>   Submodule 'example2361M1' (https://github.com/agmikhailov/example2361M1.git) registered for path 'example2361M1'\n\nIndeed, `git submodule init` is not recursive.\n\n> > git submodule update\n>\n> This command clones 'example2361M1':\n>\n>   $ git submodule update --recursive\n>   Cloning into '/tmp/example2361/example2361M1'...\n>   Submodule path 'example2361M1': checked out '6a9be24a1c0ebd44d91ae4dcf1fd62580b936540'\n>\n> Only at this point can we finally see that there is a nested\n> submodule, and can initialize and clone it with:\n>\n>   $ cd example2361M1\n>   $ git submodule init\n>   Submodule 'example2361M2' (https://github.com/agmikhailov/example2361M2.git) registered for path 'example2361M2'\n>   $ git submodule update\n>   Cloning into '/tmp/example2361/example2361M1/example2361M2'...\n>   Submodule path 'example2361M2': checked out '9ed39cf1fe0a8cf34e72d2e7ebff1ea9d4a63ac1'\n\nI concur.\n\n> > git pull --recurse-submodules=true\n>\n> And after that:\n>\n>   $ cd ../..\n>   $ git pull --recurse-submodules=true\n>   Fetching submodule example2361M1\n>   Fetching submodule example2361M1/example2361M2\n>   Already up to date.\n\nYes, I agree that _probably_ what the user wanted is to initialize the\nsubmodules recursively.\n\nHaving said that, I vaguely remember that e.g. Boost has this insane\nforest of submodules, and I am almost certain that no sane person wants\nto clone them all. _I_ wouldn't.\n\n> > ACTUAL RESULT\n> >\n> > \"git --recurse-submodules=true\" command fails with message \"Could not access submodule\":\n> >\n> > $ git --recurse-submodules=true\n> > Fetching submodule example2361M1\n> > Could not access submodule 'example2361M2'\n> >\n> > EXPECTED RESULT\n> >\n> > All submodules are successfully updated by \"git --recurse-submodules=true\" command.\n> >\n> > ADDITIONAL INFORMATION\n> >\n> > Git version 2.20.1 does not have this problem.\n> > So we had to downgrade Git to work with submodules.\n>\n> The behavior was indeed different with v2.20.1, but that version\n> didn't show the behavior you expected.  When running your commands\n> with v2.20.1 I get:\n>\n>   $ ~/src/git/bin-wrappers/git pull --recurse-submodules=true\n>   Fetching submodule example2361M1\n>   Already up to date.\n>   $ find example2361M1/example2361M2/\n>   example2361M1/example2361M2/\n>\n> So while that 'git pull' didn't error out, it didn't even look at the\n> nested submodule, which is still uninitialized and empty.\n\nI would actually argue that this is what is expected: the entire _point_\nof submodules is that they can be inactive.\n\nComing back to the Boost example, what I would want Git to do when only\na fraction of the submodules is active is to skip the inactive ones\nduring a `git pull --recurse-submodules=true`.\n\nWhich v2.20.1 apparently did, and I would call the current behavior a\nregression.\n\n> FWIW, bisecting shows that the behavior changed with commit\n> a62387b3fc,\n\nThanks for digging this out!\n\n> but, unfortunately, the commit message doesn't seem to be very helpful\n> to me, but perhaps others with more experience with submodules can\n> make something out of it.\n>\n> commit a62387b3fc9f5aeeb04a2db278121d33a9caafa7\n> Author: Stefan Beller <sbeller@google.com>\n> Date:   Wed Nov 28 16:27:55 2018 -0800\n>\n>     submodule.c: fetch in submodules git directory instead of in worktree\n>\n>     Keep the properties introduced in 10f5c52656 (submodule: avoid\n>     auto-discovery in prepare_submodule_repo_env(), 2016-09-01), by fixating\n>     the git directory of the submodule.\n>\n>     Signed-off-by: Stefan Beller <sbeller@google.com>\n>     Signed-off-by: Junio C Hamano <gitster@pobox.com>\n>\n>  submodule.c | 10 ++++++++--\n>  1 file changed, 8 insertions(+), 2 deletions(-)\n\nTo me, this commit message suggests that the bahvior should not have\nchanged in the reported manner.\n\nLet's look at the diff:\n\n-- snip --\ndiff --git a/submodule.c b/submodule.c\nindex 77ace5e784a..d1b6646f42d 100644\n--- a/submodule.c\n+++ b/submodule.c\n@@ -494,6 +494,12 @@ void prepare_submodule_repo_env(struct argv_array *out)\n \t\t\t DEFAULT_GIT_DIR_ENVIRONMENT);\n }\n\n+static void prepare_submodule_repo_env_in_gitdir(struct argv_array *out)\n+{\n+\tprepare_submodule_repo_env_no_git_dir(out);\n+\targv_array_pushf(out, \"%s=.\", GIT_DIR_ENVIRONMENT);\n+}\n+\n /* Helper function to display the submodule header line prior to the full\n  * summary output. If it can locate the submodule objects directory it will\n  * attempt to lookup both the left and right commits and put them into the\n@@ -1327,8 +1333,8 @@ static int get_next_submodule(struct child_process *cp,\n \t\trepo = get_submodule_repo_for(spf->r, submodule);\n \t\tif (repo) {\n \t\t\tchild_process_init(cp);\n-\t\t\tcp->dir = xstrdup(repo->worktree);\n-\t\t\tprepare_submodule_repo_env(&cp->env_array);\n+\t\t\tcp->dir = xstrdup(repo->gitdir);\n+\t\t\tprepare_submodule_repo_env_in_gitdir(&cp->env_array);\n \t\t\tcp->git_cmd = 1;\n \t\t\tif (!spf->quiet)\n \t\t\t\tstrbuf_addf(err, \"Fetching submodule %s%s\\n\",\n-- snap --\n\nThe obvious difference in behavior is that we no longer let Git\ndiscover the `.git` file/directory, but we define it (because we can).\n\nBut actually, we cannot, not if the submodule is not checked out!\nBecause in this case, there is no `.git` file and Git then tries to\ninitialize the repository and the worktree, and fails rather miserably\nin the reported manner.\n\nSide note: I think there is something spooky going on where we try to\nfetch submodules twice when the first time failed, and somehow slip into\nthe `else` arm of this code:\n\n-- snip --\n\t\ttask->repo = get_submodule_repo_for(spf->r, task->sub);\n\t\tif (task->repo) {\n\t\t\tstruct strbuf submodule_prefix = STRBUF_INIT;\n\t\t\tchild_process_init(cp);\n\t\t\tcp->dir = task->repo->gitdir;\n\t\t\tprepare_submodule_repo_env_in_gitdir(&cp->env_array);\n\t\t\tcp->git_cmd = 1;\n\t\t\tif (!spf->quiet)\n\t\t\t\tstrbuf_addf(err, \"Fetching submodule %s%s\\n\",\n\t\t\t\t\t    spf->prefix, ce->name);\n\t\t\targv_array_init(&cp->args);\n\t\t\targv_array_pushv(&cp->args, spf->args.argv);\n\t\t\targv_array_push(&cp->args, default_argv);\n\t\t\targv_array_push(&cp->args, \"--submodule-prefix\");\n\n\t\t\tstrbuf_addf(&submodule_prefix, \"%s%s/\",\n\t\t\t\t\t\t       spf->prefix,\n\t\t\t\t\t\t       task->sub->path);\n\t\t\targv_array_push(&cp->args, submodule_prefix.buf);\n\n\t\t\tspf->count++;\n\t\t\t*task_cb = task;\n\n\t\t\tstrbuf_release(&submodule_prefix);\n\t\t\treturn 1;\n\t\t} else {\n\n\t\t\tfetch_task_release(task);\n\t\t\tfree(task);\n\n\t\t\t/*\n\t\t\t * An empty directory is normal,\n\t\t\t * the submodule is not initialized\n\t\t\t */\n\t\t\tif (S_ISGITLINK(ce->ce_mode) &&\n\t\t\t    !is_empty_dir(ce->name)) {\n\t\t\t\tspf->result = 1;\n\t\t\t\tstrbuf_addf(err,\n\t\t\t\t\t    _(\"Could not access submodule '%s'\"),\n\t\t\t\t\t    ce->name);\n\t\t\t}\n\t\t}\n-- snap --\n\nAs you can see, at that point, `is_empty_dir()` indicates that it is _no\nlonger empty_, which means that the recursive pull actually tried to\ninitialize it, and left things in a half-consistent state.\n\nBTW I also think that Stefan's commit just made a bug very obvious that\nhad not mattered all that much before: it would seem that before that\ncommit, when the code tried to fetch a submodule, it would actually\nfetch the super project (because it would discover the .git\nfile/directory, and as the inactive submodule does not have any, it\nwould have found the super project's).\n\nIn essence, I think that the report points out a very real bug, and this\nbug should be fixed.\n\nI _could_ imagine that it would be as easy as applying this patch (and\nturning the provided reproducer into a regression test), then polishing\nthis with a nice commit message:\n\n-- snip --\ndiff --git a/submodule.c b/submodule.c\nindex 0f199c51378..5694905610a 100644\n--- a/submodule.c\n+++ b/submodule.c\n@@ -1443,6 +1443,12 @@ static int get_next_submodule(struct child_process *cp,\n \t\ttask->repo = get_submodule_repo_for(spf->r, task->sub);\n \t\tif (task->repo) {\n \t\t\tstruct strbuf submodule_prefix = STRBUF_INIT;\n+\n+\t\t\t/* skip uninitialized submodule */\n+\t\t\tif (!file_exists(task->repo->gitdir) ||\n+\t\t\t    is_empty_dir(task->repo->gitdir))\n+\t\t\t\tcontinue;\n+\n \t\t\tchild_process_init(cp);\n \t\t\tcp->dir = task->repo->gitdir;\n \t\t\tprepare_submodule_repo_env_in_gitdir(&cp->env_array);\n-- snap --\n\nAny takers?\n\nCiao,\nJohannes\n"},{"id":"413304","messageId":"a12b4c26-3844-694f-d16d-4d5299a20503@gmail.com","threadId":"52099","inReplyTo":"nycvar.QRO.7.76.6.1910251415560.46@tvgsbejvaqbjf.bet","subject":"Re: Issue: \"Could not access submodule\" error when pulling recursively with Git 2.22.0","fromName":"Philippe Blain","fromEmail":"levraiphilippeblain@gmail.com","sentAt":"2021-01-01T15:42:52Z","receivedAt":"2021-01-01T15:43:52Z","isPatch":false,"sender":{"key":"levraiphilippeblain@gmail.com","avatar":"https://avatars.githubusercontent.com/u/44212482?v=4"},"body":"Hi Johannes, Gábor, Aleksey,\n\nLe 2019-10-25 à 08:41, Johannes Schindelin a écrit :\n> Hi Gábor,\n> \n> On Wed, 23 Oct 2019, SZEDER Gábor wrote:\n> \n>> On Wed, Oct 23, 2019 at 07:22:12AM +0000, Aleksey Mikhaylov wrote:\n>>> \"Could not access submodule\" error when pulling recursively with Git 2.22.0.\n>>> This issue causes if there is submodule in submodule.\n>>\n>>> Please use my simple test repository to reproduce the problem:\n>>> https://github.com/agmikhailov/example2361.git\n>>>\n>>> It is just an empty repository with one submodule (https://github.com/agmikhailov/example2361M1.git)\n>>> and one submodule of submodule (https://github.com/agmikhailov/example2361M2.git):\n>>>\n>>> git clone https://github.com/agmikhailov/example2361.git\n>>> cd example2361/\n>>> git submodule init\n>>\n>> According to the docs of 'git submodule init', it \"initializes the\n>> submodules recorded in the index\".  Therefore, it can only initialize\n>> the submodule in 'example2361M1', because at this point we have no\n>> idea that there is a nested submodule in there.\n>>\n>>    $ git submodule init\n>>    Submodule 'example2361M1' (https://github.com/agmikhailov/example2361M1.git) registered for path 'example2361M1'\n> \n> Indeed, `git submodule init` is not recursive.\n> \n>>> git submodule update\n>>\n>> This command clones 'example2361M1':\n>>\n>>    $ git submodule update --recursive\n>>    Cloning into '/tmp/example2361/example2361M1'...\n>>    Submodule path 'example2361M1': checked out '6a9be24a1c0ebd44d91ae4dcf1fd62580b936540'\n>>\n>> Only at this point can we finally see that there is a nested\n>> submodule, and can initialize and clone it with:\n>>\n>>    $ cd example2361M1\n>>    $ git submodule init\n>>    Submodule 'example2361M2' (https://github.com/agmikhailov/example2361M2.git) registered for path 'example2361M2'\n>>    $ git submodule update\n>>    Cloning into '/tmp/example2361/example2361M1/example2361M2'...\n>>    Submodule path 'example2361M2': checked out '9ed39cf1fe0a8cf34e72d2e7ebff1ea9d4a63ac1'\n> \n> I concur.\n> \n>>> git pull --recurse-submodules=true\n>>\n>> And after that:\n>>\n>>    $ cd ../..\n>>    $ git pull --recurse-submodules=true\n>>    Fetching submodule example2361M1\n>>    Fetching submodule example2361M1/example2361M2\n>>    Already up to date.\n> \n> Yes, I agree that _probably_ what the user wanted is to initialize the\n> submodules recursively.\n> \n> Having said that, I vaguely remember that e.g. Boost has this insane\n> forest of submodules, and I am almost certain that no sane person wants\n> to clone them all. _I_ wouldn't.\n> \n>>> ACTUAL RESULT\n>>>\n>>> \"git --recurse-submodules=true\" command fails with message \"Could not access submodule\":\n>>>\n>>> $ git --recurse-submodules=true\n>>> Fetching submodule example2361M1\n>>> Could not access submodule 'example2361M2'\n>>>\n>>> EXPECTED RESULT\n>>>\n>>> All submodules are successfully updated by \"git --recurse-submodules=true\" command.\n>>>\n>>> ADDITIONAL INFORMATION\n>>>\n>>> Git version 2.20.1 does not have this problem.\n>>> So we had to downgrade Git to work with submodules.\n>>\n>> The behavior was indeed different with v2.20.1, but that version\n>> didn't show the behavior you expected.  When running your commands\n>> with v2.20.1 I get:\n>>\n>>    $ ~/src/git/bin-wrappers/git pull --recurse-submodules=true\n>>    Fetching submodule example2361M1\n>>    Already up to date.\n>>    $ find example2361M1/example2361M2/\n>>    example2361M1/example2361M2/\n>>\n>> So while that 'git pull' didn't error out, it didn't even look at the\n>> nested submodule, which is still uninitialized and empty.\n> \n> I would actually argue that this is what is expected: the entire _point_\n> of submodules is that they can be inactive.\n> \n> Coming back to the Boost example, what I would want Git to do when only\n> a fraction of the submodules is active is to skip the inactive ones\n> during a `git pull --recurse-submodules=true`.\n> \n> Which v2.20.1 apparently did, and I would call the current behavior a\n> regression.\n\nI agree, and this regression was fixed recently by Peter Kaestle.\nThis bug was in fact reported twice recently ([1], [2]) and fixed\nearlier this month [3] (full threads: [4], [5]). The patch series is currently cooking\nin the 'next' branch [6]. You can check out just the fix from [7].\nIt should be included in Git 2.31.\n\nCheers,\n\nPhilippe.\n\n[1] https://lore.kernel.org/git/op.0vvmwohypvqxoc@damia/\n[2] https://lore.kernel.org/git/1604413399-63090-1-git-send-email-peter.kaestle@nokia.com/\n[3] https://lore.kernel.org/git/20201209105844.7019-1-peter.kaestle@nokia.com/\n[4] https://lore.kernel.org/git/CAN0XMOLiS_8JZKF_wW70BvRRxkDHyUoa=Z3ODtB_Bd6f5Y=7JQ@mail.gmail.com/t/#u\n[5] https://lore.kernel.org/git/1604413399-63090-1-git-send-email-peter.kaestle@nokia.com/t/#u\n[6] https://github.com/git/git/blob/730f2a8a60960c30a79e00ebe034836f60befbf0/whats-cooking.txt#L765-L771\n[7] https://github.com/gitster/git/tree/pk/subsub-fetch-fix-take-2\n"}]}