韩仰 <hanyang.tony@xxxxxxxxxxxxx> writes: > On Sun, Sep 22, 2024 at 2:53 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > > I was hoping to see that the issue can be fixed on the "gc" side, > > regardless of how the objects enter our repository, but perhaps I am > > missing something. Isn't it just the matter of collecting C1, C3 > > but not C2? Or to put it another way, if we first create a list of > > objects to be packed (regardless of whether they are in promisor > > packs), and then remove the objects that are in promisor packs from > > the list, and pack the objects still remaining in the list? > > I tried to fix the issue on the "gc" side following JTan's suggestion, > by packing local objects referenced by promisor objects into promisor > packs. But it turns out the cost for "for each promisor object, > parse them and try to decide the objects they reference is in local repo" > is too great. In a test blob:none partial clone repo, the gc would take more > than one hour in the 2019 MacBook, despite the repo only > having 17071073 objects. Normally it would take about 30 minutes. I found that running `time git submodule foreach git <create promisor pack set>` on Android takes 25 minutes on my machine. Granted this is single threaded but it's still quite an expensive operation to be doing on every recursive fetch. If this operation is so expensive, then unless we can figure out some method that doesn't involve creating a set of promisor pack objects, solving this during fetch is infeasible.
