jk/diff-files-cleanup-fix + related un-picked-up ab/* (was: What's cooking in git.git (Jul 2022, #05; Sun, 17))

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

On Sun, Jul 17 2022, Junio C Hamano wrote:

> * jk/diff-files-cleanup-fix (2022-07-12) 1 commit
>   (merged to 'next' on 2022-07-13 at 9db5235d01)
>  + diff-files: move misplaced cleanup label
>
>  An earlier attempt to plug leaks placed a clean-up label to jump to
>  at a bogus place, which as been corrected.
>
>  Will merge to 'master'.
>  source: <Ys0c0ePxPOqZ/5ck@coredump.intra.peff.net>

(As noted before) that fix looks good, thanks Jeff!

But here's a gentle *poke* about picking up [1], which is a related
follow-up series (but applies directly on master).

It fixes some other minor issues in my earlier release_revisions()
series, and then goes on to fix other common memory leaks that didn't
make it into that initial series.

These in particular & somewhat tricky or non-obvious, and could use
careful review:

    https://lore.kernel.org/git/patch-4.6-9bff7b10197-20220713T130511Z-avarab@gmail.com/
    https://lore.kernel.org/git/patch-6.6-4a581a4a6ce-20220713T130511Z-avarab@gmail.com/

The latter of those proposes to fix what's a common leak pattern in the
codebase in a particular way, I'd be interested to know what people
think of that approach.

There was a related earlier discussion between me and Glen at:

	https://lore.kernel.org/git/220713.86o7xs3g76.gmgdl@evledraar.gmail.com/

I.e. whether we should do an xstrdup() (or equivalent) in those cases,
so we wouldn't have to mix up free()-able data (strvec etc) with
un-free() able (main()'s "argv") in various APIs.

There are more drastic ways to address it, but I think that 6/6 is the
best trade-off in terms of a narrow fix & fixing that class of leak.

1. https://lore.kernel.org/git/cover-0.6-00000000000-20220713T130511Z-avarab@gmail.com/