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

Re: [PATCH v3] fetch: delay fetch_if_missing=0 until after config

From
JTJonathan Tan <jonathantanmy@google.com>
Date
Nov 1, 2019, 20:43 UTC
Message-ID
<20191101204321.234006-1-jonathantanmy@google.com>
In-Reply-To
<xmqqh83s8h3m.fsf@gitster-ct.c.googlers.com>
Show 18 quoted lines
> Jonathan Tan <jonathantanmy@google.com> writes:
> 
> >> > Instead, we can control whether a region of code lazy-fetches...
> >> 
> >> The approach "from here to there, we can set global to forbid
> >> lazy-fetch" may prolong the life support of the quick-and-dirty
> >> mechanism, but it has to assume you can say "from here to there"; it
> >> would mean that we cannot go multi-threaded until we get off of it.
> >
> > By "from here to there", I meant, for example, creating a struct
> > repository in cmd_fetch() that has fetch_if_missing=0, then passing that
> > repository to fetch_pack() (once fetch_pack() and all functions it calls
> > support a repository object).
> 
> I know---but that means the struct cannot be shared among threads
> that are calling object layer, some of which want to lazily fetch
> missing objects while others only want to check the existence, at
> the same time.

That's true. Mixing lazy-fetch and non-lazy-fetch in a function is rare, but admittedly it does happen - in particular, when fetching, the server may send us objects delta-ed against a missing object, and we need to lazy-fetch those missing objects.

Show 6 quoted lines
> Compared to that, judicious use of OBJECT_INFO_SKIP_FETCH_OBJECT and
> other flags by callers can tell the underlying machinery why we are
> interested in the object, which I think is the right direction to go
> in the longer term.  What I am not certain about is if we are ready
> to move to the right direction for the longer term, or we should still
> be relying on the big-hammer global bit for expediency a bit longer.

I've taken a look at this and figured out tests that can demonstrate what exactly is being lazy-fetched (and hopefully will be good enough to prevent future code changes from adding extra lazy-fetches). In this way, maybe we can at least reduce the scope of the big-hammer global.

I just sent out a patch [1].
[1] https://public-inbox.org/git/20191101203830.231676-1-jonathantanmy@google.com/
Previous: Junio C Hamano
Message 11 of 11 in “fetch: delay fetch_if_missing=0 until after config”
  1. fetch: delay fetch_if_missing=0 until after configJonathan Tan, Oct 7, 2019
  2. Emily ShafferOct 23, 2019
  3. fetch: delay fetch_if_missing=0 until after configJonathan Tan, Oct 23, 2019
  4. Emily ShafferOct 23, 2019
  5. fetch: delay fetch_if_missing=0 until after configJonathan Tan, Oct 23, 2019
  6. Junio C HamanoOct 24, 2019
  7. Jonathan TanOct 24, 2019
  8. Junio C HamanoOct 25, 2019
  9. Jonathan TanOct 25, 2019
  10. Junio C HamanoOct 29, 2019
  11. Jonathan TanNov 1, 2019

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.