From: Junio C Hamano <gitster@pobox•com>
To: Patrick Steinhardt <ps@pks•im>
Cc: "Manuel Quiñones" <manuel.por.aca@gmail•com>, git@vger•kernel.org
Subject: Re: Usability issue: "Your branch is up to date"
Date: Wed, 05 Feb 2025 10:40:41 -0800 [thread overview]
Message-ID: <xmqqikponsk6.fsf@gitster.g> (raw)
In-Reply-To: <Z6MLOA3mJGbPFBae@pks.im> (Patrick Steinhardt's message of "Wed, 5 Feb 2025 07:54:48 +0100")
Patrick Steinhardt <ps@pks•im> writes:
> One thing to consider is that some remotes tend to have many thousands
> or even hundreds of thousands of references. Updating timestamps for all
> of them could be quite inefficient depending on where exactly that data
> is store. If it was in the form of no-op reflog entries, the "files"
> backend would have to touch as many files as the remote has references.
> Consequently, even if only a single remote ref changed, we'd potentially
> have to update metadata on hundreds of thousands of files.
>
> So I'm not sure whether such a schema would scale well enough in the
> general case for large repos.
I actually view that as quite an orthogonal issue.
Recording the fact that you checked the state of thousands of refs
at the remote and found them unchanged is probably a very small part
of a larger problem that checking the state of thousands of refs is
already expensive. People have solved it at the protocol level to
limit the ref advertisement to only the relevant refs (as opposed to
the original protocol where the server end unconditionally
advertises the state of all of its refs at the beginning of the
conversation), so when you are only pulling a single branch from
there, you do not even observe the state of other unrelated refs
(like other branches or pull/*/ hierarchy), hence you would not
create these no-op reflog entries.
If the user, on the other hand, is interested in keeping track of
all these thousands of refs, "git fetch" would have to ask and
receive advertisement for all these thousands of refs anyway, and
at that point, recording the no-op update would be a very small
part of the problem, I suspect. Besides, we have reftable that
would make this kind of problem easier to solve, no? ;-)
next prev parent reply other threads:[~2025-02-05 18:40 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-03 16:45 Usability issue: "Your branch is up to date" Manuel Quiñones
2025-02-03 16:56 ` Junio C Hamano
2025-02-04 0:10 ` Junio C Hamano
2025-02-04 0:28 ` Bram van Oosterhout
[not found] ` <CAPx1GveyP4+yn5NMgvO3JpbOwPRT5=tb9YBx7U1Ufvae7gFnHQ@mail.gmail.com>
[not found] ` <CAMoUM6LstYx3PJcx-Sz3Dfs-1BxF1uP373MO8+eknbO7j-S01Q@mail.gmail.com>
2025-02-04 0:51 ` Fwd: " Bram van Oosterhout
2025-02-04 2:08 ` D. Ben Knoble
2025-02-04 12:53 ` Manuel Quiñones
2025-02-05 3:55 ` Bram van Oosterhout
2025-02-04 12:38 ` Manuel Quiñones
2025-02-04 17:43 ` Junio C Hamano
2025-02-05 6:54 ` Patrick Steinhardt
2025-02-05 18:40 ` Junio C Hamano [this message]
2025-02-06 9:53 ` Patrick Steinhardt
2025-02-07 8:20 ` Karthik Nayak
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=xmqqikponsk6.fsf@gitster.g \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=manuel.por.aca@gmail$(echo .)com \
--cc=ps@pks$(echo .)im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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