{"thread":{"id":"44795","subject":"Wanted: shallow submodule clones with --no-single-branch.","startedAt":"2016-12-30T10:51:04Z","lastAt":"2017-01-03T19:21:48Z","messageCount":2,"participants":["Tor Andersson","Stefan Beller"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"308513","messageId":"CAAmwXB=M8yZY2sFLwavrrQSEW9bipFhNZyLduwYXtZNK6-Ppxg@mail.gmail.com","threadId":"44795","inReplyTo":null,"subject":"Wanted: shallow submodule clones with --no-single-branch.","fromName":"Tor Andersson","fromEmail":"tor@ccxvii.net","sentAt":"2016-12-30T10:50:56Z","receivedAt":"2016-12-30T10:51:04Z","isPatch":false,"sender":{"key":"tor@ccxvii.net","avatar":null},"body":"Hi,\n\nWhen adding submodules with --depth=1 only the master branch is\ncloned. This often leaves the submodule pointing to a non-existing\ncommit.\n\nIt would be useful if I could pass the --no-single-branch argument to\nthe submodule clone process, since then a submodule can point to any\ntag or branch without ending up in this situation. I've got a local\npatch to hardwire the --no-single-branch argument in the\nbuiltin/submodule--helper.c clone_submodule function, but I'm not sure\nif this will have any other adverse effects?\n\nBetter yet would be for the shallow submodule clone to automatically\nretrieve and graft the actual commit the submodule points to, but\nthat's probably wishing for too much.\n\n-Tor\n"},{"id":"308737","messageId":"CAGZ79kYZwSM78FoytDm9VhFY0D=Z1tzoq=tW7h65kSCYSr0grQ@mail.gmail.com","threadId":"44795","inReplyTo":"CAAmwXB=M8yZY2sFLwavrrQSEW9bipFhNZyLduwYXtZNK6-Ppxg@mail.gmail.com","subject":"Re: Wanted: shallow submodule clones with --no-single-branch.","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-01-03T19:21:42Z","receivedAt":"2017-01-03T19:21:48Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Fri, Dec 30, 2016 at 2:50 AM, Tor Andersson <tor@ccxvii.net> wrote:\n> Hi,\n>\n> When adding submodules with --depth=1 only the master branch is\n> cloned. This often leaves the submodule pointing to a non-existing\n> commit.\n\nYou can also use the \"--branch=not_master\" flag to track another branch.\nThis however doesn't clone the correct branch. I would have expected that\nit cloned the correct branch instead.\n\n>\n> It would be useful if I could pass the --no-single-branch argument to\n> the submodule clone process, since then a submodule can point to any\n> tag or branch without ending up in this situation.\n\n\nAdding --no-single-branch sounds like a good idea for general use,\nbut it seems like a clunky workaround when looking for a specific branch,\ni.e. fixing the --branch flag sounds like the right approach for this\nissue here?\n\n> I've got a local\n> patch to hardwire the --no-single-branch argument in the\n> builtin/submodule--helper.c clone_submodule function, but I'm not sure\n> if this will have any other adverse effects?\n\nWell, when asking for depth=1, the user usually actually wants to have the\nleast amount of data, which is why --depth implies --single-branch\nin clone.\n\nSo adding it unconditionally is a bad idea IMHO, we'd need to have a flag\nfor that propagated from git-submodule.sh (function cmd_add) to the\nsubmodule--helpers module_clone.\n\n>\n> Better yet would be for the shallow submodule clone to automatically\n> retrieve and graft the actual commit the submodule points to, but\n> that's probably wishing for too much.\n\nI think fixing the branch option comes a bit closer, but still doesn't\nfix this root problem. \"submodule update\" tries to fetch by sha1\ndirectly in the hope that the server has uploadpack.\\\nallowReachableSHA1InWant configured.\n\nIn \"submodule add\" I think it is sufficient to take the current remotes\n$branch and record that, so I do not see the need in the add code\nto support direct sha1s unlike the update command?\n\nThanks,\nStefan\n"}]}