Re: [PATCH 2/2] clone: remember references for submodules even when not recursing

From: Stefan Beller <sbeller@google.com>
Date: Apr 20, 2017, 22:28 UTC
Message-ID: <CAGZ79kYug=5vggaU9qruKK=N7efrMm7B98xjn-hNgghZUzsAiQ@mail.gmail.com>
In-Reply-To: <20170420221255.GI142567@google.com>

On Thu, Apr 20, 2017 at 3:12 PM, Brandon Williams <bmwill@google.com> wrote:

Show 14 quoted lines

> 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-3af5024ae7dd@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