Split the SHA256 builds into their own workflow; since they're
experimental (and have proven to be flaky) they shouldn't be used as
signal that there's a problem with a PR.
The Microsoft C runtime (MSVCRT) may take a heavy lock on the
locale in order to figure out how the `ctype` functions work.
This is deeply slow. Provide our own to avoid that.
On POSIX, provide emulation for that functionality using the ctype
functions, but compress the return value into a `bool`, and cast the
value to an `unsigned char`.
Update `git_fetch_options` to break out the fetch options into
individual options. This prevents creating an API breaking change from
v1.7.0. `git_remote_update_tips` retains the `update_flags` to also
avoid an API breaking change.
Instead of trying to allocate something, hand it to mbedTLS, and then
peer into its private data structures to try to free that thing... we
could just keep track of it ourselves.
Once we've done that, we needn't do an allocation _anyway_, we can just
keep it on the stack.
libgit2 may adjust the system includes - for example, to locate a
dependency installed in a funny location. Ensure that the cli
understands those include paths as well.
The packbuilder tests should be deterministic. This comment suggests
that they are:
```
/*
* By default, packfiles are created with only one thread.
* Therefore we can predict the object ordering and make sure
* we create exactly the same pack as git.git does when *not*
* reusing existing deltas (as libgit2).
*
* $ cd tests/resources/testrepo.git
* $ git rev-list --objects HEAD | \
* git pack-objects -q --no-reuse-delta --threads=1 pack
* $ sha1sum pack-7f5fa362c664d68ba7221259be1cbd187434b2f0.pack
* 5d410bdf97cf896f9007681b92868471d636954b
*
*/
```
but it is disappointingly incorrect. As is evidenced by the fact that --
at least on _my_ machine -- that command does not actually produce that
output any longer.
Variations in things like the which compression library is actually
used, and its defaults, mean that we cannot accurately predict or
enforce the bytes in the packfile from one system to another.
Adjust the tests so that they do not believe that they should enforce
the bytes in the packfile. This allows broader compatibility with
zlib-compatible compression libraries, or other compression levels.
Linux updated its ASLR randomization in a way that is incompatible with
TSAN. See https://github.com/google/sanitizers/issues/1716
Reducing the randomness for ASLR allows the sanitizers to cope.
Git looks explicitly for `---` followed by whitespace (`isspace()`) to
determine when a patch line begins in a commit message. Match that
behavior. This ensures that we don't treat (say) `----` as a patch line
incorrectly.
When we start a transaction, we should refcount the backend so that we
don't lose it. This prevents the case where we have a transaction open
and a configuration entry locked and somebody forces a new backend at
the same level and the backend is freed. Now a user can gently wind down
their transaction even when the backend has been removed from the live
configuration object.
When we `git_config_unlock`, we shouldn't _unlock the thing that we
locked_ instead of assuming that the highest-priority target _remains_
the highest-priority target.
When a configuration transaction is freed with `git_transaction_free` -
without first committing it - we should not `git_config_free`. We never
increased the refcount, so we certainly shouldn't decrease it.
Also, add a test around aborting a transaction without committing it.
Introduce `GIT_EREADONLY` and return it when a read-only configuration
is attempted to be mutated. This is preferred over the prior
`GIT_ENOTFOUND` which is not accurate.
Configuration read order and write order should be separated. For
example: configuration readers have a worktree level that is higher
priority than the local configuration _for reads_. Despite that, the
worktree configuration is not written to by default.
Use a new list, `writers`, to identify the write target.
To do this, we need another level of indirection between backend
instances (which are refcounted and shared amongst different git_config
instances) and the config reader/writer list (since each of those
different git_config instances can have different read/write
priorities).
The refdb iterator has grown a bit and has a few concerns intermixed.
Refactor a bit to improve readability while trying to avoid unnecessary
git_str allocations.
