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

From: Ævar Arnfjörð Bjarmason <[email-masked]>
Date: Mon, 18 Jul 2022 12:15:00 +0200

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/[email-masked]>

(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/[email-masked]/
    https://lore.kernel.org/git/[email-masked]/

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/[email-masked]/

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/[email-masked]/