> Jonathan Tan <jonathantanmy@xxxxxxxxxx> 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. > 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@xxxxxxxxxx/
