# git clone --bundle-uri: provide progress feedback?

2 messages from 2025-04-11 to 2025-04-14. Participants: Xavier Morel, Toon Claes.
Thread: https://gitlist.dev/t/63281

## Xavier Morel, 2025-04-11 11:07

Subject: git clone --bundle-uri: provide progress feedback?
Message-ID: <bdf4c917-f1b2-4c24-9b59-97d8a770d06d@odoo.com>
URL: https://gitlist.dev/e/bdf4c917-f1b2-4c24-9b59-97d8a770d06d%40odoo.com

```
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.

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.

```

## Toon Claes, 2025-04-14 13:24

Subject: Re: git clone --bundle-uri: provide progress feedback?
Message-ID: <87a58i6fl7.fsf@iotcl.com>
URL: https://gitlist.dev/e/87a58i6fl7.fsf%40iotcl.com
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

```
