Re: Fetching too many tags?

From: Ronan Pigott <ronan@rjp.ie>
Date: Aug 11, 2023, 22:06 UTC
Message-ID: <5a0544e570fb962c95840d99994bf45aa638faa8@rjp.ie>
In-Reply-To: <20230811180932.GB2816191@coredump.intra.peff.net>

> And the answer, then, is that this is how the Git protocol works. The
> server says "here are all the refs I know about", then the client
> decides what it wants from that list and asks the server to send the
> necessary objects, after which it updates its local refs.

Thanks, this clears up some of my confusion. I had thought that the client sent the server what we had and that the server would then decide what objects to send over.

Show 6 quoted lines

> When you use "--no-tags", that explicitly says "do not bother with tags
> at all". Recent versions of Git have a protocol extension where the
> client can say "I am only interested in refs/heads/master; don't bother
> telling me about other stuff". Since the client knows we do not care
> about tags, it can use that extension to get a much smaller ref
> advertisement from the server.

Do you mean the --negotiation-tip fetch option? In my experience, it doesn't appear to have much of an effect in this case.

  $ time git fetch origin master
  From https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux
   * branch                      master     -> FETCH_HEAD
  git fetch origin master  0.13s user 0.04s system 9% cpu 1.793 total
  $ time git fetch --negotiation-tip=master origin master
  From https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux
   * branch                      master     -> FETCH_HEAD
  git fetch --negotiation-tip=master origin master  0.10s user 0.06s system 9% cpu 1.762 total

Is that because (most) the tags point to commits reachable from master?

My prior (apparently incorrect) understanding of the fetch negotiation is based on my interpretation of the description of this option in git-fetch(1):

Show 6 quoted lines

> By default, Git will report, to the server, commits reachable from all local
> refs to find common commits in an attempt to reduce the size of the
> to-be-received packfile. If specified, Git will only report commits reachable
> from the given tips. This is useful to speed up fetches when the user knows
> which local ref is likely to have commits in common with the upstream ref being
> fetched.

Now, if I understand correctly, the report does not include the tags that we already have?

Cheers, Ronan