The goal is to let cmake manage the parallelism

==17851== Invalid free() / delete / delete[] / realloc()
==17851==    at 0x4C2BDEC: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==17851==    by 0x60BBE2B: __libc_freeres (in /lib/x86_64-linux-gnu/libc-2.19.so)
==17851==    by 0x4A256BC: _vgnU_freeres (in /usr/lib/valgrind/vgpreload_core-amd64-linux.so)
==17851==    by 0x5F8F16A: __run_exit_handlers (exit.c:97)
==17851==    by 0x5F8F1F4: exit (exit.c:104)
==17851==    by 0x5F74F4B: (below main) (libc-start.c:321)
==17851==  Address 0x63153c0 is 0 bytes inside data symbol "noai6ai_cached"

==2957== 912 bytes in 19 blocks are still reachable in loss record 323 of 369
==2957==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2957==    by 0x675B120: ??? (in /lib/x86_64-linux-gnu/libgcrypt.so.11.8.2)
==2957==    by 0x675BDF8: ??? (in /lib/x86_64-linux-gnu/libgcrypt.so.11.8.2)
==2957==    by 0x675FE0D: ??? (in /lib/x86_64-linux-gnu/libgcrypt.so.11.8.2)
==2957==    by 0x6761DC4: ??? (in /lib/x86_64-linux-gnu/libgcrypt.so.11.8.2)
==2957==    by 0x676477E: ??? (in /lib/x86_64-linux-gnu/libgcrypt.so.11.8.2)
==2957==    by 0x675B071: ??? (in /lib/x86_64-linux-gnu/libgcrypt.so.11.8.2)
==2957==    by 0x675B544: ??? (in /lib/x86_64-linux-gnu/libgcrypt.so.11.8.2)
==2957==    by 0x675914B: gcry_control (in /lib/x86_64-linux-gnu/libgcrypt.so.11.8.2)
==2957==    by 0x5D30EC9: libssh2_init (in /usr/lib/x86_64-linux-gnu/libssh2.so.1.0.1)
==2957==    by 0x66BCCD: git_transport_ssh_global_init (ssh.c:910)
==2957==    by 0x616443: init_common (global.c:65)

==18109== 664 bytes in 1 blocks are still reachable in loss record 279 of 339
==18109==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==18109==    by 0x675B120: ??? (in /lib/x86_64-linux-gnu/libgcrypt.so.11.8.2)
==18109==    by 0x675C13C: ??? (in /lib/x86_64-linux-gnu/libgcrypt.so.11.8.2)
==18109==    by 0x675C296: ??? (in /lib/x86_64-linux-gnu/libgcrypt.so.11.8.2)
==18109==    by 0x679BD14: ??? (in /lib/x86_64-linux-gnu/libgcrypt.so.11.8.2)
==18109==    by 0x679CC64: ??? (in /lib/x86_64-linux-gnu/libgcrypt.so.11.8.2)
==18109==    by 0x6A64946: ??? (in /usr/lib/x86_64-linux-gnu/libgnutls.so.26.22.6)
==18109==    by 0x6A116E8: ??? (in /usr/lib/x86_64-linux-gnu/libgnutls.so.26.22.6)
==18109==    by 0x6A01114: gnutls_global_init (in /usr/lib/x86_64-linux-gnu/libgnutls.so.26.22.6)
==18109==    by 0x52A6C78: ??? (in /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.3.0)
==18109==    by 0x5285ADC: curl_global_init (in /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.3.0)
==18109==    by 0x663524: git_curl_stream_global_init (curl.c:44)

Detect duplicated submodules for the same path

Fix docurium missing includes

github: update issue template

streams: openssl: add missing check on OPENSSL_LEGACY_API

Previous to dfda2f68 (submodule: remove the per-repo cache,
2015-04-27), we tried to cache our submodules per repository to avoid
having to reload it too frequently. As it created some headaches with
regards to multithreading, we removed that cache.

Previous to that removal, we had to compute what submodule status to
refresh. The mask computation was not removed, though, resulting in
confusing and actually dead code. While it seems like the mask is
currently in use in a conditional, it is not, as we unconditionally
assign to the mask previous to that condition.

Remove all mask computations to clean up stale code.

The function `load_submodule_names` was always being called with a
newly allocated string map, which was then getting filled by the
function. Move the string map allocation into `load_submodule_names`,
instead, and pass the whole map back to the caller in case no error
occurs. This change helps to avoid misuse by handing in pre-populated
maps.

When loading submodule names, we build a map of submodule paths and
their respective names. While looping over the configuration keys,
we do not check though whether a submodule path was seen already. This
leads to a memory leak in case we have multiple submodules with the same
path, as we just overwrite the old value in the map in that case.

Fix the error by verifying that the path to be added is not yet part of
the string map. Git does not allow to have multiple submodules for a
path anyway, so we now do the same and detect this duplication,
reporting it to the user.

mbedtls: don't require mbedtls from our pkgconfig file

The `CRYPTO_THREADID` type is no longer available in OpenSSL ≥ 1.1.0 with deprecated features disabled, and causes build failures. Since the `threadid_cb()` function is only ever called by `git_openssl_set_locking()` when `defined(OPENSSL_LEGACY_API)`, only define it then.

Fixes for CVE 2018-11235

mbedTLS has no pkgconfig file, hence we can't require it. For now, pass its link flags as our own.

Added note about Windows junction points to the differences from git document

We might modify caches due to us trying to load the configuration to figure out
what kinds of filesystem protections we should have.

We still compare case-insensitively to protect more thoroughly as we don't know
what specifics we'll see on the system and it's the behaviour from git.

When dealing with `core.proectNTFS` and `core.protectHFS` we do check
against `.gitmodules` but we still have a failing test as the non-filesystem
codepath does not check for it.

Any part of the library which asks the question can pass in the mode to have it
checked against `.gitmodules` being a symlink.

This is particularly relevant for adding entries to the index from the worktree
and for checking out files.

This is so we have it available for the path validity checking. In a later
commit we will start rejecting `.gitmodules` files as symlinks.

We may take in names from the middle of a string so we want the caller to let us
know how long the path component is that we should be checking.

We want to reject these as they cause compatibility issues and can lead to git
writing to files outside of the repository.

These will be used by the checkout code to detect them for the particular
filesystem they're on.

These can't go into the public API yet as we don't want to introduce API or ABI
changes in a security release.

Given a path component it knows what to pass to the filesystem-specific
functions so we're protected even from trees which try to use the 8.3 naming
rules to get around us matching on the filename exactly.

The logic and test strings come from the equivalent git change.

It checks against the 8.3 shortname variants, including the one which includes
the checksum as part of its name.

This lets us check for other kinds of reserved files.

Otherwise we would also admit `..\..\foo\bar` as a valid path and fail to
protect Windows users.

Ideally we would check for both separators without the need for the copied
string, but this'll get us over the RCE.