Re: [PATCH v2] add test to demonstrate that shallow recursive clones fail

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 30, 2015, 18:11 UTC
Message-ID: <xmqqio4j8iit.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kYDKM2ffdiR-+wQ9=HTgCZMG3UstJiNVrSh7rB1p9xecA@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

Show 15 quoted lines

> +cc Junio, Duy
>
> So cloning from an arbitrary SHA1 is not a new thing I just came up with,
> but has been discussed before[1].
>
> Junio wrote on Oct 09, 2014:
>> This is so non-standard a thing to do that I doubt it is worth
>> supporting with "git clone".  "git clone --branch", which is about
> "> I want to follow that particular branch", would not mesh well with
>> "I want to see the history that leads to this exact commit", either.
>> You would not know which branch(es) is that exact commit is on in
>> the first place.
>
> I disagree with this. This is the *exact* thing you actually want to do when
> dealing with submodules.

Yup, I know, but I do not think the above disagrees with you (read again ;-). It merely says "--branch" option to "clone" is not a good place to add a new "clone at this single commit" mode of operation.

In order to propagate "--single-branch" thru "--recurse-submodules", I suspect that you would need to teach "clone" a new option that is different from "--branch" that allows you to clone the history starting from the commit recorded in the tree of the superproject in the submodule. That would be orthogonal to "--depth $n", of course, in other words, a top-level "--single-branch --recurse-submodules" clone should trigger the "history reachable from a specified commit" mode of clone in submodules, and if the top-level one specified the "--depth" option, the lower-level ones can limit the depth accordingly.