On 3/3/25 12:12 PM, Junio C Hamano wrote:
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.
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
