[PATCH 1/3] fast-import: rename mem_pool to fi_mem_pool

From: Jameson Miller Rename the mem_pool variables and structs in fast-import.c that will conflict with an upcoming global mem_pool type. Signed-off-by: Jameson Miller --- fast-import.c | 18 +- 1 file changed, 9 insertions(+), 9

[PATCH 0/3] Extract memory pool logic into reusable component

From: Jameson Miller This patch series extracts the memory pool implementation, currently used by fast-import, into a generalized component. This memory pool can then be generally used by any component that needs a pool of memory. This patch is in preparation for a change

[PATCH 2/3] Introduce a reusable memory pool type

From: Jameson Miller Extract the existing memory pool logic used by fast-import into a generalized component. This memory pool component can then be used by other components that need this functionality. Signed-off-by: Jameson Miller --- Makefile

[PATCH 3/3] fast-import: use built-in mem pool

From: Jameson Miller Signed-off-by: Jameson Miller --- fast-import.c | 50 +++--- 1 file changed, 7 insertions(+), 43 deletions(-) diff --git a/fast-import.c b/fast-import.c index 4e68acc156..126f2da118

Re: [PATCH v6 00/11] nd/pack-objects-pack-struct updates

On Wed, Mar 21, 2018 at 04:59:19PM +0100, Duy Nguyen wrote: > About the 16k limit (and some other limits as well), I'm making these > patches with the assumption that large scale deployment probably will > go with custom builds anyway. Adjusting the limits back should be > quite easy while we can

Re: [PATCH v6 00/11] nd/pack-objects-pack-struct updates

Ævar Arnfjörð Bjarmason writes: > That's going to be super rare (and probably nonexisting) edge case, but > (untested) I wonder if something like this on top would alleviate your > concerns, i.e. instead of dying we just take the first N packs up to our > limit: > > diff

<    1   2