{"thread":{"id":"63281","subject":"git clone --bundle-uri: provide progress feedback?","startedAt":"2025-04-11T11:07:31Z","lastAt":"2025-04-14T13:24:52Z","messageCount":2,"participants":["Xavier Morel","Toon Claes"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"515994","messageId":"bdf4c917-f1b2-4c24-9b59-97d8a770d06d@odoo.com","threadId":"63281","inReplyTo":null,"subject":"git clone --bundle-uri: provide progress feedback?","fromName":"Xavier Morel","fromEmail":"xmo@odoo.com","sentAt":"2025-04-11T11:07:28Z","receivedAt":"2025-04-11T11:07:31Z","isPatch":false,"sender":{"key":"xmo@odoo.com","avatar":"https://gravatar.com/avatar/42b8eb16dcf3bd6c1998698115b36ab6f4d69f93710caa10ff8ab04a9652ae34?d=mp&s=160"},"body":"I've been looking at `--bundle-uri` for a repository of some size (~5 \nmillion objects, ~10GB fresh cloned though an aggressive gc get it down \nto under 2), however from a UX perspective it seems to have a bit of an \nissue: while normally `git clone` provides pretty extensive progress \nfeedback as far as I can see there is no feedback whatsoever while \n`clone` is interacting with the bundle, even explicitly setting \n`--verbose` and `--progress`, at least when the bundle is a local file.\n\nI assume bundle-uri is mostly intended for large repositories, for which \neven a clone with a bundle uri can take a while, and the lack of any \nsort of feedback until git reaches out to the actual repository to find \nwhat was not in the bundle is somewhat distressing.\n\nAnd side-note, it might make sense to emit a warning when trying to \ncombine `--bundle-uri` with `--filter`? I assume if any filtering \nhappens it happens only on the reconciliation fetch, which should be \nextremely small compared to the bundle's size. Experimentally with a \nsample size of (1) using `--filter=tree:0` with a bundle uri yields a \nlarger repository *and* is slower than leaving the filter out.\n"},{"id":"516097","messageId":"87a58i6fl7.fsf@iotcl.com","threadId":"63281","inReplyTo":"bdf4c917-f1b2-4c24-9b59-97d8a770d06d@odoo.com","subject":"Re: git clone --bundle-uri: provide progress feedback?","fromName":"Toon Claes","fromEmail":"toon@iotcl.com","sentAt":"2025-04-14T13:24:36Z","receivedAt":"2025-04-14T13:24:52Z","isPatch":false,"sender":{"key":"toon@iotcl.com","avatar":"https://avatars.githubusercontent.com/u/121621?v=4"},"body":"Xavier Morel <xmo@odoo.com> writes:\n\n> I've been looking at `--bundle-uri` for a repository of some size (~5 \n> million objects, ~10GB fresh cloned though an aggressive gc get it down \n> to under 2), however from a UX perspective it seems to have a bit of an \n> issue: while normally `git clone` provides pretty extensive progress \n> feedback as far as I can see there is no feedback whatsoever while \n> `clone` is interacting with the bundle, even explicitly setting \n> `--verbose` and `--progress`, at least when the bundle is a local file.\n>\n> I assume bundle-uri is mostly intended for large repositories, for which \n> even a clone with a bundle uri can take a while, and the lack of any \n> sort of feedback until git reaches out to the actual repository to find \n> what was not in the bundle is somewhat distressing.\n\nI agree the UX isn't great. And I've tried to fix that[1].\n\nUnfortunately we faced some issues in that implementation[2] for which\nwe didn't find a clean fix. Every solution felt hacky.\n\nWe came up with another idea[3], but I've never found time to implement\nit, because there are still a few technical details to be figured out[4]\nand implement the solution wouldn't be so trivial.\n\nAnyhow, I agree it would nice to implement something like this. But at\nthe moment I'm unfortunately unable to work on this any time soon.\n\n> And side-note, it might make sense to emit a warning when trying to \n> combine `--bundle-uri` with `--filter`? I assume if any filtering \n> happens it happens only on the reconciliation fetch, which should be \n> extremely small compared to the bundle's size. Experimentally with a \n> sample size of (1) using `--filter=tree:0` with a bundle uri yields a \n> larger repository *and* is slower than leaving the filter out.\n\nUse of bundle URIs with filters isn't supported very well overall. For\ninstance, if the server is advertising bundles, it's also impossible for\nthe client to know which/if a bundle is available that matches the\nfilter they provided. It's a known shortcoming in the current design,\nand as far I'm aware there no proposed solution yet.\n\n[1]: https://lore.kernel.org/git/20250219-toon-bundleuri-progress-v2-0-a84e7ffa921a@iotcl.com/\n[2]: https://lore.kernel.org/git/20250221074854.GC1988395@coredump.intra.peff.net/\n[3]: https://lore.kernel.org/git/87o6z43gz8.fsf@iotcl.com/\n[4]: https://lore.kernel.org/git/20250221073605.GA1988395@coredump.intra.peff.net/\n\n-- \nToon\n"}]}