ab/plug-leak-in-revisions (was: What's cooking in git.git (Apr 2022, #03; Tue, 12))

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Tue, Apr 12 2022, Junio C Hamano wrote:

> * ab/plug-leak-in-revisions (2022-04-03) 28 commits
>  - revisions API: add a TODO for diff_free(&revs->diffopt)
>  - revisions API: have release_revisions() release "topo_walk_info"
>  - revisions API: have release_revisions() release "date_mode"
>  - revisions API: call diff_free(&revs->pruning) in revisions_release()
>  - revisions API: release "reflog_info" in release revisions()
>  - revisions API: clear "boundary_commits" in release_revisions()
>  - revisions API: have release_revisions() release "prune_data"
>  - revisions API: have release_revisions() release "grep_filter"
>  - revisions API: have release_revisions() release "filter"
>  - revisions API: have release_revisions() release "cmdline"
>  - revisions API: have release_revisions() release "mailmap"
>  - revisions API: have release_revisions() release "commits"
>  - revisions API users: use release_revisions() for "prune_data" users
>  - revisions API users: use release_revisions() with UNLEAK()
>  - revisions API users: use release_revisions() in builtin/log.c
>  - revisions API users: use release_revisions() in http-push.c
>  - revisions API users: add "goto cleanup" for release_revisions()
>  - stash: always have the owner of "stash_info" free it
>  - revisions API users: use release_revisions() needing REV_INFO_INIT
>  - revision.[ch]: document and move code declared around "init"
>  - revisions API users: add straightforward release_revisions()
>  - revision.[ch]: provide and start using a release_revisions()
>  - cocci: add and apply free_commit_list() rules
>  - format-patch: don't leak "extra_headers" or "ref_message_ids"
>  - string_list API users: use string_list_init_{no,}dup
>  - blame: use "goto cleanup" for cleanup_scoreboard()
>  - t/helper/test-fast-rebase.c: don't leak "struct strbuf"
>  - Merge branch 'ds/partial-bundle-more' into ab/plug-leak-in-revisions
>
>  Plug the memory leaks from the trickiest API of all, the revision
>  walker.
>
>  Will merge to 'next'?
>  source: <cover-v5-00.27-00000000000-20220402T102002Z-avarab@gmail.com>

I think it should be ready with my just-submitted re-roll, which fixes a
trivial nit spotted by Phillip Wood by removing a useless NULL check:
https://lore.kernel.org/git/cover-v6-00.27-00000000000-20220413T195935Z-avarab@gmail.com/