Re: [PATCH] bundle-uri: copy all bundle references ino the refs/bundle space

From: Derrick Stolee <stolee@gmail.com>
Date: Mar 3, 2025, 18:46 UTC
Message-ID: <1d946797-e4d9-4c53-a728-ef80657e1431@gmail.com>
In-Reply-To: <xmqqfrjuvy18.fsf@gitster.g>

On 3/3/25 12:12 PM, Junio C Hamano wrote:

Show 25 quoted lines

> Scott Chacon <schacon@gmail.com> writes:
> 
>> Hey,
>>
>> On Wed, Feb 26, 2025 at 12:36 AM Derrick Stolee <stolee@gmail.com> 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.

Show 17 quoted lines

>> 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