Re: [PATCHv2 0/6] git clone: Marry --recursive and --reference

[Stefan Beller <sbeller@google.com>]

On Tue, Aug 9, 2016 at 2:45 PM, Junio C Hamano <gitster@pobox.com> wrote:
> becomes easily doable (i.e. subsequent "submodule update" can realize
> that the submodule does not have alternates but it could borrow from
> the submodule in the other-super-project-location).

I would suggest to postpone this to a later time once the need arises.

I rather imagine that once you clone from "other-super-project-location"
and get the warning about no alternates borrowing, you can decide if you want
to set it up and link the submodule manually to that alternate, or if you just
don't care about this one repository being duplicated.

For now I plan to introduce 2 options, as these are 2 different things, that
can be extended independently of each other:

submodule.alternateLocation::
    Specifies how the submodules obtain alternates when submodules are
    cloned. Possible values are `no`, `superproject`.
    By default `no` is assumed, which doesn't add references. When the
    value is set to `superproject` the submodule to be cloned computes
    its alternates location relative to the superprojects alternate.

submodule.alternateErrorStrategy::
    Specifies how to treat errors with the alternates for a submodule
    as computed via `submodule.alternateLocation`. Possible values are
    `ignore`, `info`, `die`.

> *1* Rather, I meant: clone has a very intimate knowledge on what and
>     what cannot be borrowed from and it is not just "is there a
>     directory?", so "git submodule update --init" is not in a good
>     position to decide if it wants to add --reference to the
>     invocation of "git clone" it makes internally, and introducing
>     an "if-able" variant to "clone" is one way to relieve it from
>     having to make that decision.

That is how I first understood the design as well.

>
>     I could have suggested an alternative: because the submodule
>     machinery is gettting moved to C the "update --init" code that
>     drives the internal invocation of "git clone" could share the
>     the logic in "git clone --reference" that determines if a local
>     repository can be used as an alternate by small refactoring of
>     builtin/clone.c::add_one_reference().

I see. I might actually need to do this anyway as the helper is a place
to act on the submodule.alternateErrorStrategy.