public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Toon Claes <toon@iotcl•com>
To: Xavier Morel <xmo@odoo•com>, git@vger•kernel.org
Subject: Re: git clone --bundle-uri: provide progress feedback?
Date: Mon, 14 Apr 2025 15:24:36 +0200	[thread overview]
Message-ID: <87a58i6fl7.fsf@iotcl.com> (raw)
In-Reply-To: <bdf4c917-f1b2-4c24-9b59-97d8a770d06d@odoo.com>

Xavier Morel <xmo@odoo•com> writes:

> I've been looking at `--bundle-uri` for a repository of some size (~5 
> million objects, ~10GB fresh cloned though an aggressive gc get it down 
> to under 2), however from a UX perspective it seems to have a bit of an 
> issue: while normally `git clone` provides pretty extensive progress 
> feedback as far as I can see there is no feedback whatsoever while 
> `clone` is interacting with the bundle, even explicitly setting 
> `--verbose` and `--progress`, at least when the bundle is a local file.
>
> I assume bundle-uri is mostly intended for large repositories, for which 
> even a clone with a bundle uri can take a while, and the lack of any 
> sort of feedback until git reaches out to the actual repository to find 
> what was not in the bundle is somewhat distressing.

I agree the UX isn't great. And I've tried to fix that[1].

Unfortunately we faced some issues in that implementation[2] for which
we didn't find a clean fix. Every solution felt hacky.

We came up with another idea[3], but I've never found time to implement
it, because there are still a few technical details to be figured out[4]
and implement the solution wouldn't be so trivial.

Anyhow, I agree it would nice to implement something like this. But at
the moment I'm unfortunately unable to work on this any time soon.

> And side-note, it might make sense to emit a warning when trying to 
> combine `--bundle-uri` with `--filter`? I assume if any filtering 
> happens it happens only on the reconciliation fetch, which should be 
> extremely small compared to the bundle's size. Experimentally with a 
> sample size of (1) using `--filter=tree:0` with a bundle uri yields a 
> larger repository *and* is slower than leaving the filter out.

Use of bundle URIs with filters isn't supported very well overall. For
instance, if the server is advertising bundles, it's also impossible for
the client to know which/if a bundle is available that matches the
filter they provided. It's a known shortcoming in the current design,
and as far I'm aware there no proposed solution yet.

[1]: https://lore.kernel.org/git/20250219-toon-bundleuri-progress-v2-0-a84e7ffa921a@iotcl.com/
[2]: https://lore.kernel.org/git/20250221074854.GC1988395@coredump.intra.peff.net/
[3]: https://lore.kernel.org/git/87o6z43gz8.fsf@iotcl.com/
[4]: https://lore.kernel.org/git/20250221073605.GA1988395@coredump.intra.peff.net/

-- 
Toon

      reply	other threads:[~2025-04-14 13:24 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-11 11:07 git clone --bundle-uri: provide progress feedback? Xavier Morel
2025-04-14 13:24 ` Toon Claes [this message]

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=87a58i6fl7.fsf@iotcl.com \
    --to=toon@iotcl$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=xmo@odoo$(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