Scott Chacon <schacon@xxxxxxxxx> writes: > 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. I am not sure where that need to avoid including tags comes from. >> 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 do not know of any at least for a local consumption of these 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. Can it be some brittleness Derrick is worried about auto-following of tags during future "git fetch"? You store a tag that a regular fetch may want to store at refs/tags/v1.0 in refs/bundles/tags/v1.0 taken from the bundle, and then a later fetch may advance the history based on you extracted from the bundle---without having to run an explicit "git fetch --tags" or "git fetch origin v1.0", would we ever obtain "refs/tags/v1.0" with only the usual auto-following when we have the same tag elsewhere? In any case, instead of me speculating, I'd prefer to hear from Derrick, who is a lot more familiar with the mechanism under discussion, what the issues are that we want to limit ourselves to local branches. Thanks.
