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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 9, 2016, 21:45 UTC
Message-ID: <xmqqeg5x8vl4.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kbPvj6dU1DMaCh7ieJbs0qWimdHSD8xFfUyV98md2pywQ@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

Show 7 quoted lines

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

Show 6 quoted lines

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