public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Toon claes <toon@iotcl•com>
To: ellie <el@horse64•org>, Junio C Hamano <gitster@pobox•com>,
	Emily Shaffer <nasamuffin@google•com>
Cc: Jeff King <peff@peff•net>, rsbecker@nexbridge•com, git@vger•kernel.org
Subject: Re: With big repos and slower connections, git clone can be hard to work with
Date: Thu, 13 Jun 2024 12:10:19 +0200	[thread overview]
Message-ID: <87msnpjgqc.fsf@iotcl.com> (raw)
In-Reply-To: <f5c24dfc-8d35-4418-b8f6-0a03d70c0917@horse64.org>

ellie <el@horse64•org> writes:

> Sorry for again another total newcomer/outsider question:

Don't apologize for asking these questions, you're more than welcome.

> Is a bundle or pack file something any regular git HTTPS instance
> would naturally provide when setup the usual ways?

Yes and no. Bundle and packfile format can used in many places.
Packfiles are used to transfer a bunch of objects, or store them locally
in Git's object database. A bundle is a packfile, but with a leading
header describing refs. You can read about that at
https://git-scm.com/docs/gitformat-bundle.

> Like, if resume relied on that, would this work when following the
> standard smart HTTP setup procedure
> https://git-scm.com/book/en/v2/Git-on-the-Server-Smart-HTTP (sorry if
> I got the wrong link) and then git cloning from that? That would
> result in the best availability of such a resume feature, if it ever
> came to be.

As mentioned elsewhere in the thread, on clone (and fetch) the client
negotiates with the server which objects to download. Because the state
of the remote repository can change between clones, so will the result
of this negotiation. This means the content of the packfile sent over
might differ, which is disruptive for caching these files.

That's why the proposal of bundle URI or packfile URI is suggested. In
case of bundle URI, it will tell the client to download a pre-made
bundle before starting the negotiation. This bundle can be stored on a
CDN or whatever static HTTP(s) server. But it requires the server to
create it, store it, and tell the client about it. This is not something
that's builtin into Git itself at the moment.

This is not really related to the Smart HTTP protocol, because it can be
used over SSH as well. But when such file is stored on a regular HTTP
server, we can rely on resumable downloads. Only after that bundle is
downloaded, the client will start the negotiation with the server to get
missing objects and refs (which should be a small subset when the bundle
is recent).


--
Toon

  reply	other threads:[~2024-06-13 10:10 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-07 23:28 With big repos and slower connections, git clone can be hard to work with ellie
2024-06-07 23:33 ` rsbecker
2024-06-08  0:03   ` ellie
2024-06-08  0:35     ` rsbecker
2024-06-08  0:46       ` ellie
2024-06-08  8:43         ` Jeff King
2024-06-08  9:40           ` ellie
2024-06-08  9:44             ` ellie
2024-06-08 10:38               ` Jeff King
2024-06-08 10:35             ` Jeff King
2024-06-08 11:05               ` ellie
2024-06-08 19:00           ` Junio C Hamano
2024-06-08 20:16             ` ellie
2024-06-10  6:46           ` Patrick Steinhardt
2024-06-10 19:04           ` Emily Shaffer
2024-06-10 20:34             ` Junio C Hamano
2024-06-10 21:55               ` ellie
2024-06-13 10:10                 ` Toon claes [this message]
2024-06-11  6:31               ` Jeff King
2024-06-11 15:12                 ` Junio C Hamano
2024-06-29  1:53                   ` Sitaram Chamarty
2024-06-11  6:26             ` Jeff King
2024-06-11 19:40               ` Ivan Frade
2024-07-07 23:42         ` ellie
2024-07-08  1:27           ` rsbecker
2024-07-08  2:28             ` ellie
2024-07-08 12:30               ` rsbecker
2024-07-08 12:41                 ` ellie
2024-07-08 14:32                   ` Konstantin Khomoutov
2024-07-08 15:02                     ` rsbecker
2024-07-08 15:14                     ` ellie
2024-07-08 15:31                       ` rsbecker
2024-07-08 15:48                         ` ellie
2024-07-08 16:23                           ` rsbecker
2024-07-08 17:06                             ` ellie
2024-07-08 17:38                               ` rsbecker
2024-07-08 16:09                         ` Emanuel Czirai
2024-07-08 15:44                       ` Konstantin Khomoutov
2024-07-08 16:27                         ` rsbecker
2024-07-14 12:00                           ` ellie
2024-07-24  6:42                           ` ellie
2025-09-08  2:34                           ` Ellie
2024-09-30 21:01 ` Ellie

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=87msnpjgqc.fsf@iotcl.com \
    --to=toon@iotcl$(echo .)com \
    --cc=el@horse64$(echo .)org \
    --cc=git@vger$(echo .)kernel.org \
    --cc=gitster@pobox$(echo .)com \
    --cc=nasamuffin@google$(echo .)com \
    --cc=peff@peff$(echo .)net \
    --cc=rsbecker@nexbridge$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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