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

[Junio C Hamano <gitster@pobox.com>]

Stefan Beller <sbeller@google.com> writes:

> At the time of cloning you may run
>
>   git clone --recursive --reference <other-super-project-location>
> or
>   git clone --recursive --reference-if-able <other-super-project-location>
> or
>   git clone --recursive

That's an interesting tangent.  I never meant "if-able" to be an
end-user visible option [*1*], but now you mention it, I do not see
a reason why "clone --reference-if-able" of the top-level project
cannot be used together with "--recursive".

> Then later when we run
>     git submodule update
> we have this option to know if a submodule alternate should be treated
> as optional or required referenced as the existence
> of the superprojects alternate (as a boolean indicator) is not enough of
> an indicator what the user later wants.

A tangent that comes to my mind after reading this is if letting
"if-able" just skip (with or without warning) and forget about it
once a clone is made is what we really want.

Suppose the "other-super-project-location" repository did not have a
clone of a submodule when you create a new clone of the superproject
using it as a reference.  The submodule will be made a full clone,
but after that happens, other-super-project-location can get
interested in the submodule and can acquire its own clone.

At that point, our clone of the submodule _could_ add the submodule
in the other-super-project-location as its alternate and lose the
duplicate objects that it could borrow from there by repacking, but
the suggested "clone with if-able, and forget about it after a clone
is made" would not allow us to do this.  I do not know if a
real-world use of submodules want the ability to do so, or it is
unnecessary.  I suspect with the recording of "you were told that
borrowing from the same location as the superproject is OK", this
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).


[Footnote]

*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.

    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().