Re: What's cooking in git.git (Dec 2024, #10; Sat, 28)

[Patrick Steinhardt <ps@pks.im>]

On Sat, Dec 28, 2024 at 02:23:56PM -0800, Junio C Hamano wrote:
> * ps/more-sign-compare (2024-12-27) 10 commits
>  - sign-compare: avoid comparing ptrdiff with an int/unsigned
>  - commit-reach: use `size_t` to track indices when computing merge bases
>  - shallow: fix -Wsign-compare warnings
>  - builtin/log: fix remaining -Wsign-compare warnings
>  - builtin/log: use `size_t` to track indices
>  - commit-reach: use `size_t` to track indices in `get_reachable_subset()`
>  - commit-reach: use `size_t` to track indices in `remove_redundant()`
>  - commit-reach: fix type of `min_commit_date`
>  - commit-reach: fix index used to loop through unsigned integer
>  - prio-queue: fix type of `insertion_ctr`
> 
>  More -Wsign-compare fixes.
> 
>  Expecting a reroll?
>  cf. <Z2-2dbYVuuLxpNmK@pks.im>
>  cf. https://staticthinking.wordpress.com/2023/07/25/wsign-compare-is-garbage/
>  source: <20241227-b4-pks-commit-reach-sign-compare-v1-0-07c59c2aa632@pks.im>

There wasn't anything yet that needs addressing, unless I have missed
something. Peff acked a couple of patches, and the questions from Jialuo
have been addressed. So no rerolled is planney (yet).

> * sk/maintenance-remote-prune (2024-12-28) 1 commit
>  - maintenance: add prune-remote-refs task
> 
>  A new periodic maintenance task to run "git remote prune" has been
>  introduced.
> 
>  Will merge to 'next'?
>  source: <pull.1838.v2.git.1735380461980.gitgitgadget@gmail.com>

I've had another look at this series just now.

> --------------------------------------------------
> [Cooking]
> 
> * rs/reftable-realloc-errors (2024-12-28) 4 commits
>  - t-reftable-merged: handle realloc errors
>  - reftable: handle realloc error in parse_names()
>  - reftable: fix allocation count on realloc error
>  - reftable: avoid leaks on realloc error
> 
>  The custom allocator code in the reftable library did not handle
>  failing realloc() very well, which has been addressed.
> 
>  Will merge to 'next'?
>  source: <f4677194-0a3a-4f07-b003-c0295b51c100@web.de>

I'm not a 100% happy with the split for reallocators that this series
introduces, but don't think that the series is to blame because it
simply fixes the underlying problem. So this is a good first iteration
and we can improve the status quo in a follow-up.

So yes, I think this can be merged.

Patrick