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

"git fetch --refetch" and multiple (separate/orphan) branches

From
Tao Klerks <tao@klerks.biz>
Date
Jun 2, 2023, 21:22 UTC
Message-ID
<CAPMMpoiJ4cNcAR9gO5d-749N3YW-88p1gMnX8ySGgz84Mr9coA@mail.gmail.com>
Hi folks,

I just recently noticed that "--refetch" was added in 2.36, and I got pretty excited - the ability to "fill in" missing blobs after a too-filtered clone is something that I've wanted a number of times, as I mentioned in 2021 in thread https://public-inbox.org/git/CAPMMpohOuXX-0YOjV46jFZFvx7mQdj0p7s8SDR4SQxj5hEhCgg@mail.gmail.com/ .

When I first ran "git fetch --refetch" today however (git 2.38.1, against server git/2.38.4.gl1), with a configured blob filter of "blob:1100M", a much higher size than any blob in the history, it only got a *relatively* small number of objects - 3GB of data rather than the 18GB that a new unfiltered fetch would have retrieved.

After some more testing I tried again, and got the expected outcome that time. The relevant difference between the two attempts is that in the first case, when I only got some of the objects I expected, there was an updated tag as a result of the fetch. The second time, when I got everything, there were no updated refs.

In this repository there are several "independent" sets of branches, and the tag updated in that first fetch belongs to one of the smaller-history branches.

What I believe is happening is that *if* there are refs to be updated (or new refs, presumably), *then* the objects returned to the client are only those required for those refs. If, on the other hand, there are no updated refs, then you get what is advertised in the doc: "all objects as a fresh clone would [...]".

I've tested a couple of different scenarios and the behavior seems consistent with this explanation.

In a repo where all branches are derived from the same history, this probably isn't very noticeable; in the repo I'm working on it makes a huge difference, so the only way I can imagine getting "correct" behavior would be to always to a "git fetch" right before the "git fetch --refetch".

Is this a bug, or expected behavior that should be noted in the doc, or do we consider the multiple-independent-branches usecase to be edge-casey enough to be an easter egg for people like me?

Thanks, Tao

Next: Robert Coup
Message 1 of 3 in “"git fetch --refetch" and multiple (separate/orphan) branches”
  1. Tao KlerksJun 2, 2023
  2. Robert CoupJun 3, 2023
  3. Tao KlerksAug 10, 2023

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.