git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Fetch remote only if remote hasn't been fetched recently

From
Junio C Hamano <gitster@pobox.com>
Date
Jun 11, 2025, 15:23 UTC
Message-ID
<xmqqjz5ijo97.fsf@gitster.g>
In-Reply-To
<CAGJzqs=Xur+=0=KUSR6TQA-A3zt-Bpyd5-T52_ntuV+mCUrAQA@mail.gmail.com>
M Hickford <mirth.hickford@gmail.com> writes:
Show 8 quoted lines
>>     $ 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/*"
Previous: M HickfordNext: M Hickford
Message 7 of 8 in “Fetch remote only if remote hasn't been fetched recently”
  1. M HickfordJun 5, 2025
  2. Konstantin RyabitsevJun 5, 2025
  3. Junio C HamanoJun 5, 2025
  4. M HickfordJun 7, 2025
  5. Junio C HamanoJun 9, 2025
  6. M HickfordJun 11, 2025
  7. Junio C HamanoJun 11, 2025
  8. M HickfordJul 1, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.