git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ronan Pigott" <ronan@rjp.ie>
To: "Jeff King" <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: Fetching too many tags?
Date: Fri, 11 Aug 2023 22:06:43 +0000	[thread overview]
Message-ID: <5a0544e570fb962c95840d99994bf45aa638faa8@rjp.ie> (raw)
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.

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

> 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

  parent reply	other threads:[~2023-08-11 22:07 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-10  6:08 Fetching too many tags? Ronan Pigott
2023-08-11 18:09 ` Jeff King
2023-08-11 22:06 ` Ronan Pigott [this message]
2023-08-11 23:58   ` Jeff King
2023-08-12  1:04   ` Ronan Pigott

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5a0544e570fb962c95840d99994bf45aa638faa8@rjp.ie \
    --to=ronan@rjp.ie \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).