[0/3] Extend and add a little more generalization to the mem_pool API

Message

Philippe Blain via GitGitGadget Aug. 14, 2020, 3:02 a.m. UTC

In my new merge algorithm, I made use of the mem_pool API in a few
places...but I also needed to add a few more functions. More importantly,
though, I couldn't reuse the existing API as-is since I want to be able to
discard the memory (after each recursive merge) and then continue adding to
the pool, something the existing API was not amenable to. Instead of writing
another competing API, since there is only one other user, I just modified
the existing callsites to use the more generic calling structure that I
needed.

Unfortunately, Matheus' parallel-checkout RFC series (not yet in next or
seen as far as I can tell) adds a few more mem_pool callers, so this series
conflicts with his (semantically). I can rebuild mine on top of his, or,
since his is longer and would probably advance more slowly, it may make
sense to have his series be based on this one. If so, I'm happy to help him
update his to depend on this series. Let me know preferences.

Elijah Newren (3):
  mem-pool: add convenience functions for xstrdup and xstrndup
  mem-pool: use more standard initialization and finalization
  mem-pool: use consistent pool variable name

 fast-import.c | 12 ++-------
 mem-pool.c    | 75 ++++++++++++++++++++++++++++++++-------------------
 mem-pool.h    | 14 +++++++---
 read-cache.c  | 21 +++++++++------
 split-index.c |  6 +++--
 5 files changed, 76 insertions(+), 52 deletions(-)


base-commit: 7814e8a05a59c0cf5fb186661d1551c75d1299b5
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-830%2Fnewren%2Fmem_pool_api-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-830/newren/mem_pool_api-v1
Pull-Request: https://github.com/git/git/pull/830

Comments

Matheus Tavares Aug. 14, 2020, 3:51 a.m. UTC | #1

Hi, Elijah

On Fri, Aug 14, 2020 at 12:02 AM Elijah Newren via GitGitGadget
<[e-mail]> wrote:
>
> Unfortunately, Matheus' parallel-checkout RFC series (not yet in next or
> seen as far as I can tell) adds a few more mem_pool callers, so this series
> conflicts with his (semantically). I can rebuild mine on top of his, or,
> since his is longer and would probably advance more slowly, it may make
> sense to have his series be based on this one. If so, I'm happy to help him
> update his to depend on this series. Let me know preferences.

Thanks for the heads up. Yeah, let me rebuild my series on top of
yours. From a quick look at your patches, I think it should be quite
straightforward to rebase my changes.