All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Stefan Beller <sbeller@google.com>
Cc: Jens.Lehmann@web.de, git@vger.kernel.org, mst@redhat.com
Subject: Re: [PATCHv2 0/6] git clone: Marry --recursive and --reference
Date: Sat, 06 Aug 2016 10:29:43 -0700	[thread overview]
Message-ID: <xmqqd1lliz5k.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20160806012318.17968-1-sbeller@google.com> (Stefan Beller's message of "Fri, 5 Aug 2016 18:23:12 -0700")

Stefan Beller <sbeller@google.com> 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?

  parent reply	other threads:[~2016-08-06 20:05 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-06  1:23 [PATCHv2 0/6] git clone: Marry --recursive and --reference Stefan Beller
2016-08-06  1:23 ` [PATCHv2 1/6] t7408: modernize style Stefan Beller
2016-08-06  1:23 ` [PATCHv2 2/6] t7408: merge short tests, factor out testing method Stefan Beller
2016-08-06 17:02   ` Junio C Hamano
2016-08-06  1:23 ` [PATCHv2 3/6] submodule--helper module-clone: allow multiple references Stefan Beller
2016-08-06  1:23 ` [PATCHv2 4/6] submodule--helper update-clone: " Stefan Beller
2016-08-06 17:05   ` Junio C Hamano
2016-08-06  1:23 ` [PATCHv2 5/6] submodule update: add super-reference flag Stefan Beller
2016-08-06 17:13   ` Junio C Hamano
2016-08-06  1:23 ` [PATCHv2 6/6] clone: reference flag is used for submodules as well Stefan Beller
2016-08-06 17:29 ` Junio C Hamano [this message]
2016-08-08 18:16   ` [PATCHv2 0/6] git clone: Marry --recursive and --reference Stefan Beller
  -- strict thread matches above, loose matches on Subject: below --
2016-08-09  4:08 Stefan Beller
2016-08-09  5:23 ` Jacob Keller
2016-08-09 15:49 ` Junio C Hamano
2016-08-09 17:26   ` Stefan Beller
2016-08-09 17:47     ` Junio C Hamano
2016-08-09 17:58       ` Junio C Hamano
2016-08-09 18:09       ` Stefan Beller
2016-08-09 18:44         ` Junio C Hamano
2016-08-09 20:31           ` Stefan Beller
2016-08-09 21:45             ` Junio C Hamano
2016-08-09 22:05               ` Stefan Beller
2016-08-10 15:59                 ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqd1lliz5k.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=Jens.Lehmann@web.de \
    --cc=git@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=sbeller@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.