git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Derrick Stolee via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Jonathan Tan <jonathantanmy@google.com>,
	Taylor Blau <me@ttaylorr.com>,
	Derrick Stolee <derrickstolee@github.com>,
	Derrick Stolee <dstolee@microsoft.com>
Subject: Re: [PATCH] clone: --filter=tree:0 implies fetch.recurseSubmodules=no
Date: Fri, 20 Nov 2020 19:04:36 -0500
Message-ID: <20201121000436.GB353076@coredump.intra.peff.net> (raw)
In-Reply-To: <pull.797.git.1605904586929.gitgitgadget@gmail.com>

On Fri, Nov 20, 2020 at 08:36:26PM +0000, Derrick Stolee via GitGitGadget wrote:

> I decided that even if I did populate the submodules, the nature of
> treeless clones makes me not want to care about the contents of commits
> other than those that I am explicitly navigating to.
> 
> This loop of tree fetches can be avoided by adding
> --no-recurse-submodules to the 'git fetch' command or setting
> fetch.recurseSubmodules=no.
> 
> To make this as painless as possible for future users of treeless
> clones, automatically set fetch.recurseSubmodules=no at clone time.

I think it's definitely worth adjusting the defaults here to make this
less painful out of the box. But I wonder if this is too big a hammer,
and the on-demand logic just needs to be a bit less aggressive.

If I clone with tree:0, I'm still going to get the tree for the thing
I'm actually checking out (assuming a non-bare repo). It would be
reasonable to recursively fetch the submodules in that commit to
check them out (assuming you specified --recurse-submodules).

If I then fetch again, I'll end up with another tree that I'm about to
checkout. So likewise, would it make sense to fetch any updates from
there?

I.e., I think the problem is that whether or not cared about submodules
in the first place, the default "on-demand" setting of fetch.submodules
is very eager to poke through history looking at the .gitmodules file to
see if there is anything worth also fetching. But:

  - if we know there are no active submodules in the first place
    (because you did not say --recurse-submodules), should it skip that
    poking? That seems like it shouldn't be too hard.

  - during its poking, should it set the necessary variables so that it
    never demand-fetches from a promisor remote? I suspect this part
    may be hard, because "fetch" and "checkout" are distinct operations
    (so during the "fetch" we don't yet have the new tree demand-fetched
    by checkout; in fact the user might not even be interested in
    checking it out yet).

Given the difficulties in the latter case, this may be the best we can
do. But in that case, what happens when we _do_ care about submodules,
and do:

  git clone --recurse-submodules --filter=tree:0 ...
  git fetch
  git merge origin

Will we correctly fetch-on-demand the submodules we need during the
merge operation? If so, then that user experience is probably pretty
reasonable.

-Peff

  reply	other threads:[~2020-11-21  0:07 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-20 20:36 Derrick Stolee via GitGitGadget
2020-11-21  0:04 ` Jeff King [this message]
2020-11-23 15:18   ` Derrick Stolee
2020-11-24  8:04     ` Jeff King
2020-11-21 16:19 ` Philippe Blain

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=20201121000436.GB353076@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=derrickstolee@github.com \
    --cc=dstolee@microsoft.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=jonathantanmy@google.com \
    --cc=me@ttaylorr.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

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for the project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git