On Thu, Apr 20, 2017 at 3:12 PM, Brandon Williams <bmw...@google.com> wrote: > On 04/11, Stefan Beller wrote: >> The commit 31224cbdc7 (clone: recursive and reference option triggers >> submodule alternates, 2016-08-17) argued for any further `submodule update` >> to respect the initial setup. This is not the case if you only pass >> '--reference[-if-able]' to the initial clone without instructing to >> recurse into submodules. >> >> If there are submodules however the user is likely to later run >> a 'submodule update --init' to obtain the submodules. In this case we >> also want to have the references available. >> > > So the idea is to keep the references around even if the user doesn't > want to recurse immediately?
Yes. This patch is a bug fix response for https://public-inbox.org/git/35343b75-0aa7-3477-888b-3af5024ae...@serato.com/ Note that this breaks the test suite t7407-submodule-foreach.sh 15: test "update --recursive" with a flag with spaces because the reference is recorded but not all submodules can be referenced; the nested submodules are not populated. A couple of thoughts on that * A test for "update --recursive" ought to live in a test other than t7407-submodule-foreach.sh (Maybe in t7406-submodule-update.sh?) * The test checks for white space issues in path names and the breakage shows an unintentional side effect of --reference: it may error out in more cases (not all submodules populated -> error) * Maybe "git submodule update" should learn the --reference-if-able flag, just like git-clone did, to improve the submodule situation? (I put it on my todo list) Thanks, Stefan
