From: Junio C Hamano <gitster@pobox.com>
To: Stefan Beller <sbeller@google.com>
Cc: git@vger.kernel.org, larsxschneider@gmail.com, jrnieder@gmail.com
Subject: Re: [RFC/PATCH] clone: add `--shallow-submodules` flag
Date: Fri, 11 Mar 2016 16:41:54 -0800 [thread overview]
Message-ID: <xmqqa8m4a5nx.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <1457739683-1972-1-git-send-email-sbeller@google.com> (Stefan Beller's message of "Fri, 11 Mar 2016 15:41:23 -0800")
Stefan Beller <sbeller@google.com> writes:
> When creating a shallow clone of a repository with submodules, the depth
> argument does not influence the submodules, i.e. the submodules are done
> as non-shallow clones. It is unclear what the best default is for the
> depth of submodules of a shallow clone, so we need to have the possibility
> to do all kinds of combinations:
>
> * shallow super project with shallow submodules
> e.g. build bots starting always from scratch. They want to transmit
> the least amount of network data as well as using the least amount
> of space on their hard drive.
> * shallow super project with unshallow submodules
> e.g. The superproject is just there to track a collection of repositories
> and it is not important to have the relationship between the repositories
> intact. However the history of the individual submodules matter.
> * unshallow super project with shallow submodules
> e.g. The superproject is the actual project and the submodule is a
> library which is rarely touched.
>
> The new switch to select submodules to be shallow or unshallow supports
> all of these three cases.
I think something like this is necessary to prime the well, but the
more important (and intereseting) bit is how this shallowness is
going to be maintained and carried forward across the future updates
to the top-level supermodule. A submodule that was cloned at depth=1
initially along with its supermodule when the latter was initially
cloned does not have to be indefinitely kept at depth=1, and there
would be a lot of creative ways to make it useful, but the creative
and useful logic would need a piece of information to tell the
future "submodule update" why the submodule repository is shallow to
take into account, I would imagine.
It is somewhat curious that there is no hint left in the submodule
repositories (e.g. their configfile) that they are originally
created with an explicit user request "I said that I want these
submodules to be cloned with depth=1", from that point of view.
next prev parent reply other threads:[~2016-03-12 0:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-11 23:41 [RFC/PATCH] clone: add `--shallow-submodules` flag Stefan Beller
2016-03-12 0:41 ` Junio C Hamano [this message]
2016-03-12 0:56 ` Stefan Beller
2016-03-12 19:29 ` Junio C Hamano
2016-03-14 18:17 ` Stefan Beller
2016-03-14 18:37 ` 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=xmqqa8m4a5nx.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
--cc=larsxschneider@gmail.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.