From: Derrick Stolee Date: Mon, 03 Mar 2025 18:46:52 GMT Subject: Re: [PATCH] bundle-uri: copy all bundle references ino the refs/bundle space Message-ID: <1d946797-e4d9-4c53-a728-ef80657e1431@gmail.com> In-Reply-To: On 3/3/25 12:12 PM, Junio C Hamano wrote: > Scott Chacon writes: > >> Hey, >> >> On Wed, Feb 26, 2025 at 12:36 AM Derrick Stolee 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. These ideas about avoiding annotated tags outside of refs/tags/ is likely an invention of my own, and must not be a firm expectation of the Git tool. >> 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. My thinking here is similar to the prefetch maintenance task: we want users who run "git fetch [origin]" to see the refs that are being updated by that action in the normal foreground messages. This includes new tag messages, such as in my local copy of the Git repository: $ git fetch origin remote: Enumerating objects: 186, done. remote: Counting objects: 100% (168/168), done. remote: Compressing objects: 100% (51/51), done. remote: Total 186 (delta 120), reused 162 (delta 117), pack-reused 18 (from 2) Receiving objects: 100% (186/186), 118.04 KiB | 10.73 MiB/s, done. Resolving deltas: 100% (122/122), completed with 24 local objects. From github.com:git/git b838bf19389..db91954e186 master -> origin/master 2feabab25ac..627208d89de next -> origin/next + 9b2be6f7989...39dfbbf0521 seen -> origin/seen (forced update) 5fa232d8520..fb8899337a8 todo -> origin/todo * [new tag] v2.49.0-rc0 -> v2.49.0-rc0 As long as these messages are still appearing, then I'm fine with these annotated tags being added to the object database earlier by the bundle URI mechanism. Scott: You also asked about the intended design for bundle URIs and things, and the best places to look are Git's technical docs [1] and the bundle server reference implementation docs [2]. CC Victoria who implemented the reference implementation and wrote those docs. [1] https://github.com/git/git/blob/master/Documentation/technical/bundle-uri.adoc [2] https://github.com/git-ecosystem/git-bundle-server/blob/main/docs/technical/architecture.md Thanks, -Stolee