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

Stefan Beller [off-list ref] writes:

 Some submodules in the referenced superproject may not be there, 
 (they are just not initialized/cloned/checked out), which yields
 an error for now.

Perhaps you can teach "git clone --reference" an new option
(--reference-if-able) to do this?  Then 

    When `--reference` is given together with `--recursive`,
    the reference repository is assumed to contain the submodules
    as well and the submodules are setup as alternates of the
    submodules in the given reference project.
 
in which "assumed" is a horrible wording (leave the reader
wondering: "so what happens to my data when the assumption does not
hold") can become a lot more reasonable

    When using --reference with --recursive, the --reference is used
    to specify a repository that has a copy of the superproject.  If
    that copy has submodules cloned for itself in its $GIT_DIR/modules,
    they are used as --reference when cloning submodules in the
    resulting clone.

and readers expectation would match with the reality.  Their
submodules would be cloned in a regular fashion if the central
mirror does not have it, and would take advantage of it if there is
already a clone.

Come to think of it, do we even need --super-reference?  "git clone
--reference --recursive" is a two step process, in that first the
superproject is cloned while creating objects/info/alternates, and
then submodules are cloned (via "update --init").  Can we make the
procedure to clone a submodule always look at the reference of the
superproject (i.e. objects/info/alternates) and try to borrow from
the place in it that corresponds to the submodule?  That way, not
just "git clone --reference --recursive" would take advantage of the
existing mirrors of submodules, a user who does this:

    $ git clone --reference $URL super
    $ cd super
    $ git submodule update --init ...

would be able to take advantage of the "what the mirror the
superproject uses already has" when cloning the submodules, no?

On Sat, Aug 6, 2016 at 10:29 AM, Junio C Hamano [off-list ref] wrote:

Stefan Beller [off-list ref] writes:

quoted

 Some submodules in the referenced superproject may not be there,
 (they are just not initialized/cloned/checked out), which yields
 an error for now.

Perhaps you can teach "git clone --reference" an new option
(--reference-if-able) to do this?  Then

    When `--reference` is given together with `--recursive`,
    the reference repository is assumed to contain the submodules
    as well and the submodules are setup as alternates of the
    submodules in the given reference project.

in which "assumed" is a horrible wording (leave the reader
wondering: "so what happens to my data when the assumption does not
hold") can become a lot more reasonable

    When using --reference with --recursive, the --reference is used
    to specify a repository that has a copy of the superproject.  If
    that copy has submodules cloned for itself in its $GIT_DIR/modules,
    they are used as --reference when cloning submodules in the
    resulting clone.

and readers expectation would match with the reality.  Their
submodules would be cloned in a regular fashion if the central
mirror does not have it, and would take advantage of it if there is
already a clone.

That makes sense.

Come to think of it, do we even need --super-reference?  "git clone
--reference --recursive" is a two step process, in that first the
superproject is cloned while creating objects/info/alternates, and
then submodules are cloned (via "update --init").  Can we make the
procedure to clone a submodule always look at the reference of the
superproject (i.e. objects/info/alternates) and try to borrow from
the place in it that corresponds to the submodule?  That way, not
just "git clone --reference --recursive" would take advantage of the
existing mirrors of submodules, a user who does this:

    $ git clone --reference $URL super
    $ cd super
    $ git submodule update --init ...

would be able to take advantage of the "what the mirror the
superproject uses already has" when cloning the submodules, no?

That would work, too.

I'll implement that.

Thanks,
Stefan