git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, vdye@github.com,
	Derrick Stolee <derrickstolee@github.com>
Subject: Re: [PATCH] fetch: download bundles once, even with --all
Date: Fri, 31 Mar 2023 10:06:57 -0700	[thread overview]
Message-ID: <xmqqo7o8g89a.fsf@gitster.g> (raw)
In-Reply-To: <pull.1508.git.1680278344173.gitgitgadget@gmail.com> (Derrick Stolee via GitGitGadget's message of "Fri, 31 Mar 2023 15:59:04 +0000")

"Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Derrick Stolee <derrickstolee@github.com>
>
> When fetch.bundleURI is set, 'git fetch' downloads bundles from the
> given bundle URI before fetching from the specified remote. However,
> when using non-file remotes, 'git fetch --all' will launch 'git fetch'
> subprocesses which then read fetch.bundleURI and fetch the bundle list
> again. We do not expect the bundle list to have new information during
> these multiple runs, so avoid these extra calls by un-setting
> fetch.bundleURI in the subprocess arguments.

It is a good observation, if we assume that all these remotes want
to share the same expectation on what the list of bundles described
in bundleURI should be.

I expected that people use multiple remotes and do a "fetch --all"
before starting work from a cronjob or while fetching coffee first
time in the morning to fetch from repositories holding work from
different folks and manged by different groups, and these groups do
not tightly share the object management recipes at what bundles to
pre-package and list in the list served at a bundleURI.  If there is
such an arrangement between repositires to share the object
management, even if the repositories fetched with the "--all" option
are truly multiple places, it may make sense to assume that these
repositories you are fetching from want you to use the same set of
bundles that are managed the same way to be used.  But I am not sure
if that assumption holds true.

Where does fetch.bundleURI come originally?  If we set only one
globally for the local repository at "git clone" time, perhaps that
is a problem?  IOW, instead of fetch.bundleURI, we would want to
have something per remote, e.g. remote.<name>.bundleURI, instead?

Putting that design level tangent aside, everything I see in this
patch makes sense, assuming that the fetch_bundle_uri() call done
fairly early in the parent process is sufficient to tell the child
processes that deal with individual repositories to reuse the info
that was already retrieved that call.

Thanks.


  reply	other threads:[~2023-03-31 17:07 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-31 15:59 [PATCH] fetch: download bundles once, even with --all Derrick Stolee via GitGitGadget
2023-03-31 17:06 ` Junio C Hamano [this message]
2023-03-31 18:09   ` Derrick Stolee
2023-04-01  8:22 ` Jeff King
2023-04-03 18:32   ` 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=xmqqo7o8g89a.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=derrickstolee@github.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=vdye@github.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).