From: Junio C Hamano <gitster@pobox.com>
To: M Hickford <mirth.hickford@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: Fetch remote only if remote hasn't been fetched recently
Date: Wed, 11 Jun 2025 08:23:32 -0700 [thread overview]
Message-ID: <xmqqjz5ijo97.fsf@gitster.g> (raw)
In-Reply-To: <CAGJzqs=Xur+=0=KUSR6TQA-A3zt-Bpyd5-T52_ntuV+mCUrAQA@mail.gmail.com> (M. Hickford's message of "Wed, 11 Jun 2025 08:00:00 +0100")
M Hickford <mirth.hickford@gmail.com> writes:
>> $ git fetch . 'refs/prefetch/remotes/origin/*:refs/remotes/origin/*'
>>
>
> Thanks, that worked.
>
> To support Git users with sporadic connectivity, might it be useful to
> add an option to git fetch? Perhaps `git fetch --offline` or `git
> fetch --complete-prefetch`?
"offline catch-up" is probably the phrase I would prefer to see in
the documentation page to explain the concept of the operation than
"complete prefetch".
"complete prefetch" sounds like an oxymoron, in that the prefetch
has already been completed long ago, and the operation being
proposed is more about using the result of that operation completed
long ago to get yourself closer to the present state of the remote
without any guarantees that you would end up being close enough.
In any case, to present it as a first-class option to end-users,
there needs a lot more thinking and a bit of work need to go into
the way "prefetch" works. For example, the longhand I gave would
work as a good solution only when the user _knows_ that the prefetch
is more recent than their actual remote-tracking branches. If
refs/prefetch/remotes/R/* is older, then you wouldn't be bringing
yourself closer to the present state of the remote at all with such
a fetch, but as far as I know, a normal "git fetch R" from the
remote R would not clear refs/prefetch/remotes/R/* when it
completes. There is no "last time we fetched from there" record
kept anywhere in the repository either. So offhand, you'd at least
need to do these:
- teach "git fetch" that updates remote-tracking branches to remove
the corresponding ref in the refs/prefetch/ hierarchy;
- decide on what option name to use for this new operation and
document it;
- implement the option "git fetch --that-option nickname" to
- figure out the remote-tracking hierarchy for nickname and call
it R
- when refs/prefetch/remotes/R/* exists, do an
$ git fetch . "+refs/prefetch/remotes/R/*:refs/remotes/R/*"
next prev parent reply other threads:[~2025-06-11 15:23 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAGJzqs=kJtPcMrWC8Dayd+VW7BvC1rmzS0zT+EwQXfLOpZ3Tfg@mail.gmail.com>
2025-06-05 11:16 ` Fetch remote only if remote hasn't been fetched recently M Hickford
2025-06-05 14:02 ` Konstantin Ryabitsev
2025-06-05 16:55 ` Junio C Hamano
2025-06-07 7:00 ` M Hickford
2025-06-09 14:08 ` Junio C Hamano
2025-06-11 7:00 ` M Hickford
2025-06-11 15:23 ` Junio C Hamano [this message]
2025-07-01 7:00 ` M Hickford
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=xmqqjz5ijo97.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=mirth.hickford@gmail.com \
/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).