Hey, On Wed, Feb 26, 2025 at 12:36 AM Derrick Stolee <stolee@xxxxxxxxx> wrote: > > The intention of the design is to avoid having the bundle URI fetch > changing tag refs, especially annotated tags. Those tag updates are > expected to be advertised in the "git fetch" output. It would probably > be best to peel the tag refs to a commit and then create a fake branch > for the bundle. The issue for this and also for the other suggestion you have later on is that I'm not sure how this can be easily done with the bundle command. It seems like everyone would have to write some sort of script to create a special type of bundle so that all these objects are referenced in a way that makes the bundle-uri helper actually get most of the objects that are needed. Is there some option to rev-list that does this? Or are you saying it's better to write a script? > The biggest question I had (and tried to get ahead of on the PR) is > the use of a test to demonstrate what kind of bundle files cause this > issue. It would be important to demosntrate that the repo is still > usable if "refs/bundles/tags/v1.0" exists and points to a tag object. I have written a test and I'll submit the new series in a minute, but I'm not sure what you mean by 'usable' in this context. Is there a situation where Git gets mad if there are annotated tags that aren't under refs/tags? I have done these test clones and nothing bad seems to happen having them in refs/bundle/tags/v1.0 that I notice, but I don't know how to write a test that specifically verifies that. > So I'm OK with relaxing this to be more flexible, but I'm not sure > why the bundles couldn't be created using "refs/heads/", possibly via > changing the ref names during bundle creation. So same point here. I think the bundle-uri functionality isn't particularly effective if the creation of the bundle needs special scripts to create in a way that is expected. One other approach would be to add an option to `git bundle` that does this sanitization (unpeeling things into fake branch heads), like some `--bundle-for-uri`, but I feel like just using `--all` and having the clone handle it in the way I proposed might be much simpler and more usable. We could also immediately delete everything under `refs/bundle/tags` after the fetch if we don't like them there, but still having them be available for the fetch negotiation. I'll send a new series with the existing tests updated to look for `refs/bundle/heads/*` instead of `refs/bundle/*` and adding a very simple test to see that the tags were unpacked as the next step. Scott
