Xavier Morel <xmo@xxxxxxxx> 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@xxxxxxxxx/ [2]: https://lore.kernel.org/git/20250221074854.GC1988395@xxxxxxxxxxxxxxxxxxxxxxx/ [3]: https://lore.kernel.org/git/87o6z43gz8.fsf@xxxxxxxxx/ [4]: https://lore.kernel.org/git/20250221073605.GA1988395@xxxxxxxxxxxxxxxxxxxxxxx/ -- Toon
