{"thread":{"id":"54942","subject":"[Bug] 'git submodule update --single-branch' still fetching master","startedAt":"2021-01-06T00:21:42Z","lastAt":"2021-01-08T14:29:55Z","messageCount":3,"participants":["- -","Philippe Blain"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"413516","messageId":"898607890.216528.1609892347792@email.ionos.de","threadId":"54942","inReplyTo":null,"subject":"[Bug] 'git submodule update --single-branch' still fetching master","fromName":"- -","fromEmail":"sven@nichtgerade.de","sentAt":"2021-01-06T00:19:07Z","receivedAt":"2021-01-06T00:21:42Z","isPatch":false,"sender":{"key":"sven@nichtgerade.de","avatar":null},"body":"Hello,\n\nI encountered today some problems while trying to track a single branch with 'git submodule add' and 'git submodule update'. Please find my bug report below.\nAny help would be very welcome! :)\n\nKind regards,\nSven Krummen\n\n\nWhat did you do before the bug happened? (Steps to reproduce your issue)\nI've got two repositories, 'project' and 'lib', and I want to add 'lib' into 'project' as a git submodule.\nThe 'lib' repository contains the 'master' branch, which is quite heavy-weighted (~900MB), and a 'light' branch (~10MB) with a mostly unrelated history to 'master'. The 'master' branch is the default branch.\nSimilar to using 'git clone -b light --single-branch path/to/lib' I want to track only the 'light' branch as a submodule to reduce traffic on our build server.\n\nTo add the submodule to 'project' I tried to run:\n(a) 'git submodule add -b light path/to/lib'\n(b) 'git submodule add -b light --single-branch path/to/lib'\nBut git was always fetching the whole 'master' branch of 'lib' before switching to 'light'.\n\nAfter commiting & pushing everything to 'project''s remote, I started over with a fresh clone of 'project' to test whether 'git submodule update' would only fetch the 'light' branch (typical use-case for our build jobs):\n(c) 'git clone path/to/project && cd project'\n(d) 'git submodule update --init --remote --single-branch lib'\nBut again, git was fetching the whole 'master' branch of 'lib' before switching to 'light'. This behaviour seems to be independent of the used options of 'git submodule update'.\n\n\nWhat did you expect to happen? (Expected behavior)\n(a) or (b) To create a submodule which is tracking the 'light' branch of 'lib' and to fetch *only* this branch.\n(d) To fetch and checkout *only* the 'light' branch of 'lib'.\n\n\nWhat happened instead? (Actual behavior)\n(a) Fetching 'master' (or the full 'lib' repo?), then checking out the 'light' branch.\n(b) Error as option '--single-branch' is not supported for 'git submodule add'.\n(d) Fetching 'master' (or the full 'lib' repo?), then checking out the 'light' branch.\n\n\nWhat's different between what you expected and what actually happened?\nAs the 'master' branch of 'lib' is quite heavy-weighted, I do not want to fetch 'master' at all. By using the option '-b light' to specify which branch shall be tracked, there is no need to fetch other branches besides 'light'. I'm not sure if it is really necessary for 'git submodule add' to fetch anything, as this could also be done by a subsequent 'git submodule update'.\n\n\nAnything else you want to add:\nThis issue could be related to: https://stackoverflow.com/questions/61483547/how-to-shallow-pull-submodule-that-is-tracked-by-branch-name\n\n\n[System Info]\ngit version:\ngit version 2.29.2.windows.2\ncpu: x86_64\nbuilt from commit: 3464b98ce6803c98bf8fb34390cd150d66e4a0d3\nsizeof-long: 4\nsizeof-size_t: 8\nshell-path: /bin/sh\nuname: Windows 10.0 17763 \ncompiler info: gnuc: 10.2\nlibc info: no libc information available\n$SHELL (typically, interactive shell): C:\\Program Files\\Git\\usr\\bin\\bash.exe\n\n\n[Enabled Hooks]\n"},{"id":"413596","messageId":"05fafba4-6415-7b61-92ae-112bdc8fd7be@gmail.com","threadId":"54942","inReplyTo":"898607890.216528.1609892347792@email.ionos.de","subject":"Re: [Bug] 'git submodule update --single-branch' still fetching master","fromName":"Philippe Blain","fromEmail":"levraiphilippeblain@gmail.com","sentAt":"2021-01-06T19:30:05Z","receivedAt":"2021-01-06T19:31:05Z","isPatch":false,"sender":{"key":"levraiphilippeblain@gmail.com","avatar":"https://avatars.githubusercontent.com/u/44212482?v=4"},"body":"Hi Sven,\n\nLe 2021-01-05 à 19:19, - - a écrit :\n> Hello,\n> \n> I encountered today some problems while trying to track a single branch with 'git submodule add' and 'git submodule update'. Please find my bug report below.\n> Any help would be very welcome! :)\n> \n> Kind regards,\n> Sven Krummen\n> \n> \n> What did you do before the bug happened? (Steps to reproduce your issue)\n> I've got two repositories, 'project' and 'lib', and I want to add 'lib' into 'project' as a git submodule.\n> The 'lib' repository contains the 'master' branch, which is quite heavy-weighted (~900MB), and a 'light' branch (~10MB) with a mostly unrelated history to 'master'. The 'master' branch is the default branch.\n> Similar to using 'git clone -b light --single-branch path/to/lib' I want to track only the 'light' branch as a submodule to reduce traffic on our build server.\n\nThanks for a nice scenario description. Just a note on wording though (to make sure\nwe are on the same page): you can't have a submodule \"track\" a branch, at least\nnot in the sense that the submodule is always \"checked out\" on a branch, and the superproject\nknows that the submodule should always be \"on that branch\"; that's not how submodules work.\nAs specified in [1], the config `submodule.<name>.branch` is only ever used by\n`git submodule update --remote`, i.e. the superproject itself only records at which *commit* the\nsubmodule is at.\n\n> \n> To add the submodule to 'project' I tried to run:\n> (a) 'git submodule add -b light path/to/lib'\n> (b) 'git submodule add -b light --single-branch path/to/lib'\n> But git was always fetching the whole 'master' branch of 'lib' before switching to 'light'.\n\nThat's not a bug (in my opinion) since it's in a line with the documentation [1].\nThere is no way at the moment for the initial `git submodule add` to pass\n'--single-branch' and '--branch' to the underlying `git clone`.\n\n> \n> After commiting & pushing everything to 'project''s remote, I started over with a fresh clone of 'project' to test whether 'git submodule update' would only fetch the 'light' branch (typical use-case for our build jobs):\n> (c) 'git clone path/to/project && cd project'\n> (d) 'git submodule update --init --remote --single-branch lib'\n> But again, git was fetching the whole 'master' branch of 'lib' before switching to 'light'. This behaviour seems to be independent of the used options of 'git submodule update'.\n> \n  \nI can partly reproduce that behaviour. The following script creates \"lib\" with two branches,\nmaster and light, that *do not* share any history.\n\n~~~\n#!/bin/bash\n\nTEST_AUTHOR_LOCALNAME=author\nTEST_AUTHOR_DOMAIN=example.com\nGIT_AUTHOR_EMAIL=${TEST_AUTHOR_LOCALNAME}@${TEST_AUTHOR_DOMAIN}\nGIT_AUTHOR_NAME='A U Thor'\nGIT_AUTHOR_DATE='1112354055 +0200'\nTEST_COMMITTER_LOCALNAME=committer\nTEST_COMMITTER_DOMAIN=example.com\nGIT_COMMITTER_EMAIL=${TEST_COMMITTER_LOCALNAME}@${TEST_COMMITTER_DOMAIN}\nGIT_COMMITTER_NAME='C O Mitter'\nGIT_COMMITTER_DATE='1112354055 +0200'\nexport GIT_AUTHOR_EMAIL GIT_AUTHOR_NAME\nexport GIT_COMMITTER_EMAIL GIT_COMMITTER_NAME\nexport GIT_COMMITTER_DATE GIT_AUTHOR_DATE\n\nmkdir test\ncd test\n\nrm -rf project lib clone\n\ngit init lib && cd lib\necho \"content\">file\ngit add file\ngit commit -m \"initial on master in lib\"\ngit checkout --orphan light\necho \"content\">file\ngit add file\ngit commit -m \"initial on light in lib\"\n# Switch HEAD back to master\ngit checkout master\ncd ../\n\ngit init project && cd project\necho \"content\">file\ngit add file\ngit commit -m \"initial in proj\"\ngit submodule add -b light ../lib\ngit commit -m \"add lib to project\"\ncd ../\n\ngit clone project clone && cd clone\necho 'RUNNING: git submodule update --init --remote --single-branch'\n# This fails\ngit submodule update --init --remote --single-branch\necho 'RUNNING: ls -al lib'\nls -al lib\necho 'RUNNING: git -C lib ls-files -s'\ngit -C lib ls-files -s\necho 'RUNNING: git -C lib branch --all'\ngit -C lib branch --all\necho 'RUNNING: git -C lib config --get remote.origin.fetch'\ngit -C lib config --get remote.origin.fetch\n# Try to update again\necho 'RUNNING: git submodule update'\nGIT_TRACE2=1 git submodule update 2> >(grep -E 'start git fetch|^From|^ \\*' )\n~~~\n\nThe output should end with:\n\nRUNNING: git submodule update --init --remote --single-branch\nSubmodule 'lib' (/Users/Philippe/Code/GIT-devel/test/lib) registered for path 'lib'\nCloning into '/Users/Philippe/Code/GIT-devel/test/clone/lib'...\ndone.\nfatal: Needed a single revision\nUnable to find current origin/light revision in submodule path 'lib'\nRUNNING: ls -al lib\ntotal 8\ndrwxr-xr-x  3 Philippe  staff  102 Jan  6 14:03 .\ndrwxr-xr-x  6 Philippe  staff  204 Jan  6 14:03 ..\n-rw-r--r--  1 Philippe  staff   28 Jan  6 14:03 .git\nRUNNING: git -C lib ls-files -s\nRUNNING: git -C lib branch --all\n* master\n   remotes/origin/HEAD -> origin/master\n   remotes/origin/master\nRUNNING: git -C lib config --get remote.origin.fetch\n+refs/heads/master:refs/remotes/origin/master\nRUNNING: git submodule update\n14:14:09.745288 common-main.c:49                  start git fetch\n14:14:09.892463 common-main.c:49                  start git fetch origin cc09362ae7314174785faed3e5ee72a8e2db5460\n From /Users/Philippe/Code/GIT-devel/test/lib\n  * branch            cc09362ae7314174785faed3e5ee72a8e2db5460 -> FETCH_HEAD\nSubmodule path 'lib': checked out 'cc09362ae7314174785faed3e5ee72a8e2db5460'\n\nYou can see that the first 'git submodule update --init --remote --single-branch'\nfails. 'ls' and 'ls-files' tell us that the submodule is not checked out,\nand that the submodule index is empty.\n'git branch' and 'git config' then reveal that indeed only the 'master' branch exists\nin the submodule, so '--single-branch' was passed correctly but not the branch itself.\nAfterwards, issuing 'git submodule update' a second time will issue a simple 'git fetch',\nwhich will not work because of the single-branch refspec, then it will try fetching\nthe commit by its hash, which works, and then it will checkout that commit.\n\nLooking at commit 132f600b06 (clone: pass --single-branch during,\n  --recurse-submodules, 2020-02-20), which introduced the '--single-branch'\noption for 'git submodule update', it seems that what we have at the moment\nis partly a documentation bug, i.e. the doc should say\n\"Clone only the history leading up to the remote HEAD during update\",\nand not mention '--branch' at all. I'm CC-ing Emily and Peff who were involved\nin that series. Looking at the mailing list thread where\nthis feature was discussed [2], it seems that mentioning 'branch' in the description\nof 'single-branch' was just a leftover from v1 of the series that was forgotten\nin later iterations.\n\nAlso,looking at the code, the '--remote' option has no effect at all for the initial clone\nof the submodule. It is only taken into account after the initial clone.\nI think it would make sense for it to also influence the initial\nclone, so that it would behave as you expect, i.e. the code looks at the branch\nin '.gitmodules' and this branch is passed to the underlying 'git clone' if '--single-branch'\nwas passed to 'git submodule update'.\n\n\n> What did you expect to happen? (Expected behavior)\n> (a) or (b) To create a submodule which is tracking the 'light' branch of 'lib' and to fetch *only* this branch.\n\nThat would be a diffenret feature request, and I think it does make sense\nfor (b) to work. I don't think that '--branch' should automatically\nimply '--single-branch' though (i.e. I don't think (a) should change\nbehaviour).\n\n> (d) To fetch and checkout *only* the 'light' branch of 'lib'.\n> \n> \n> What happened instead? (Actual behavior)\n> (a) Fetching 'master' (or the full 'lib' repo?), then checking out the 'light' branch.\n\nYes, this does a plain 'git clone' so all branches are fetched.\n\n> (b) Error as option '--single-branch' is not supported for 'git submodule add'.\n> (d) Fetching 'master' (or the full 'lib' repo?), then checking out the 'light' branch.\n\nAs my script above shows, this does fetch only the 'master' branch, and then *if* we issue\na second 'git submodule update' it then fetches the required commmit by hash and checks it out.\nIt would be nice if you could send a reproducer (i.e. a complete script like the above) that\nshows exactly the behaviour you are seeing, if indeed in your scenario it really checks out\nthe 'light' branch. I'm not sure I understand how that could happen...\n\n> \n> \n> What's different between what you expected and what actually happened?\n> As the 'master' branch of 'lib' is quite heavy-weighted, I do not want to fetch 'master' at all. By using the option '-b light' to specify which branch shall be tracked, there is no need to fetch other branches besides 'light'. I'm not sure if it is really necessary for 'git submodule add' to fetch anything, as this could also be done by a subsequent 'git submodule update'.\n\nIn the past, 'git submodule add' used to not clone the submodule at all,\nbut this was deemed not very useful so now it does 'git clone' underneath.\n\n\nHope that helps,\n\nPhilippe.\n\n[1] https://git-scm.com/docs/git-submodule#Documentation/git-submodule.txt--bltbranchgt\n[2] https://lore.kernel.org/git/20200108231900.192476-1-emilyshaffer@google.com/t/#u\n"},{"id":"413815","messageId":"1441960943.306435.1610116032985@email.ionos.de","threadId":"54942","inReplyTo":"05fafba4-6415-7b61-92ae-112bdc8fd7be@gmail.com","subject":"Re: [Bug] 'git submodule update --single-branch' still fetching master","fromName":"- -","fromEmail":"sven@nichtgerade.de","sentAt":"2021-01-08T14:27:12Z","receivedAt":"2021-01-08T14:29:55Z","isPatch":false,"sender":{"key":"sven@nichtgerade.de","avatar":null},"body":"Dear Philippe,\n\nThanks for your fast and very detailed feedback! Please find below some further details.\n\n> Philippe Blain <levraiphilippeblain@gmail.com> hat am 06.01.2021 20:30 geschrieben:\n> \n> \n> Hi Sven,\n> \n> Le 2021-01-05 à 19:19, - - a écrit :\n> > Hello,\n> > \n> > I encountered today some problems while trying to track a single branch with 'git submodule add' and 'git submodule update'. Please find my bug report below.\n> > Any help would be very welcome! :)\n> > \n> > Kind regards,\n> > Sven Krummen\n> > \n> > \n> > What did you do before the bug happened? (Steps to reproduce your issue)\n> > I've got two repositories, 'project' and 'lib', and I want to add 'lib' into 'project' as a git submodule.\n> > The 'lib' repository contains the 'master' branch, which is quite heavy-weighted (~900MB), and a 'light' branch (~10MB) with a mostly unrelated history to 'master'. The 'master' branch is the default branch.\n> > Similar to using 'git clone -b light --single-branch path/to/lib' I want to track only the 'light' branch as a submodule to reduce traffic on our build server.\n> Thanks for a nice scenario description. Just a note on wording though (to make sure\n> we are on the same page): you can't have a submodule \"track\" a branch, at least\n> not in the sense that the submodule is always \"checked out\" on a branch, and the superproject\n> knows that the submodule should always be \"on that branch\"; that's not how submodules work.\n> As specified in [1], the config `submodule.<name>.branch` is only ever used by\n> `git submodule update --remote`, i.e. the superproject itself only records at which *commit* the\n> submodule is at.\n\nAgreed & understood. :)\n\n> > To add the submodule to 'project' I tried to run:\n> > (a) 'git submodule add -b light path/to/lib'\n> > (b) 'git submodule add -b light --single-branch path/to/lib'\n> > But git was always fetching the whole 'master' branch of 'lib' before switching to 'light'.\n> That's not a bug (in my opinion) since it's in a line with the documentation [1].\n> There is no way at the moment for the initial `git submodule add` to pass\n> '--single-branch' and '--branch' to the underlying `git clone`.\n\nOK, after further reading the documentation I think I now better understand the intended behaviour of (a) and agree that this is not a bug. However, if this is the default behaviour, I would appreciate a way to somehow pass '--single-branch' and '--branch' to the underlying 'git clone' when calling 'git submodule add'. In my use-case I want to avoid fetching the 'master' branch by any measure, as it is heavy-weighted and simply not needed.\nPersonally, I think it would be very valuable to introduce the '--single-branch' option to 'git submodule add' to achieve this behaviour (as in (b)).\n\n> > After commiting & pushing everything to 'project''s remote, I started over with a fresh clone of 'project' to test whether 'git submodule update' would only fetch the 'light' branch (typical use-case for our build jobs):\n> > (c) 'git clone path/to/project && cd project'\n> > (d) 'git submodule update --init --remote --single-branch lib'\n> > But again, git was fetching the whole 'master' branch of 'lib' before switching to 'light'. This behaviour seems to be independent of the used options of 'git submodule update'.\n> > \n> \n> I can partly reproduce that behaviour. The following script creates \"lib\" with two branches,\n> master and light, that *do not* share any history.\n> \n> ~~~\n> #!/bin/bash\n> \n> TEST_AUTHOR_LOCALNAME=author\n> TEST_AUTHOR_DOMAIN=example.com\n> GIT_AUTHOR_EMAIL=${TEST_AUTHOR_LOCALNAME}@${TEST_AUTHOR_DOMAIN}\n> GIT_AUTHOR_NAME='A U Thor'\n> GIT_AUTHOR_DATE='1112354055 +0200'\n> TEST_COMMITTER_LOCALNAME=committer\n> TEST_COMMITTER_DOMAIN=example.com\n> GIT_COMMITTER_EMAIL=${TEST_COMMITTER_LOCALNAME}@${TEST_COMMITTER_DOMAIN}\n> GIT_COMMITTER_NAME='C O Mitter'\n> GIT_COMMITTER_DATE='1112354055 +0200'\n> export GIT_AUTHOR_EMAIL GIT_AUTHOR_NAME\n> export GIT_COMMITTER_EMAIL GIT_COMMITTER_NAME\n> export GIT_COMMITTER_DATE GIT_AUTHOR_DATE\n> \n> mkdir test\n> cd test\n> \n> rm -rf project lib clone\n> \n> git init lib && cd lib\n> echo \"content\">file\n> git add file\n> git commit -m \"initial on master in lib\"\n> git checkout --orphan light\n> echo \"content\">file\n> git add file\n> git commit -m \"initial on light in lib\"\n> # Switch HEAD back to master\n> git checkout master\n> cd ../\n> \n> git init project && cd project\n> echo \"content\">file\n> git add file\n> git commit -m \"initial in proj\"\n> git submodule add -b light ../lib\n> git commit -m \"add lib to project\"\n> cd ../\n> \n> git clone project clone && cd clone\n> echo 'RUNNING: git submodule update --init --remote --single-branch'\n> # This fails\n> git submodule update --init --remote --single-branch\n> echo 'RUNNING: ls -al lib'\n> ls -al lib\n> echo 'RUNNING: git -C lib ls-files -s'\n> git -C lib ls-files -s\n> echo 'RUNNING: git -C lib branch --all'\n> git -C lib branch --all\n> echo 'RUNNING: git -C lib config --get remote.origin.fetch'\n> git -C lib config --get remote.origin.fetch\n> # Try to update again\n> echo 'RUNNING: git submodule update'\n> GIT_TRACE2=1 git submodule update 2> >(grep -E 'start git fetch|^From|^ \\*' )\n> ~~~\n> \n> The output should end with:\n> \n> RUNNING: git submodule update --init --remote --single-branch\n> Submodule 'lib' (/Users/Philippe/Code/GIT-devel/test/lib) registered for path 'lib'\n> Cloning into '/Users/Philippe/Code/GIT-devel/test/clone/lib'...\n> done.\n> fatal: Needed a single revision\n> Unable to find current origin/light revision in submodule path 'lib'\n> RUNNING: ls -al lib\n> total 8\n> drwxr-xr-x 3 Philippe staff 102 Jan 6 14:03 .\n> drwxr-xr-x 6 Philippe staff 204 Jan 6 14:03 ..\n> -rw-r--r-- 1 Philippe staff 28 Jan 6 14:03 .git\n> RUNNING: git -C lib ls-files -s\n> RUNNING: git -C lib branch --all\n> * master\n> remotes/origin/HEAD -> origin/master\n> remotes/origin/master\n> RUNNING: git -C lib config --get remote.origin.fetch\n> +refs/heads/master:refs/remotes/origin/master\n> RUNNING: git submodule update\n> 14:14:09.745288 common-main.c:49 start git fetch\n> 14:14:09.892463 common-main.c:49 start git fetch origin cc09362ae7314174785faed3e5ee72a8e2db5460\n> From /Users/Philippe/Code/GIT-devel/test/lib\n> * branch cc09362ae7314174785faed3e5ee72a8e2db5460 -> FETCH_HEAD\n> Submodule path 'lib': checked out 'cc09362ae7314174785faed3e5ee72a8e2db5460'\n> \n> You can see that the first 'git submodule update --init --remote --single-branch'\n> fails. 'ls' and 'ls-files' tell us that the submodule is not checked out,\n> and that the submodule index is empty.\n> 'git branch' and 'git config' then reveal that indeed only the 'master' branch exists\n> in the submodule, so '--single-branch' was passed correctly but not the branch itself.\n> Afterwards, issuing 'git submodule update' a second time will issue a simple 'git fetch',\n> which will not work because of the single-branch refspec, then it will try fetching\n> the commit by its hash, which works, and then it will checkout that commit.\n\nThanks for your work! I can confirm that your script is reproducing the bug.\nHowever, I could observe when removing the '--remote' option, that 'git submodule update' would already fetch & checkout the commit during the first run: \n\nRUNNING: git submodule update --init --single-branch\nSubmodule 'lib' (D:/Repositories/test/lib) registered for path 'lib'\nCloning into 'D:/Repositories/test/clone/lib'...\ndone.\nFrom D:/Repositories/test/lib\n * branch            cc09362ae7314174785faed3e5ee72a8e2db5460 -> FETCH_HEAD\nSubmodule path 'lib': checked out 'cc09362ae7314174785faed3e5ee72a8e2db5460'\nRUNNING: ls -al lib\ntotal 2\ndrwxr-xr-x 1 krum_sv 1363622  0 Jan  8 13:37 .\ndrwxr-xr-x 1 krum_sv 1363622  0 Jan  8 13:37 ..\n-rw-r--r-- 1 krum_sv 1363622 28 Jan  8 13:37 .git\n-rw-r--r-- 1 krum_sv 1363622  9 Jan  8 13:37 file\nRUNNING: git -C lib ls-files -s\n100644 d95f3ad14dee633a758d2e331151e950dd13e4ed 0       file\nRUNNING: git -C lib branch --all\n* (HEAD detached at cc09362)\n  master\n  remotes/origin/HEAD -> origin/master\n  remotes/origin/master\nRUNNING: git -C lib config --get remote.origin.fetch\n+refs/heads/master:refs/remotes/origin/master\nRUNNING: git submodule update\n\n> Looking at commit 132f600b06 (clone: pass --single-branch during,\n> --recurse-submodules, 2020-02-20), which introduced the '--single-branch'\n> option for 'git submodule update', it seems that what we have at the moment\n> is partly a documentation bug, i.e. the doc should say\n> \"Clone only the history leading up to the remote HEAD during update\",\n> and not mention '--branch' at all. I'm CC-ing Emily and Peff who were involved\n> in that series. Looking at the mailing list thread where\n> this feature was discussed [2], it seems that mentioning 'branch' in the description\n> of 'single-branch' was just a leftover from v1 of the series that was forgotten\n> in later iterations.\n\nI do not fully agree that this is just a documentation bug, as in my use-case I do not want fetch the 'master' branch at all (~900MB vs. ~10MB traffic on our build servers for each job). As you can see in the output above the remote HEAD (pointing to 'master') will be fetched any time. However, for fetching the 'light' branch, or the corresponding commit by hash, this traffic would not be necessary.\nIn the example script this problem is not so obvious as the 'master' branch does not contain any large files.\n\n> Also,looking at the code, the '--remote' option has no effect at all for the initial clone\n> of the submodule. It is only taken into account after the initial clone.\n> I think it would make sense for it to also influence the initial\n> clone, so that it would behave as you expect, i.e. the code looks at the branch\n> in '.gitmodules' and this branch is passed to the underlying 'git clone' if '--single-branch'\n> was passed to 'git submodule update'.\n\nPlease see above the different behaviour with or without the '--remote' option - I guess we have here two closely related bugs.\nBesides that, I agree that the '--remote' option should also influence the initial clone.\n\n> > What did you expect to happen? (Expected behavior)\n> > (a) or (b) To create a submodule which is tracking the 'light' branch of 'lib' and to fetch *only* this branch.\n> That would be a diffenret feature request, and I think it does make sense\n> for (b) to work. I don't think that '--branch' should automatically\n> imply '--single-branch' though (i.e. I don't think (a) should change\n> behaviour).\n\nYes, adding the '--single-branch' option to 'git submodule add' would be very helpful!\n\n> > (d) To fetch and checkout *only* the 'light' branch of 'lib'.\n> > \n> > \n> > What happened instead? (Actual behavior)\n> > (a) Fetching 'master' (or the full 'lib' repo?), then checking out the 'light' branch.\n> Yes, this does a plain 'git clone' so all branches are fetched.\n> \n> > (b) Error as option '--single-branch' is not supported for 'git submodule add'.\n> > (d) Fetching 'master' (or the full 'lib' repo?), then checking out the 'light' branch.\n> As my script above shows, this does fetch only the 'master' branch, and then *if* we issue\n> a second 'git submodule update' it then fetches the required commmit by hash and checks it out.\n> It would be nice if you could send a reproducer (i.e. a complete script like the above) that\n> shows exactly the behaviour you are seeing, if indeed in your scenario it really checks out\n> the 'light' branch. I'm not sure I understand how that could happen...\n\nSorry, I think I was describing the behaviour of 'git submodule update --init --single-branch' instead\nof 'git submodule update --init --remote --single-branch' (I've been playing around with a lot of different setups). \nYour script is reproducing this bug quite well when omitting the '--remote' option, so I recommend to stay with this baseline.\n\n> > What's different between what you expected and what actually happened?\n> > As the 'master' branch of 'lib' is quite heavy-weighted, I do not want to fetch 'master' at all. By using the option '-b light' to specify which branch shall be tracked, there is no need to fetch other branches besides 'light'. I'm not sure if it is really necessary for 'git submodule add' to fetch anything, as this could also be done by a subsequent 'git submodule update'.\n> In the past, 'git submodule add' used to not clone the submodule at all,\n> but this was deemed not very useful so now it does 'git clone' underneath.\n> \n> > Anything else you want to add:\n> > This issue could be related to: https://stackoverflow.com/questions/61483547/how-to-shallow-pull-submodule-that-is-tracked-by-branch-name\n> \n> \n> Hope that helps,\n> \n> Philippe.\n> \n> [1] https://git-scm.com/docs/git-submodule#Documentation/git-submodule.txt--bltbranchgt\n> [2] https://lore.kernel.org/git/20200108231900.192476-1-emilyshaffer@google.com/t/#u\n\nThanks for your help! :)\n\nKind regards,\nSven Krummen\n"}]}