[PATCH v3 0/3] unpack-trees: memory-leak fixes

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

This commit-message-only-change to v2 should address the comments
Elijah had on v2 (see link in the range-diff). I.e. there's probably
bug in adjacent code in leaving a stale lockfile, but I'm punting on
that and just narrowly fixing a memory leak here.

Ævar Arnfjörð Bjarmason (3):
  unpack-trees: don't leak memory in verify_clean_subdirectory()
  sequencer: add a "goto cleanup" to do_reset()
  sequencer: fix a memory leak in do_reset()

 sequencer.c                 | 36 +++++++++++++++---------------------
 t/t1001-read-tree-m-2way.sh |  2 ++
 unpack-trees.c              |  3 ++-
 3 files changed, 19 insertions(+), 22 deletions(-)

Range-diff against v2:
1:  e5ef1be2aa9 = 1:  0ab1e74f50d unpack-trees: don't leak memory in verify_clean_subdirectory()
2:  1d5f5e9fff0 ! 2:  393937e8a98 sequencer: add a "goto cleanup" to do_reset()
    @@ Commit message
         unconditionally free desc.buffer, it won't be initialized on the first
         couple of "goto"'s.
     
    -    There are three earlier "return"'s in this function that I'm not
    -    bothering to covert, those don't need to rollback anything, or free
    -    any resources, so let's leave, even though they could safely "goto
    -    cleanup" as well.
    +    There are three earlier "return"'s in this function which should
    +    probably be made to use this new "cleanup" too, per [1] it looks like
    +    they're leaving behind stale locks. But let's not try to fix every
    +    potential bug here now, I'm just trying to narrowly plug a memory
    +    leak.
    +
    +    1. https://lore.kernel.org/git/CABPp-BH=3DP-dXRCphY53-3eZd1TU8h5GY_M12nnbEGm-UYB9Q@mail.gmail.com/
     
         Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
     
3:  66ae63db8fd ! 3:  00b6b469a8c sequencer: fix a memory leak in do_reset()
    @@ Commit message
         setup_unpack_trees_porcelain() without a corresponding call to
         clear_unpack_trees_porcelain().
     
    +    This introduces a change in behavior in that we now start calling
    +    clear_unpack_trees_porcelain() even without having called the
    +    setup_unpack_trees_porcelain(). That's OK, that clear function, like
    +    most others, will accept a zero'd out struct.
    +
         This inches us closer to passing various tests in
         "t34*.sh" (e.g. "t3434-rebase-i18n.sh"), but because they have so many
         other memory leaks in revisions.c this doesn't make any test file or
-- 
2.33.0.1569.gd2dc77f7abf