Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Signed-off-by: Junio C Hamano <gitster@pobox.com>

* master:
  Post 2.3 cycle (batch #9)

Many of our test scripts have several "setup" tests.  It's a lot easier
to say

   ./t0050-filesystem.sh --run=setup,9

in order to run all the setup tests as well as test git#9, than it is to
track down what all the setup tests are and enter all their numbers in
the list.  Also, I often find myself wanting to run just one or a couple
tests from the test file, but I don't know the numbering of any of the
tests -- to get it I either have to first run the whole test file (or
start counting by hand or figure out some other clever but non-obvious
tricks).  It's really convenient to be able to just look at the test
description(s) and then run

   ./t6416-recursive-corner-cases.sh --run=symlink

or

   ./t6402-merge-rename.sh --run='setup,unnecessary update'

Add such an ability to test selection which relies on merely matching
against the test description.

Signed-off-by: Elijah Newren <newren@gmail.com>

Many of our test scripts have several "setup" tests.  It's a lot easier
to say

   ./t0050-filesystem.sh --run=setup,9

in order to run all the setup tests as well as test git#9, than it is to
track down what all the setup tests are and enter all their numbers in
the list.  Also, I often find myself wanting to run just one or a couple
tests from the test file, but I don't know the numbering of any of the
tests -- to get it I either have to first run the whole test file (or
start counting by hand or figure out some other clever but non-obvious
tricks).  It's really convenient to be able to just look at the test
description(s) and then run

   ./t6416-recursive-corner-cases.sh --run=symlink

or

   ./t6402-merge-rename.sh --run='setup,unnecessary update'

Add such an ability to test selection which relies on merely matching
against the test description.

Signed-off-by: Elijah Newren <newren@gmail.com>

Many of our test scripts have several "setup" tests.  It's a lot easier
to say

   ./t0050-filesystem.sh --run=setup,9

in order to run all the setup tests as well as test #9, than it is to
track down what all the setup tests are and enter all their numbers in
the list.  Also, I often find myself wanting to run just one or a couple
tests from the test file, but I don't know the numbering of any of the
tests -- to get it I either have to first run the whole test file (or
start counting by hand or figure out some other clever but non-obvious
tricks).  It's really convenient to be able to just look at the test
description(s) and then run

   ./t6416-recursive-corner-cases.sh --run=symlink

or

   ./t6402-merge-rename.sh --run='setup,unnecessary update'

Add such an ability to test selection which relies on merely matching
against the test description.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Many of our test scripts have several "setup" tests.  It's a lot easier
to say

   ./t0050-filesystem.sh --run=setup,9

in order to run all the setup tests as well as test git#9, than it is to
track down what all the setup tests are and enter all their numbers in
the list.  Also, I often find myself wanting to run just one or a couple
tests from the test file, but I don't know the numbering of any of the
tests -- to get it I either have to first run the whole test file (or
start counting by hand or figure out some other clever but non-obvious
tricks).  It's really convenient to be able to just look at the test
description(s) and then run

   ./t6416-recursive-corner-cases.sh --run=symlink

or

   ./t6402-merge-rename.sh --run='setup,unnecessary update'

Add such an ability to test selection which relies on merely matching
against the test description.

Signed-off-by: Elijah Newren <newren@gmail.com>

Many of our test scripts have several "setup" tests.  It's a lot easier
to say

   ./t0050-filesystem.sh --run=setup,9

in order to run all the setup tests as well as test git#9, than it is to
track down what all the setup tests are and enter all their numbers in
the list.  Also, I often find myself wanting to run just one or a couple
tests from the test file, but I don't know the numbering of any of the
tests -- to get it I either have to first run the whole test file (or
start counting by hand or figure out some other clever but non-obvious
tricks).  It's really convenient to be able to just look at the test
description(s) and then run

   ./t6416-recursive-corner-cases.sh --run=symlink

or

   ./t6402-merge-rename.sh --run='setup,unnecessary update'

Add such an ability to test selection which relies on merely matching
against the test description.

Signed-off-by: Elijah Newren <newren@gmail.com>

Many of our test scripts have several "setup" tests.  It's a lot easier
to say

   ./t0050-filesystem.sh --run=setup,9

in order to run all the setup tests as well as test git#9, than it is to
track down what all the setup tests are and enter all their numbers in
the list.  Also, I often find myself wanting to run just one or a couple
tests from the test file, but I don't know the numbering of any of the
tests -- to get it I either have to first run the whole test file (or
start counting by hand or figure out some other clever but non-obvious
tricks).  It's really convenient to be able to just look at the test
description(s) and then run

   ./t6416-recursive-corner-cases.sh --run=symlink

or

   ./t6402-merge-rename.sh --run='setup,unnecessary update'

Add such an ability to test selection which relies on merely matching
against the test description.

Signed-off-by: Elijah Newren <newren@gmail.com>

Many of our test scripts have several "setup" tests.  It's a lot easier
to say

   ./t0050-filesystem.sh --run=setup,9

in order to run all the setup tests as well as test git#9, than it is to
track down what all the setup tests are and enter all their numbers in
the list.  Also, I often find myself wanting to run just one or a couple
tests from the test file, but I don't know the numbering of any of the
tests -- to get it I either have to first run the whole test file (or
start counting by hand or figure out some other clever but non-obvious
tricks).  It's really convenient to be able to just look at the test
description(s) and then run

   ./t6416-recursive-corner-cases.sh --run=symlink

or

   ./t6402-merge-rename.sh --run='setup,unnecessary update'

Add such an ability to test selection which relies on merely matching
against the test description.

Signed-off-by: Elijah Newren <newren@gmail.com>

Many of our test scripts have several "setup" tests.  It's a lot easier
to say

   ./t0050-filesystem.sh --run=setup,9

in order to run all the setup tests as well as test git#9, than it is to
track down what all the setup tests are and enter all their numbers in
the list.  Also, I often find myself wanting to run just one or a couple
tests from the test file, but I don't know the numbering of any of the
tests -- to get it I either have to first run the whole test file (or
start counting by hand or figure out some other clever but non-obvious
tricks).  It's really convenient to be able to just look at the test
description(s) and then run

   ./t6416-recursive-corner-cases.sh --run=symlink

or

   ./t6402-merge-rename.sh --run='setup,unnecessary update'

Add such an ability to test selection which relies on merely matching
against the test description.

Signed-off-by: Elijah Newren <newren@gmail.com>

Many of our test scripts have several "setup" tests.  It's a lot easier
to say

   ./t0050-filesystem.sh --run=setup,9

in order to run all the setup tests as well as test #9, than it is to
track down what all the setup tests are and enter all their numbers in
the list.  Also, I often find myself wanting to run just one or a couple
tests from the test file, but I don't know the numbering of any of the
tests -- to get it I either have to first run the whole test file (or
start counting by hand or figure out some other clever but non-obvious
tricks).  It's really convenient to be able to just look at the test
description(s) and then run

   ./t6416-recursive-corner-cases.sh --run=symlink

or

   ./t6402-merge-rename.sh --run='setup,unnecessary update'

Add such an ability to test selection which relies on merely matching
against the test description.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Many of our test scripts have several "setup" tests.  It's a lot easier
to say

   ./t0050-filesystem.sh --run=setup,9

in order to run all the setup tests as well as test #9, than it is to
track down what all the setup tests are and enter all their numbers in
the list.  Also, I often find myself wanting to run just one or a couple
tests from the test file, but I don't know the numbering of any of the
tests -- to get it I either have to first run the whole test file (or
start counting by hand or figure out some other clever but non-obvious
tricks).  It's really convenient to be able to just look at the test
description(s) and then run

   ./t6416-recursive-corner-cases.sh --run=symlink

or

   ./t6402-merge-rename.sh --run='setup,unnecessary update'

Add such an ability to test selection which relies on merely matching
against the test description.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Many of our test scripts have several "setup" tests.  It's a lot easier
to say

   ./t0050-filesystem.sh --run=setup,9

in order to run all the setup tests as well as test git#9, than it is to
track down what all the setup tests are and enter all their numbers in
the list.  Also, I often find myself wanting to run just one or a couple
tests from the test file, but I don't know the numbering of any of the
tests -- to get it I either have to first run the whole test file (or
start counting by hand or figure out some other clever but non-obvious
tricks).  It's really convenient to be able to just look at the test
description(s) and then run

   ./t6416-recursive-corner-cases.sh --run=symlink

or

   ./t6402-merge-rename.sh --run='setup,unnecessary update'

Add such an ability to test selection which relies on merely matching
against the test description.

Signed-off-by: Elijah Newren <newren@gmail.com>

Many of our test scripts have several "setup" tests.  It's a lot easier
to say

   ./t0050-filesystem.sh --run=setup,9

in order to run all the setup tests as well as test #9, than it is to
track down what all the setup tests are and enter all their numbers in
the list.  Also, I often find myself wanting to run just one or a couple
tests from the test file, but I don't know the numbering of any of the
tests -- to get it I either have to first run the whole test file (or
start counting by hand or figure out some other clever but non-obvious
tricks).  It's really convenient to be able to just look at the test
description(s) and then run

   ./t6416-recursive-corner-cases.sh --run=symlink

or

   ./t6402-merge-rename.sh --run='setup,unnecessary update'

Add such an ability to test selection which relies on merely matching
against the test description.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

write_commit_graph initialises topo_levels using init_topo_level_slab(),
next it calls compute_topological_levels() which can cause the slab to
grow, we therefore need to clear the slab again using
clear_topo_level_slab() when we're done.

First introduced in 72a2bfc - which
is currently only in master and not on maint.

LeakSanitizer output:

==1026==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 8 byte(s) in 1 object(s) allocated from:
    #0 0x498ae9 in realloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3
    #1 0xafbed8 in xrealloc /src/git/wrapper.c:126:8
    #2 0x7966d1 in topo_level_slab_at_peek /src/git/commit-graph.c:71:1
    #3 0x7965e0 in topo_level_slab_at /src/git/commit-graph.c:71:1
    #4 0x78fbf5 in compute_topological_levels /src/git/commit-graph.c:1472:12
    #5 0x78c5c3 in write_commit_graph /src/git/commit-graph.c:2456:2
    #6 0x535c5f in graph_write /src/git/builtin/commit-graph.c:299:6
    #7 0x5350ca in cmd_commit_graph /src/git/builtin/commit-graph.c:337:11
    git#8 0x4cddb1 in run_builtin /src/git/git.c:453:11
    git#9 0x4cabe2 in handle_builtin /src/git/git.c:704:3
    git#10 0x4cd084 in run_argv /src/git/git.c:771:4
    git#11 0x4ca424 in cmd_main /src/git/git.c:902:19
    git#12 0x707fb6 in main /src/git/common-main.c:52:11
    git#13 0x7fee4249383f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f)

Indirect leak of 524256 byte(s) in 1 object(s) allocated from:
    #0 0x498942 in calloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:154:3
    #1 0xafc088 in xcalloc /src/git/wrapper.c:140:8
    #2 0x796870 in topo_level_slab_at_peek /src/git/commit-graph.c:71:1
    #3 0x7965e0 in topo_level_slab_at /src/git/commit-graph.c:71:1
    #4 0x78fbf5 in compute_topological_levels /src/git/commit-graph.c:1472:12
    #5 0x78c5c3 in write_commit_graph /src/git/commit-graph.c:2456:2
    #6 0x535c5f in graph_write /src/git/builtin/commit-graph.c:299:6
    #7 0x5350ca in cmd_commit_graph /src/git/builtin/commit-graph.c:337:11
    git#8 0x4cddb1 in run_builtin /src/git/git.c:453:11
    git#9 0x4cabe2 in handle_builtin /src/git/git.c:704:3
    git#10 0x4cd084 in run_argv /src/git/git.c:771:4
    git#11 0x4ca424 in cmd_main /src/git/git.c:902:19
    git#12 0x707fb6 in main /src/git/common-main.c:52:11
    git#13 0x7fee4249383f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f)

SUMMARY: AddressSanitizer: 524264 byte(s) leaked in 2 allocation(s).

write_commit_graph initialises topo_levels using init_topo_level_slab(),
next it calls compute_topological_levels() which can cause the slab to
grow, we therefore need to clear the slab again using
clear_topo_level_slab() when we're done.

First introduced in 72a2bfc - which
is currently only in master and not on maint.

LeakSanitizer output:

==1026==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 8 byte(s) in 1 object(s) allocated from:
    #0 0x498ae9 in realloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3
    #1 0xafbed8 in xrealloc /src/git/wrapper.c:126:8
    #2 0x7966d1 in topo_level_slab_at_peek /src/git/commit-graph.c:71:1
    #3 0x7965e0 in topo_level_slab_at /src/git/commit-graph.c:71:1
    #4 0x78fbf5 in compute_topological_levels /src/git/commit-graph.c:1472:12
    #5 0x78c5c3 in write_commit_graph /src/git/commit-graph.c:2456:2
    #6 0x535c5f in graph_write /src/git/builtin/commit-graph.c:299:6
    #7 0x5350ca in cmd_commit_graph /src/git/builtin/commit-graph.c:337:11
    git#8 0x4cddb1 in run_builtin /src/git/git.c:453:11
    git#9 0x4cabe2 in handle_builtin /src/git/git.c:704:3
    git#10 0x4cd084 in run_argv /src/git/git.c:771:4
    git#11 0x4ca424 in cmd_main /src/git/git.c:902:19
    git#12 0x707fb6 in main /src/git/common-main.c:52:11
    git#13 0x7fee4249383f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f)

Indirect leak of 524256 byte(s) in 1 object(s) allocated from:
    #0 0x498942 in calloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:154:3
    #1 0xafc088 in xcalloc /src/git/wrapper.c:140:8
    #2 0x796870 in topo_level_slab_at_peek /src/git/commit-graph.c:71:1
    #3 0x7965e0 in topo_level_slab_at /src/git/commit-graph.c:71:1
    #4 0x78fbf5 in compute_topological_levels /src/git/commit-graph.c:1472:12
    #5 0x78c5c3 in write_commit_graph /src/git/commit-graph.c:2456:2
    #6 0x535c5f in graph_write /src/git/builtin/commit-graph.c:299:6
    #7 0x5350ca in cmd_commit_graph /src/git/builtin/commit-graph.c:337:11
    git#8 0x4cddb1 in run_builtin /src/git/git.c:453:11
    git#9 0x4cabe2 in handle_builtin /src/git/git.c:704:3
    git#10 0x4cd084 in run_argv /src/git/git.c:771:4
    git#11 0x4ca424 in cmd_main /src/git/git.c:902:19
    git#12 0x707fb6 in main /src/git/common-main.c:52:11
    git#13 0x7fee4249383f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f)

SUMMARY: AddressSanitizer: 524264 byte(s) leaked in 2 allocation(s).
Signed-off-by: Andrzej Hunt <ajrhunt@google.com>

write_commit_graph initialises topo_levels using init_topo_level_slab(),
next it calls compute_topological_levels() which can cause the slab to
grow, we therefore need to clear the slab again using
clear_topo_level_slab() when we're done.

First introduced in 72a2bfc - which
is currently only in master and not on maint.

LeakSanitizer output:

==1026==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 8 byte(s) in 1 object(s) allocated from:
    #0 0x498ae9 in realloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3
    #1 0xafbed8 in xrealloc /src/git/wrapper.c:126:8
    #2 0x7966d1 in topo_level_slab_at_peek /src/git/commit-graph.c:71:1
    #3 0x7965e0 in topo_level_slab_at /src/git/commit-graph.c:71:1
    #4 0x78fbf5 in compute_topological_levels /src/git/commit-graph.c:1472:12
    #5 0x78c5c3 in write_commit_graph /src/git/commit-graph.c:2456:2
    #6 0x535c5f in graph_write /src/git/builtin/commit-graph.c:299:6
    #7 0x5350ca in cmd_commit_graph /src/git/builtin/commit-graph.c:337:11
    git#8 0x4cddb1 in run_builtin /src/git/git.c:453:11
    git#9 0x4cabe2 in handle_builtin /src/git/git.c:704:3
    git#10 0x4cd084 in run_argv /src/git/git.c:771:4
    git#11 0x4ca424 in cmd_main /src/git/git.c:902:19
    git#12 0x707fb6 in main /src/git/common-main.c:52:11
    git#13 0x7fee4249383f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f)

Indirect leak of 524256 byte(s) in 1 object(s) allocated from:
    #0 0x498942 in calloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:154:3
    #1 0xafc088 in xcalloc /src/git/wrapper.c:140:8
    #2 0x796870 in topo_level_slab_at_peek /src/git/commit-graph.c:71:1
    #3 0x7965e0 in topo_level_slab_at /src/git/commit-graph.c:71:1
    #4 0x78fbf5 in compute_topological_levels /src/git/commit-graph.c:1472:12
    #5 0x78c5c3 in write_commit_graph /src/git/commit-graph.c:2456:2
    #6 0x535c5f in graph_write /src/git/builtin/commit-graph.c:299:6
    #7 0x5350ca in cmd_commit_graph /src/git/builtin/commit-graph.c:337:11
    git#8 0x4cddb1 in run_builtin /src/git/git.c:453:11
    git#9 0x4cabe2 in handle_builtin /src/git/git.c:704:3
    git#10 0x4cd084 in run_argv /src/git/git.c:771:4
    git#11 0x4ca424 in cmd_main /src/git/git.c:902:19
    git#12 0x707fb6 in main /src/git/common-main.c:52:11
    git#13 0x7fee4249383f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f)

SUMMARY: AddressSanitizer: 524264 byte(s) leaked in 2 allocation(s).

Signed-off-by: Andrzej Hunt <ajrhunt@google.com>

write_commit_graph initialises topo_levels using init_topo_level_slab(),
next it calls compute_topological_levels() which can cause the slab to
grow, we therefore need to clear the slab again using
clear_topo_level_slab() when we're done.

First introduced in 72a2bfc (commit-graph: add a slab to store
topological levels, 2021-01-16).

LeakSanitizer output:

==1026==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 8 byte(s) in 1 object(s) allocated from:
    #0 0x498ae9 in realloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3
    #1 0xafbed8 in xrealloc /src/git/wrapper.c:126:8
    #2 0x7966d1 in topo_level_slab_at_peek /src/git/commit-graph.c:71:1
    #3 0x7965e0 in topo_level_slab_at /src/git/commit-graph.c:71:1
    #4 0x78fbf5 in compute_topological_levels /src/git/commit-graph.c:1472:12
    #5 0x78c5c3 in write_commit_graph /src/git/commit-graph.c:2456:2
    #6 0x535c5f in graph_write /src/git/builtin/commit-graph.c:299:6
    #7 0x5350ca in cmd_commit_graph /src/git/builtin/commit-graph.c:337:11
    #8 0x4cddb1 in run_builtin /src/git/git.c:453:11
    #9 0x4cabe2 in handle_builtin /src/git/git.c:704:3
    #10 0x4cd084 in run_argv /src/git/git.c:771:4
    #11 0x4ca424 in cmd_main /src/git/git.c:902:19
    #12 0x707fb6 in main /src/git/common-main.c:52:11
    #13 0x7fee4249383f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f)

Indirect leak of 524256 byte(s) in 1 object(s) allocated from:
    #0 0x498942 in calloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:154:3
    #1 0xafc088 in xcalloc /src/git/wrapper.c:140:8
    #2 0x796870 in topo_level_slab_at_peek /src/git/commit-graph.c:71:1
    #3 0x7965e0 in topo_level_slab_at /src/git/commit-graph.c:71:1
    #4 0x78fbf5 in compute_topological_levels /src/git/commit-graph.c:1472:12
    #5 0x78c5c3 in write_commit_graph /src/git/commit-graph.c:2456:2
    #6 0x535c5f in graph_write /src/git/builtin/commit-graph.c:299:6
    #7 0x5350ca in cmd_commit_graph /src/git/builtin/commit-graph.c:337:11
    #8 0x4cddb1 in run_builtin /src/git/git.c:453:11
    #9 0x4cabe2 in handle_builtin /src/git/git.c:704:3
    #10 0x4cd084 in run_argv /src/git/git.c:771:4
    #11 0x4ca424 in cmd_main /src/git/git.c:902:19
    #12 0x707fb6 in main /src/git/common-main.c:52:11
    #13 0x7fee4249383f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f)

SUMMARY: AddressSanitizer: 524264 byte(s) leaked in 2 allocation(s).

Signed-off-by: Andrzej Hunt <ajrhunt@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Both invocations of transport_helper_init take ownership of name, see:
- Path 1:
  helper = xstrndup(...)
    https://git.kernel.org/pub/scm/git/git.git/tree/transport.c#n1049
  followed by transport_helper_init taking ownership:
    https://git.kernel.org/pub/scm/git/git.git/tree/transport.c#n1053
- Path 2:
  handler = xmemdupz(...), immediately followed by transpot_helper_init
  taking ownership:
    https://git.kernel.org/pub/scm/git/git.git/tree/transport.c#n1083

Therefore it seems clear that all functions clearing helper_data
should also be responsible for clearing the name. (We also add
a comment to transport_helper_init to make the ownership explicit.)

This avoids leaks such as the following, which I used to see on
every git pull - it's minor, but noisy. In most cases there appears
to be only one transport (so we'd leak at most once). The biggest
exception is builtin/push.c which can create multiple transports
in a loop, but even there the impact is unlikely to be noticeable.

Direct leak of 6 byte(s) in 1 object(s) allocated from:
    #0 0x49a53d in malloc /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
    #1 0x9a6fe4 in do_xmalloc /home/ahunt/oss-fuzz/git/wrapper.c:41:8
    #2 0x9a7078 in do_xmallocz /home/ahunt/oss-fuzz/git/wrapper.c:75:8
    #3 0x9a705a in xmallocz /home/ahunt/oss-fuzz/git/wrapper.c:83:9
    #4 0x9a7107 in xmemdupz /home/ahunt/oss-fuzz/git/wrapper.c:99:16
    #5 0x975338 in transport_get /home/ahunt/oss-fuzz/git/transport.c:1083:19
    #6 0x5636c0 in prepare_transport /home/ahunt/oss-fuzz/git/builtin/fetch.c:1388:14
    #7 0x56294d in fetch_one /home/ahunt/oss-fuzz/git/builtin/fetch.c:1837:15
    git#8 0x561e2c in cmd_fetch /home/ahunt/oss-fuzz/git/builtin/fetch.c:1993:12
    git#9 0x4cd60d in run_builtin /home/ahunt/oss-fuzz/git/git.c:453:11
    git#10 0x4cb2da in handle_builtin /home/ahunt/oss-fuzz/git/git.c:704:3
    git#11 0x4ccc37 in run_argv /home/ahunt/oss-fuzz/git/git.c:771:4
    git#12 0x4cac29 in cmd_main /home/ahunt/oss-fuzz/git/git.c:902:19
    git#13 0x69c43e in main /home/ahunt/oss-fuzz/git/common-main.c:52:11
    git#14 0x7fec22a90349 in __libc_start_main (/lib64/libc.so.6+0x24349)

SUMMARY: AddressSanitizer: 6 byte(s) leaked in 1 allocation(s).

Both invocations of transport_helper_init take ownership of name, see:
- Path 1:
  helper = xstrndup(...)
    https://git.kernel.org/pub/scm/git/git.git/tree/transport.c#n1049
  followed by transport_helper_init taking ownership:
    https://git.kernel.org/pub/scm/git/git.git/tree/transport.c#n1053
- Path 2:
  handler = xmemdupz(...), immediately followed by transpot_helper_init
  taking ownership:
    https://git.kernel.org/pub/scm/git/git.git/tree/transport.c#n1083

Therefore it seems clear that all functions clearing helper_data
should also be responsible for clearing the name. (We also add
a comment to transport_helper_init to make the ownership explicit.)

This avoids leaks such as the following, which I used to see on
every git pull - it's minor, but noisy. In most cases there appears
to be only one transport (so we'd leak at most once). The biggest
exception is builtin/push.c which can create multiple transports
in a loop, but even there the impact is unlikely to be noticeable.

Direct leak of 6 byte(s) in 1 object(s) allocated from:
    #0 0x49a53d in malloc /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
    #1 0x9a6fe4 in do_xmalloc /home/ahunt/oss-fuzz/git/wrapper.c:41:8
    #2 0x9a7078 in do_xmallocz /home/ahunt/oss-fuzz/git/wrapper.c:75:8
    #3 0x9a705a in xmallocz /home/ahunt/oss-fuzz/git/wrapper.c:83:9
    #4 0x9a7107 in xmemdupz /home/ahunt/oss-fuzz/git/wrapper.c:99:16
    #5 0x975338 in transport_get /home/ahunt/oss-fuzz/git/transport.c:1083:19
    #6 0x5636c0 in prepare_transport /home/ahunt/oss-fuzz/git/builtin/fetch.c:1388:14
    #7 0x56294d in fetch_one /home/ahunt/oss-fuzz/git/builtin/fetch.c:1837:15
    git#8 0x561e2c in cmd_fetch /home/ahunt/oss-fuzz/git/builtin/fetch.c:1993:12
    git#9 0x4cd60d in run_builtin /home/ahunt/oss-fuzz/git/git.c:453:11
    git#10 0x4cb2da in handle_builtin /home/ahunt/oss-fuzz/git/git.c:704:3
    git#11 0x4ccc37 in run_argv /home/ahunt/oss-fuzz/git/git.c:771:4
    git#12 0x4cac29 in cmd_main /home/ahunt/oss-fuzz/git/git.c:902:19
    git#13 0x69c43e in main /home/ahunt/oss-fuzz/git/common-main.c:52:11
    git#14 0x7fec22a90349 in __libc_start_main (/lib64/libc.so.6+0x24349)

SUMMARY: AddressSanitizer: 6 byte(s) leaked in 1 allocation(s).
Signed-off-by: Andrzej Hunt <ajrhunt@google.com>

Both invocations of transport_helper_init take ownership of name, see:
- Path 1:
  helper = xstrndup(...)
    https://git.kernel.org/pub/scm/git/git.git/tree/transport.c#n1049
  followed by transport_helper_init taking ownership:
    https://git.kernel.org/pub/scm/git/git.git/tree/transport.c#n1053
- Path 2:
  handler = xmemdupz(...), immediately followed by transpot_helper_init
  taking ownership:
    https://git.kernel.org/pub/scm/git/git.git/tree/transport.c#n1083

Therefore it seems clear that all functions clearing helper_data
should also be responsible for clearing the name. (We also add
a comment to transport_helper_init to make the ownership explicit.)

This avoids leaks such as the following, which I used to see on
every git pull - it's minor, but noisy. In most cases there appears
to be only one transport (so we'd leak at most once). The biggest
exception is builtin/push.c which can create multiple transports
in a loop, but even there the impact is unlikely to be noticeable.

Direct leak of 6 byte(s) in 1 object(s) allocated from:
    #0 0x49a53d in malloc /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
    #1 0x9a6fe4 in do_xmalloc /home/ahunt/oss-fuzz/git/wrapper.c:41:8
    #2 0x9a7078 in do_xmallocz /home/ahunt/oss-fuzz/git/wrapper.c:75:8
    #3 0x9a705a in xmallocz /home/ahunt/oss-fuzz/git/wrapper.c:83:9
    #4 0x9a7107 in xmemdupz /home/ahunt/oss-fuzz/git/wrapper.c:99:16
    #5 0x975338 in transport_get /home/ahunt/oss-fuzz/git/transport.c:1083:19
    #6 0x5636c0 in prepare_transport /home/ahunt/oss-fuzz/git/builtin/fetch.c:1388:14
    #7 0x56294d in fetch_one /home/ahunt/oss-fuzz/git/builtin/fetch.c:1837:15
    git#8 0x561e2c in cmd_fetch /home/ahunt/oss-fuzz/git/builtin/fetch.c:1993:12
    git#9 0x4cd60d in run_builtin /home/ahunt/oss-fuzz/git/git.c:453:11
    git#10 0x4cb2da in handle_builtin /home/ahunt/oss-fuzz/git/git.c:704:3
    git#11 0x4ccc37 in run_argv /home/ahunt/oss-fuzz/git/git.c:771:4
    git#12 0x4cac29 in cmd_main /home/ahunt/oss-fuzz/git/git.c:902:19
    git#13 0x69c43e in main /home/ahunt/oss-fuzz/git/common-main.c:52:11
    git#14 0x7fec22a90349 in __libc_start_main (/lib64/libc.so.6+0x24349)

SUMMARY: AddressSanitizer: 6 byte(s) leaked in 1 allocation(s).

Signed-off-by: Andrzej Hunt <ajrhunt@google.com>

Fixes the following leak encountered when running t0001:

Direct leak of 19 byte(s) in 1 object(s) allocated from:
    #0 0x486514 in strdup /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/asan_interceptors.cpp:452:3
    #1 0x9ab048 in xstrdup /home/ahunt/oss-fuzz/git/wrapper.c:29:14
    #2 0x8b452f in refs_shorten_unambiguous_ref /home/ahunt/oss-fuzz/git/refs.c
    #3 0x8b47e8 in shorten_unambiguous_ref /home/ahunt/oss-fuzz/git/refs.c:1287:9
    #4 0x679fce in check_symref /home/ahunt/oss-fuzz/git/builtin/symbolic-ref.c:28:14
    #5 0x679ad8 in cmd_symbolic_ref /home/ahunt/oss-fuzz/git/builtin/symbolic-ref.c:70:9
    #6 0x4cd60d in run_builtin /home/ahunt/oss-fuzz/git/git.c:453:11
    #7 0x4cb2da in handle_builtin /home/ahunt/oss-fuzz/git/git.c:704:3
    git#8 0x4ccc37 in run_argv /home/ahunt/oss-fuzz/git/git.c:771:4
    git#9 0x4cac29 in cmd_main /home/ahunt/oss-fuzz/git/git.c:902:19
    git#10 0x69cc6e in main /home/ahunt/oss-fuzz/git/common-main.c:52:11
    git#11 0x7f98388a4349 in __libc_start_main (/lib64/libc.so.6+0x24349)

dwim_ref() allocs a new string into ref. If we want to discard ref we should also
free it.

This leak appears to have been introduced in:
4cf76f6 (builtin/reset: compute checkout metadata for reset, 2020-03-16)

Leak found while running t0001:

Direct leak of 5 byte(s) in 1 object(s) allocated from:
    #0 0x486514 in strdup /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/asan_interceptors.cpp:452:3
    #1 0x9a7108 in xstrdup /home/ahunt/oss-fuzz/git/wrapper.c:29:14
    #2 0x8add6b in expand_ref /home/ahunt/oss-fuzz/git/refs.c:670:12
    #3 0x8ad777 in repo_dwim_ref /home/ahunt/oss-fuzz/git/refs.c:644:22
    #4 0x6394af in dwim_ref /home/ahunt/oss-fuzz/git/./refs.h:162:9
    #5 0x637e5c in cmd_reset /home/ahunt/oss-fuzz/git/builtin/reset.c:426:4
    #6 0x4cd60d in run_builtin /home/ahunt/oss-fuzz/git/git.c:453:11
    #7 0x4cb2da in handle_builtin /home/ahunt/oss-fuzz/git/git.c:704:3
    git#8 0x4ccc37 in run_argv /home/ahunt/oss-fuzz/git/git.c:771:4
    git#9 0x4cac29 in cmd_main /home/ahunt/oss-fuzz/git/git.c:902:19
    git#10 0x69c5ce in main /home/ahunt/oss-fuzz/git/common-main.c:52:11
    git#11 0x7f57ebb9d349 in __libc_start_main (/lib64/libc.so.6+0x24349)

This squashes numerous direct and indirect leaks encountered while running t0001
with LSAN. A selection of LSAN outputs are included below (the full list is
omitted because it's just too long and uninteresting).

We also add one free in the middle of cmd_clone(): path will be overwritten later,
hence we should free it after the first use to avoid a leak.

Direct leak of 178 byte(s) in 1 object(s) allocated from:
    #0 0x49a53d in malloc /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
    #1 0x9a6ff4 in do_xmalloc /home/ahunt/oss-fuzz/git/wrapper.c:41:8
    #2 0x9a6fca in xmalloc /home/ahunt/oss-fuzz/git/wrapper.c:62:9
    #3 0x8ce296 in copy_ref /home/ahunt/oss-fuzz/git/remote.c:885:8
    #4 0x8d2ebd in guess_remote_head /home/ahunt/oss-fuzz/git/remote.c:2215:10
    #5 0x51d0c5 in cmd_clone /home/ahunt/oss-fuzz/git/builtin/clone.c:1308:4
    #6 0x4cd60d in run_builtin /home/ahunt/oss-fuzz/git/git.c:453:11
    #7 0x4cb2da in handle_builtin /home/ahunt/oss-fuzz/git/git.c:704:3
    git#8 0x4ccc37 in run_argv /home/ahunt/oss-fuzz/git/git.c:771:4
    git#9 0x4cac29 in cmd_main /home/ahunt/oss-fuzz/git/git.c:902:19
    git#10 0x69c45e in main /home/ahunt/oss-fuzz/git/common-main.c:52:11
    git#11 0x7f6a459d5349 in __libc_start_main (/lib64/libc.so.6+0x24349)

Direct leak of 165 byte(s) in 1 object(s) allocated from:
    #0 0x49a53d in malloc /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
    #1 0x9a6fc4 in do_xmalloc /home/ahunt/oss-fuzz/git/wrapper.c:41:8
    #2 0x9a6f9a in xmalloc /home/ahunt/oss-fuzz/git/wrapper.c:62:9
    #3 0x8ce266 in copy_ref /home/ahunt/oss-fuzz/git/remote.c:885:8
    #4 0x51e9bd in wanted_peer_refs /home/ahunt/oss-fuzz/git/builtin/clone.c:574:21
    #5 0x51cfe1 in cmd_clone /home/ahunt/oss-fuzz/git/builtin/clone.c:1284:17
    #6 0x4cd60d in run_builtin /home/ahunt/oss-fuzz/git/git.c:453:11
    #7 0x4cb2da in handle_builtin /home/ahunt/oss-fuzz/git/git.c:704:3
    git#8 0x4ccc37 in run_argv /home/ahunt/oss-fuzz/git/git.c:771:4
    git#9 0x4cac29 in cmd_main /home/ahunt/oss-fuzz/git/git.c:902:19
    git#10 0x69c42e in main /home/ahunt/oss-fuzz/git/common-main.c:52:11
    git#11 0x7f8fef0c2349 in __libc_start_main (/lib64/libc.so.6+0x24349)

Direct leak of 165 byte(s) in 1 object(s) allocated from:
    #0 0x49a6b2 in calloc /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:154:3
    #1 0x9a72f2 in xcalloc /home/ahunt/oss-fuzz/git/wrapper.c:140:8
    #2 0x8ce203 in alloc_ref_with_prefix /home/ahunt/oss-fuzz/git/remote.c:867:20
    #3 0x8ce1a2 in alloc_ref /home/ahunt/oss-fuzz/git/remote.c:875:9
    #4 0x72f63e in process_ref_v2 /home/ahunt/oss-fuzz/git/connect.c:426:8
    #5 0x72f21a in get_remote_refs /home/ahunt/oss-fuzz/git/connect.c:525:8
    #6 0x979ab7 in handshake /home/ahunt/oss-fuzz/git/transport.c:305:4
    #7 0x97872d in get_refs_via_connect /home/ahunt/oss-fuzz/git/transport.c:339:9
    git#8 0x9774b5 in transport_get_remote_refs /home/ahunt/oss-fuzz/git/transport.c:1388:4
    git#9 0x51cf80 in cmd_clone /home/ahunt/oss-fuzz/git/builtin/clone.c:1271:9
    git#10 0x4cd60d in run_builtin /home/ahunt/oss-fuzz/git/git.c:453:11
    git#11 0x4cb2da in handle_builtin /home/ahunt/oss-fuzz/git/git.c:704:3
    git#12 0x4ccc37 in run_argv /home/ahunt/oss-fuzz/git/git.c:771:4
    git#13 0x4cac29 in cmd_main /home/ahunt/oss-fuzz/git/git.c:902:19
    git#14 0x69c45e in main /home/ahunt/oss-fuzz/git/common-main.c:52:11
    git#15 0x7f6a459d5349 in __libc_start_main (/lib64/libc.so.6+0x24349)

Direct leak of 178 byte(s) in 1 object(s) allocated from:
    #0 0x49a53d in malloc /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
    #1 0x9a6ff4 in do_xmalloc /home/ahunt/oss-fuzz/git/wrapper.c:41:8
    #2 0x9a6fca in xmalloc /home/ahunt/oss-fuzz/git/wrapper.c:62:9
    #3 0x8ce296 in copy_ref /home/ahunt/oss-fuzz/git/remote.c:885:8
    #4 0x8d2ebd in guess_remote_head /home/ahunt/oss-fuzz/git/remote.c:2215:10
    #5 0x51d0c5 in cmd_clone /home/ahunt/oss-fuzz/git/builtin/clone.c:1308:4
    #6 0x4cd60d in run_builtin /home/ahunt/oss-fuzz/git/git.c:453:11
    #7 0x4cb2da in handle_builtin /home/ahunt/oss-fuzz/git/git.c:704:3
    git#8 0x4ccc37 in run_argv /home/ahunt/oss-fuzz/git/git.c:771:4
    git#9 0x4cac29 in cmd_main /home/ahunt/oss-fuzz/git/git.c:902:19
    git#10 0x69c45e in main /home/ahunt/oss-fuzz/git/common-main.c:52:11
    git#11 0x7f6a459d5349 in __libc_start_main (/lib64/libc.so.6+0x24349)

Direct leak of 165 byte(s) in 1 object(s) allocated from:
    #0 0x49a6b2 in calloc /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:154:3
    #1 0x9a72f2 in xcalloc /home/ahunt/oss-fuzz/git/wrapper.c:140:8
    #2 0x8ce203 in alloc_ref_with_prefix /home/ahunt/oss-fuzz/git/remote.c:867:20
    #3 0x8ce1a2 in alloc_ref /home/ahunt/oss-fuzz/git/remote.c:875:9
    #4 0x72f63e in process_ref_v2 /home/ahunt/oss-fuzz/git/connect.c:426:8
    #5 0x72f21a in get_remote_refs /home/ahunt/oss-fuzz/git/connect.c:525:8
    #6 0x979ab7 in handshake /home/ahunt/oss-fuzz/git/transport.c:305:4
    #7 0x97872d in get_refs_via_connect /home/ahunt/oss-fuzz/git/transport.c:339:9
    git#8 0x9774b5 in transport_get_remote_refs /home/ahunt/oss-fuzz/git/transport.c:1388:4
    git#9 0x51cf80 in cmd_clone /home/ahunt/oss-fuzz/git/builtin/clone.c:1271:9
    git#10 0x4cd60d in run_builtin /home/ahunt/oss-fuzz/git/git.c:453:11
    git#11 0x4cb2da in handle_builtin /home/ahunt/oss-fuzz/git/git.c:704:3
    git#12 0x4ccc37 in run_argv /home/ahunt/oss-fuzz/git/git.c:771:4
    git#13 0x4cac29 in cmd_main /home/ahunt/oss-fuzz/git/git.c:902:19
    git#14 0x69c45e in main /home/ahunt/oss-fuzz/git/common-main.c:52:11
    git#15 0x7f6a459d5349 in __libc_start_main (/lib64/libc.so.6+0x24349)

Direct leak of 105 byte(s) in 1 object(s) allocated from:
    #0 0x49a859 in realloc /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3
    #1 0x9a71f6 in xrealloc /home/ahunt/oss-fuzz/git/wrapper.c:126:8
    #2 0x93622d in strbuf_grow /home/ahunt/oss-fuzz/git/strbuf.c:98:2
    #3 0x937a73 in strbuf_addch /home/ahunt/oss-fuzz/git/./strbuf.h:231:3
    #4 0x939fcd in strbuf_add_absolute_path /home/ahunt/oss-fuzz/git/strbuf.c:911:4
    #5 0x69d3ce in absolute_pathdup /home/ahunt/oss-fuzz/git/abspath.c:261:2
    #6 0x51c688 in cmd_clone /home/ahunt/oss-fuzz/git/builtin/clone.c:1021:10
    #7 0x4cd60d in run_builtin /home/ahunt/oss-fuzz/git/git.c:453:11
    git#8 0x4cb2da in handle_builtin /home/ahunt/oss-fuzz/git/git.c:704:3
    git#9 0x4ccc37 in run_argv /home/ahunt/oss-fuzz/git/git.c:771:4
    git#10 0x4cac29 in cmd_main /home/ahunt/oss-fuzz/git/git.c:902:19
    git#11 0x69c45e in main /home/ahunt/oss-fuzz/git/common-main.c:52:11
    git#12 0x7f6a459d5349 in __libc_start_main (/lib64/libc.so.6+0x24349)

Make sure we release a temporary strbuf during dwim_branch() for all codepaths.
Furthermore, UNLEAK dwim_branch()'s return value in add().

add() is only used directly from cmd_worktree(), hence there's little value
in making sure we actually free() the pointer there (vs just using UNLEAK).
Using free() would require more complicated changes as the same pointer is used
to point to either a string literal, an array member owned elsewhere, or a newly
allocated string returned by dwim_branch().

Both leaks found when running t0001 with LSAN (clang-11):

Direct leak of 60 byte(s) in 1 object(s) allocated from:
    #0 0x49a859 in realloc /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3
    #1 0x9ab076 in xrealloc /home/ahunt/oss-fuzz/git/wrapper.c:126:8
    #2 0x939fcd in strbuf_grow /home/ahunt/oss-fuzz/git/strbuf.c:98:2
    #3 0x93af53 in strbuf_splice /home/ahunt/oss-fuzz/git/strbuf.c:239:3
    #4 0x83559a in strbuf_check_branch_ref /home/ahunt/oss-fuzz/git/object-name.c:1593:2
    #5 0x6988b9 in dwim_branch /home/ahunt/oss-fuzz/git/builtin/worktree.c:454:20
    #6 0x695f8f in add /home/ahunt/oss-fuzz/git/builtin/worktree.c:525:19
    #7 0x694a04 in cmd_worktree /home/ahunt/oss-fuzz/git/builtin/worktree.c:1036:10
    git#8 0x4cd60d in run_builtin /home/ahunt/oss-fuzz/git/git.c:453:11
    git#9 0x4cb2da in handle_builtin /home/ahunt/oss-fuzz/git/git.c:704:3
    git#10 0x4ccc37 in run_argv /home/ahunt/oss-fuzz/git/git.c:771:4
    git#11 0x4cac29 in cmd_main /home/ahunt/oss-fuzz/git/git.c:902:19
    git#12 0x69caee in main /home/ahunt/oss-fuzz/git/common-main.c:52:11
    git#13 0x7f7b7dd10349 in __libc_start_main (/lib64/libc.so.6+0x24349)

Direct leak of 16 byte(s) in 1 object(s) allocated from:
    #0 0x49a53d in malloc /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
    #1 0x9aae74 in do_xmalloc /home/ahunt/oss-fuzz/git/wrapper.c:41:8
    #2 0x9aaf08 in do_xmallocz /home/ahunt/oss-fuzz/git/wrapper.c:75:8
    #3 0x9aaeea in xmallocz /home/ahunt/oss-fuzz/git/wrapper.c:83:9
    #4 0x9aaf97 in xmemdupz /home/ahunt/oss-fuzz/git/wrapper.c:99:16
    #5 0x9aafee in xstrndup /home/ahunt/oss-fuzz/git/wrapper.c:105:9
    #6 0x698887 in dwim_branch /home/ahunt/oss-fuzz/git/builtin/worktree.c:450:27
    #7 0x695f8f in add /home/ahunt/oss-fuzz/git/builtin/worktree.c:525:19
    git#8 0x694a04 in cmd_worktree /home/ahunt/oss-fuzz/git/builtin/worktree.c:1036:10
    git#9 0x4cd60d in run_builtin /home/ahunt/oss-fuzz/git/git.c:453:11
    git#10 0x4cb2da in handle_builtin /home/ahunt/oss-fuzz/git/git.c:704:3
    git#11 0x4ccc37 in run_argv /home/ahunt/oss-fuzz/git/git.c:771:4
    git#12 0x4cac29 in cmd_main /home/ahunt/oss-fuzz/git/git.c:902:19
    git#13 0x69caee in main /home/ahunt/oss-fuzz/git/common-main.c:52:11
    git#14 0x7f7b7dd10349 in __libc_start_main (/lib64/libc.so.6+0x24349)

init_db_config_path could be leaked because:
1. git_init_db_config() allocates new data into init_db_config_path on every
   invocation without freeing preexisting data.
2. git_init_db_config() can be called multiple times for a single git_config()
   invocation (see docs on git_config() for context).
Furthermore, until very recently, git_config(git_init_db_config(), ...) could
have been invoked twice in a single process as git_init_db_config() used to
be used to handle core.* config settings. This was changed in a previous
patch in this series.

Freeing the existing value in git_init_db_config() would be the least intrusive
fix, however switching to git_config_get_value() simplifies the code further by
letting us remove the static pointer (furthermore, the returned data is owned by
the config cache, saving us from having to worry about freeing it later).

LSAN output from t0001:

Direct leak of 73 byte(s) in 1 object(s) allocated from:
    #0 0x49a859 in realloc /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3
    #1 0x9a7276 in xrealloc /home/ahunt/oss-fuzz/git/wrapper.c:126:8
    #2 0x9362ad in strbuf_grow /home/ahunt/oss-fuzz/git/strbuf.c:98:2
    #3 0x936eaa in strbuf_add /home/ahunt/oss-fuzz/git/strbuf.c:295:2
    #4 0x868112 in strbuf_addstr /home/ahunt/oss-fuzz/git/./strbuf.h:304:2
    #5 0x86a8ad in expand_user_path /home/ahunt/oss-fuzz/git/path.c:758:2
    #6 0x720bb1 in git_config_pathname /home/ahunt/oss-fuzz/git/config.c:1287:10
    #7 0x5960e2 in git_init_db_config /home/ahunt/oss-fuzz/git/builtin/init-db.c:161:11
    git#8 0x7255b8 in configset_iter /home/ahunt/oss-fuzz/git/config.c:1982:7
    git#9 0x7253fc in repo_config /home/ahunt/oss-fuzz/git/config.c:2311:2
    git#10 0x725ca7 in git_config /home/ahunt/oss-fuzz/git/config.c:2399:2
    git#11 0x593e8d in create_default_files /home/ahunt/oss-fuzz/git/builtin/init-db.c:225:2
    git#12 0x5935c6 in init_db /home/ahunt/oss-fuzz/git/builtin/init-db.c:449:11
    git#13 0x59588e in cmd_init_db /home/ahunt/oss-fuzz/git/builtin/init-db.c:714:9
    git#14 0x4cd60d in run_builtin /home/ahunt/oss-fuzz/git/git.c:453:11
    git#15 0x4cb2da in handle_builtin /home/ahunt/oss-fuzz/git/git.c:704:3
    git#16 0x4ccc37 in run_argv /home/ahunt/oss-fuzz/git/git.c:771:4
    git#17 0x4cac29 in cmd_main /home/ahunt/oss-fuzz/git/git.c:902:19
    git#18 0x69c4de in main /home/ahunt/oss-fuzz/git/common-main.c:52:11
    git#19 0x7f23552d6349 in __libc_start_main (/lib64/libc.so.6+0x24349)

preprocess_options() allocates new strings for help messages if the input
options contain aliases. Therefore we also need to clean those help messages up
when freeing the returned options.

First introduced in:
7c28058 (parse-options: teach "git cmd -h" to show alias as alias, 2020-03-16)

The preprocessed options themselves no longer contain any indication that a
given option is/was an alias: the easiest and fastest way to figure it out is
to look back at the original options. Alternatively we could iterate over the
alias_groups list - but that would require nested looping and is likely to
be a (little) less efficient.

As far as I can tell, parse_options() is only ever used once per command, and
the help messages are small - hence this leak has very little impact.

This leak was found while running t0001. LSAN output can be found below:

Direct leak of 65 byte(s) in 1 object(s) allocated from:
    #0 0x49a859 in realloc /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3
    #1 0x9aae36 in xrealloc /home/ahunt/oss-fuzz/git/wrapper.c:126:8
    #2 0x939d8d in strbuf_grow /home/ahunt/oss-fuzz/git/strbuf.c:98:2
    #3 0x93b936 in strbuf_vaddf /home/ahunt/oss-fuzz/git/strbuf.c:392:3
    #4 0x93b7ff in strbuf_addf /home/ahunt/oss-fuzz/git/strbuf.c:333:2
    #5 0x86747e in preprocess_options /home/ahunt/oss-fuzz/git/parse-options.c:666:3
    #6 0x866ed2 in parse_options /home/ahunt/oss-fuzz/git/parse-options.c:847:17
    #7 0x51c4a7 in cmd_clone /home/ahunt/oss-fuzz/git/builtin/clone.c:989:9
    git#8 0x4cd60d in run_builtin /home/ahunt/oss-fuzz/git/git.c:453:11
    git#9 0x4cb2da in handle_builtin /home/ahunt/oss-fuzz/git/git.c:704:3
    git#10 0x4ccc37 in run_argv /home/ahunt/oss-fuzz/git/git.c:771:4
    git#11 0x4cac29 in cmd_main /home/ahunt/oss-fuzz/git/git.c:902:19
    git#12 0x69c9fe in main /home/ahunt/oss-fuzz/git/common-main.c:52:11
    git#13 0x7fdac42d4349 in __libc_start_main (/lib64/libc.so.6+0x24349)

Fixes the following leak encountered when running t0001:

Direct leak of 19 byte(s) in 1 object(s) allocated from:
    #0 0x486514 in strdup /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/asan_interceptors.cpp:452:3
    #1 0x9ab048 in xstrdup /home/ahunt/oss-fuzz/git/wrapper.c:29:14
    #2 0x8b452f in refs_shorten_unambiguous_ref /home/ahunt/oss-fuzz/git/refs.c
    #3 0x8b47e8 in shorten_unambiguous_ref /home/ahunt/oss-fuzz/git/refs.c:1287:9
    #4 0x679fce in check_symref /home/ahunt/oss-fuzz/git/builtin/symbolic-ref.c:28:14
    #5 0x679ad8 in cmd_symbolic_ref /home/ahunt/oss-fuzz/git/builtin/symbolic-ref.c:70:9
    #6 0x4cd60d in run_builtin /home/ahunt/oss-fuzz/git/git.c:453:11
    #7 0x4cb2da in handle_builtin /home/ahunt/oss-fuzz/git/git.c:704:3
    git#8 0x4ccc37 in run_argv /home/ahunt/oss-fuzz/git/git.c:771:4
    git#9 0x4cac29 in cmd_main /home/ahunt/oss-fuzz/git/git.c:902:19
    git#10 0x69cc6e in main /home/ahunt/oss-fuzz/git/common-main.c:52:11
    git#11 0x7f98388a4349 in __libc_start_main (/lib64/libc.so.6+0x24349)