### Bug Fixes

 - unify the dependency graph by choosing the right versions, upgrading to `gix-features 0.42`
   This is what should silence audit failures.

### Commit Statistics

 - 1 commit contributed to the release.
 - 1 commit was understood as [conventional](https://www.conventionalcommits.org).
 - 0 issues like '(#ID)' were seen in commit messages

### Commit Details

 * **Uncategorized**
    - Unify the dependency graph by choosing the right versions, upgrading to `gix-features 0.42` (9b12d50)

### Changed

 - In gix-testtools use `ignore` and `index` via `gix_worktree`
   This removes the `gix-ignore` and `gix-index` direct dependencies
   of `gix-testtools`, by having `gix_testtools` use them through
   `gix-worktree`, accessing `gix_worktree::ignore` for `gix_ignore`
   and `gix_worktree::index` for `gix_index`.
   
   The rationale is that various other gix-* dependencies were used
   this way already, and also that this specific change appears to
   have been planned, based on the TODO comment in ddaacda (#1413).

### New Features

 - Show unexpected stderr in `umask` panic message
   Because `gix_testtools::umask()` is only suitable for use in tests,
   where signaling an error with a panic is typically acceptable, it
   panics rather than returning an `Error` to indicate errors. To
   avoid leading to the use of a potentially inaccurate umask value,
   it treats as an error any departure from the typical output of
   the `umask` command: in addition to treating a nonzero exit status
   as an error, it also treats anything it cannot strictly parse on
   stdout as an error, as well as anything at all written to stderr as
   an error. The latter is to avoid a situation where a warning is
   printed that is could be significant to some umask use cases.
   
   Warnings from `umask` are rare, as well as from the shell that is
   used as an intermediary for running the command (since no external
   `umask` command need exist and, often, does not) when it is used
   just to run `umask`. When they do occur, they are sometimes from
   the dynamic linker, such as a warning about a shared library listed
   in the `LD_PRELOAD` environment variable that cannot be used by
   the shell program. To understand and distinguish such errors, it is
   useful to show the text that was sent to stderr, since tests are
   sometimes run in environments that are nontrivial to reproduce
   otherwise. For example, running tests with `cross` produces an
   environment that is not in all respects the same as what one gets
   with `docker exec -it <container>`, even if `<container>` is the
   same still-running container being used to run the tests.
   
   This modifies `gix_testtools::umask()` so that when it panics due
   anything being written to stderr, it shows what was written.
 - Add `jtt bash-program` (`jtt bp`) to show `bash_program()`
   This adds a `bash-program` subcommand, abbreviated `bp`, to the
   `gix-testools` program (`jtt`) to check what the `bash_program()`
   library function gives.
   
   This is intended for diagnostic use and should probably not be used
   in scripting. Currently it shows the quoted debug repreesentation
   of the path.
 - Document `gix_testtools::bash_program()` and make it public
   To make it easier for users of `gix-testtools` to diagnose problems
   or verify that the fallback for running fixutre scripts without
   usable shebangs (which is effectively how any fixture shell script
   is run on Windows), the formerly private `bash_program()` is now
   public.
   
   However, it is not recommend to rely on this specific value or on
   observed behavior of how it is computed. The details may change at
   any time.
   
   The purpose of `bash_program()` and how it is used internally by
   `gix-testtools` is also now documented explicitly. Broad details of
   how it searches or guesses what path to use are likewise documented,
   with a caveat that changes to them are not considered breaking.
 - Look for bash in `(git root)/bin`, then `(git root)/usr/bin`
   This changes `bash_program()` so that it will find the `bash.exe`
   provided by Git for Windows that is most reliable for our use in
   runinng test fixture scripts, of those that are available. First
   it uses the shim, but falls back to the non-shim if the shim is
   not available. If neither is found, then the fallback of using the
   simple command `bash.exe` (which triggers a path search when run)
   continues to be used.
 - Prefer `/` over `\` in `bash.exe` path (for fixtures)
   Starting in #1712, `gix-testtools` looks for `bash.exe` on Windows
   in one of its common locations as provided by Git for Windows, by
   taking the path given by `git --exec-path`, going up by three
   components, and going down to `bin/bash.exe` under that. But the
   `bin` and `bash.exe` components were appended in a way that used
   `\` directory separators.
   
   Ordinarily, that would be ideal, since `\` is the primary directory
   separator on Windows. However, in this case, appending with `\`
   produces a path that is harder to read (especially in diagostic
   messages), and that may cause problems if it is processed by a
   shell or in a way that is intended to operate similarly to shell
   processing of `\`.
   
   A path that does not explicitly prefer `/` but instead uses
   `PathBuf::push` will have `\` in front of the new components, but
   will still usually have `/` in front of the old components. This is
   because, aside from the unusual case that the `GIT_EXEC_PATH`
   environment vairable is set explicitly and its value uses all `\`
   separators, the output of `git --exec-path`, which we use to find
   where `git` installed on Windows, uses `/` separators.
   
   The effect of this change seems to be fairly minor, with existing
   test fixtures having worked before it was done. This is partly
   because, on Windows, the value of `argv[0]` that the shell
   actually sees -- and that populates `$0` when no script name is
   available, as happens in `bash -c '...'` with no subsequent
   arguments -- is translated by an MSYS DLL such as `msys-2.0.dll`
   (or, for Cygwin, `cygwin1.dll`) into a Unix-style path meaningful
   to the shell.
   
   This also refactors for clarity, and adds new tests related to the
   change.
 - Add `gix_testtools::umask`, safe but only meant for tests
   This implements a function for tests to safely read the current
   process umask without the usual race condition of doing so, at the
   expense of using subprocesses to do it. This just calls a shell and
   runs `umask` from it (which is expected to be a builtin and, on
   many systems, is available as a builtin but not an executable).
   
   Even though this is safe, including thread-safe, it is unlikely to
   be suitable for use outside of tests, because of its use of
   `expect` and assertions when there are errors, combined with the
   possibly slow speed of using subprocesses.
   
   Given that this is effecitvely running a tiny shell script to do
   the work, why is it not instead a fixture script that is named in
   a `.gitignore` file so that it is not tracked? The reason is that
   the outcomes of running such fixture scripts are still saved across
   separate test runs, but it is useful to be able to run the tests
   with differnt umasks, e.g. `(umask 077; cargo nextest run ...)`.
   
   The immediate purpose is in forthcoming tests that, when checkout
   sets +x on an existing file, it doesn't set excessive permissions.
   The fix to pass such a test is not currently planned to use the
   umask explicitly. But the tests will use it, at least to detect
   when they cannot really verify the code under test on the grounds
   that they are running with an excessively permissive umask that
   doesn't allow behavior that only occurs with a generally reasonable
   umask to be observed.
 - Add `size_ok` for asserting size is not too big
   This compares using `==` on 64-bit targets and `<=` on 32-bit
   targets.
   
   As noted in the documentation comment, when assertions about data
   stuructures' sizes are being done to safeguard against them growing
   too big, then it may be acceptable to use `<=` if the structure is
   smaller on 32-bit targets, but it is still valuable to be able to
   use `==` on 64-bit targets in the same assertions, since this
   guards against a data structure becoming smaller, other changes
   causing the smaller size to be important for memory usage or speed,
   but then the data structure growing again, up to its original size.
   An unconditional `<=` will not catch this, while `size_ok` usually
   will.
   
   A related reason to do a `==` on 64-bit systems is so that the
   expected value being compared to remains tied to the code. It can
   otherwise become unclear what the expected value's significance is
   and whether it ought to be updated.
 - Recognize `GIX_TEST_CREATE_ARCHIVES_EVEN_ON_CI`
   When `gix-testtools` runs fixtures, it now recognizes a new
   environment variable, `GIX_TEST_CREATE_ARCHIVES_EVEN_ON_CI`,
   specifying that archives should be generated even when on CI.
   
   By default, they are still not generated when on CI. It may make
   sense to enable this:
   
   - If automatically testing archive creation, or
   
   - As a way to check that all intended generated arhives are committed
     (which is the motivating use case for this feature), or
   
   - If actually using CI to generate archives that will be uploaded
     as artifacts, or
   
   - In unusual non-CI environments that are mis-detected as CI
     (though that should usually be investigated and fixed, since some
     software performs destructive operations more readily without
     interactive checks when CI is detected).
   
   The usual reason for not generating archives on CI is that they
   would not typically be preserved. Thus refraining from generating
   them on CI remains the default behavior.
   
   Like the `GIX_TEST_IGNORE_ARCHIVES` environment variable, the new
   variable `GIX_TEST_CREATE_ARCHIVES_EVEN_ON_CI` is currently
   interpreted as "true" based solely on its presence. This is to say
   that is actual value is currently not examined.

### Bug Fixes

 - fix check to detect `git-lfs` managed files that weren't checked out.
   Previously it would detect them incorrectly due to a find-and-replace
   error.
 - create a more local lock when creating writable fixtures.
   Previously, the lock location would block all writers from executing
   a fixture even though they wouldn't step on each others feet.
   
   Now, a script destination is used to assure locks are created close
   to the destination when creating writable fixtures, typically removing
   the need for multiple writers to wait on each other unnecessarily.
 - Run test fixture scripts on Windows with Git Bash
   Rather than hard-coding `bash` on all systems as the fallback
   interpreter when a fixture script cannot be run directly, this
   falls back in an operating system specific manner:
   
   - Except on Windows, always fall back to `bash`, as before.
   
   - On Windows, run `git --exec-path` to find the `git-core`
     directory. Then check if a `bash.exe` exists at the expected
     location relative to that. In Git for Windows installations,
     this will usually work. If so, use that path (with `..`
     components resolved away).
   
   - On Windows, if a specific `bash.exe` is not found in that way,
     then fall back to using the relative path `bash.exe`. This is to
     preserve the ability to run `bash` on Windows systems where it
     may have worked before even without `bash.exe` in an expected
     location provided by a Git for Windows installation.
   
   (The distinction between `bash` and `bash.exe` is only slightly
   significant: we check for the existence of the interpreter without
   initially running it, and that check requires the full filename.
   It is called `bash.exe` elsewhere for consistency both with the
   checked-for executable and for consistencey with how we run most
   other programs on Windows, e.g., the `git` vs. `git.exe`.)
   
   This fixes #1359. That bug is not currently observed on CI, but
   this change is verified to fix it on a local test system where it
   previously always occurred when running the test suite from
   PowerShell in an unmodified environment. The fix applies both with
   `GIX_TEST_IGNORE_ARCHIVES` unset, in which case there are now no
   failures, and with `GIX_TEST_IGNORE_ARCHIVES=1`, in which case the
   failures are now limited to the 15 cases tracked in #1358.
   
   Previously, fixture scripts had been run on Windows with whatever
   `bash` was found in a `PATH` search, which had two problems:
   
   - On most Windows systems, even if no WSL distribution is installed
     and even if WSL itself is not set up, the `System32` directory
     contains a `bash.exe` program associated with WSL. This program
     attempts to use WSL to run `bash` in an installed distribution.
     The `wsl.exe` program also provides this functionality and is
     favored for this purpose, but the `bash.exe` program is still
     present and is likely to remain for many years for compatibility.
   
     Even when this `bash` is usable, it is not suited for running
     most shell scripts meant to operate on the native Windows system.
     In particular, it is not suitable for running our fixture
     scripts, which need to use the native `git` to prepare fixtures
     to be used natively, among other requirements that would not be
     satisfied with WSL (except when the tests are actually running in
     WSL).
   
     Since some fixtures are `.gitignore`d because creating them on
     the test system (rather than another system) is part of the test,
     this has caused breakage in most Windows environments unless
     `PATH` is modified -- either explicitly or by testing in an MSYS2
     environment, such as the Git Bash environment -- whether or not
     `GIX_TEST_IGNORE_ARCHIVES` is set. This was the cause of #1359.
   
   - Although using a Git Bash environment or otherwise adjusting the
     path *currently* works, the reasons it works are subtle and rely
     on non-guaranteed behavior of `std::process::Command` path search
     that may change without warning.
   
     On Windows, processes are created by calling the `CreateProcessW`
     API function. `CreateProcessW` is capable of performing a `PATH`
     search, but this `PATH` search is not secure in most uses, since
     it includes the current directory (and searches it before `PATH`
     directories) unless `NoDefaultCurrentDirectoryInExePath` is set
     in the caller's environment.
   
     While it is the most relevant to security, the CWD is not the
     only location `CreateProcessW` searches before searching `PATH`
     directories (and regardless of where, if anywhere, they may also
     appear in `PATH`). Another such location is the `System32`
     directory. This is to say that, even when another directory with
     `bash.exe` precedes `System32` in `PATH`, an executable search
     will still find the WSL-associated `bash.exe` in `System32`
     unless it deviates from the algorithm `CreateProcessW` uses.
   
     To avoid including the CWD in the search, `std::process::Command`
     performs its own path search, then passes the resolved path to
     `CreateProcessW`. The path search it performs is currently almost
     the same the algorithm `CreateProcessW` uses, other than not
     automatically including the CWD. But there are some other subtle
     differences.
   
     One such difference is that, when the `Command` instance is
     configured to create a modified child environment (for example,
     by `env` calls), the `PATH` for the child is searched early on.
     This precedes a search of the `System32` directory. It is done
     even if none of the customizations of the child environment
     modify its `PATH`.
   
     This behavior is not guaranteed, and it may change at any time.
     It is also the behavior we rely on inadvertently every time we
     run `bash` on Windows with a `std::process::Command` instance
     constructed by passing `bash` or `bash.exe` as the `program`
     argument: it so happens that we are also customizing the child
     environment, and due to implementation details in the Rust
     standard library, this manages to find a non-WSL `bash` when
     the tests are run in Git Bash, in GitHub Actions jobs, and in
     some other cases.
   
     If in the future this is not done, or narrowed to be done only
     when `PATH` is one of the environment variables customized for
     the child process, then putting the directory with the desired
     `bash.exe` earlier than the `System32` directory in `PATH` will
     no longer prevent `std::proces::Command` from finding the
     `bash.exe` in `System32` as `CreateProcessW` would and using it.
     Then it would be nontrivial to run the test suite on Windows.
   
   For references and other details, see #1359 and comments including:
   #1359 (comment)
   
   On the approach of finding the Git for Windows `bash.exe` relative
   to the `git-core` directory, see the GitPython pull request
   gitpython-developers/GitPython#1791, its
   comments, and the implementation of the approach by @emanspeaks:
   https://github.com/gitpython-developers/GitPython/blob/f065d1fba422a528a133719350e027f1241273df/git/cmd.py#L398-L403
   
   Two possible future enhancements are *not* included in this commit:
   
   1. This only modifies how test fixture scripts are run. It only
      affects the behavior of `gix-testtools`, and not of any other
      gitoxide crates such as `gix-command`. This is because:
   
      - While gitoxide uses information from `git` to find out where
        it is installed, mainly so we know where to find installation
        level configuration, we cannot in assume that `git` is present
        at all. Unlike GitPython, gitoxide is usable without `git`.
   
      - We know our test fixture scripts are all (at least currently)
        `bash` scripts, and this seems likely for other software that
        currently uses this functionality of `gix-testtools`. But
        scripts that are run as hooks, or as custom commands, or
        filters, etc., are often written in other languages, such as
        Perl. (The fallback here does not examine leading `#!` lines.)
   
      - Although a `bash.exe` located at the usual place relative to
        (but outside of) the `git-core` directory is usually suitable,
        there may be scenarios where running an executable found this
        way is not safe. Limiting it to `gix-testtools` pending
        further research may help mitigate this risk.
   
   2. As in other runs of `git` by `gix-testools`, this calls
      `git.exe`, letting `std::process::Command` do an executable
      search, but not trying any additional locations where Git is
      known sometimes to be installed. This does not find `git.exe` in
      as many situations as `gix_path::env::exe_invocation` does.
   
      The reasons for not (or not quite yet) including that change are:
   
      - It would add `gix-path` as a dependency of `gix-testtools`.
   
      - Finding `git` in a `std::process::Command` path search is an
        established (though not promised) approach in `gix-testtools`,
        including to run `git --exec-path` (to find `git-daemon`).
   
      - It is not immediately obvious that `exe_invocation` behavior
        is semantically correct for `gix-testtools`, though it most
        likely is reasonable.
   
        The main issue is that, in many cases where `git` itself runs
        scripts, it prepends the path to the `git-core` directory to
        the `PATH` environment variable for the script. This directory
        has a `git` (or `git.exe`) executable in it, so scripts run
        an equivalent `git` associated with the same installation.
   
        In contrast, when we run test fixture scripts with a
        `bash.exe` associated with a Git for Windows installation, we
        do not customize its path. Since top-level scripts written to
        use `git` but not to be used *by* `git` are usually written
        without the expectation of such an environment, prepending
        this will not necessarily be an improvement.
 - Double the fixture lock timeout
   This increases the lock timeout used in `gix-testtools` from 3 min
   6 min. This seems to fix #1605.
 - Unset other env vars related to `GIT_DIR` for fixtures
   This removes other environment variables that have an effect
   conceptually related to `GIT_DIR` even when `GIT_DIR` is not set.
   Most of them change where `git` will look for files that are
   ordinarily in a repository's `.git` directory. In contrast,
   `GIT_WORK_TREE` changes where the working tree is found.
   
   These would rarely be set in the environment in which the tests are
   run, but it makes sense to unset them for the same reason as
   unsetting `GIT_DIR`, which is already done.
   
   The new `remove_env` calls are roughly in the order in which the
   variables they unset are listed in git(1).
   
   This deliberately does not attempt to unset every possible
   environment variable that git(1) documents as affecting its
   behavior. This is for four reasons:
   
   - Some variables may be set on the test machine without envisioning
     this usage, but should still be kept, such as those that cause
     more or less traversal than usual to be done. For example, if
     `GIT_CEILING_DIRECTORIES` or even `GIT_DISCOVERY_ACROSS_FILESYSTEM`
     are set, it may be for a good reason.
   
   - Some variables will have no default unless other variables that
     are being modified here are changed again after the changes here.
     In particular, `GIT_CONFIG_SYSTEM` only has an effect if
     `GIT_CONFIG_NOSYSTEM` is not set. We set `GIT_CONFIG_NOSYSTEM` to
     `1`, so if it is unset then a fixture script has unset it, in
     which case it is presumably intended that `GIT_CONFIG_SYSTEM`
     have some effect (if the fixture script doesn't change/unset it).
   
   - Some variables are useful for extra debugging and make sense to
     set when running the test fixtures under foreseeable conditions.
     For example, the effects of all `GIT_TRACE*` variables are
     intentionally preserved.
   
   - For a few variables, such as `GIT_DEFAULT_HASH`, it is unlikely
     that they would be wanted in the test environment, but even more
     unlikely that they would be set in that environment without the
     intention of experimenting with their effect on fixtures.
   
   However, this is not to say that all environment variables that
   would make sense to remove have necessarily been removed.
   
   The removed variables here differ from those removed for the `git`
   invocation in `gix-path/src/env/git/mod.rs` for two reasons:
   
   - That is a single `git` invocation for a specific command, so the
     environment variables that ought to affect it must be kept, and
     others can be removed. But here, arbitrary fixtures need to work,
     and they provide almost all of their own environment as needed.
   
   - Setting an unusual value of `GIT_DIR` there that `git` cannot
     take to be a usable repository also prevents the variables
     that override `GIT_DIR` for specific files from being used. (But
     maybe those should be unset there anyway, for clarity?)
 - Append to preexisting `MSYS` env var even if ill-formed
   The value of an environment variable as obtained by the facilities
   in `std::env` is not always well-formed Unicode. Specifically, on
   Windows the values of environment variables, like paths, are
   natively UTF-16LE strings except that unpaired surrogate code
   points can also occur. An `&OsStr` on Windows may accordingly not
   quite be UTF-8.
   
   When the `MSYS` variable is absent, we treat this the same as when
   it is present but empty. However, as described in #1574, an `MSYS`
   variable that is present but whose value contains an unpaired
   surrogate would also be replaced entirely, rather than appending to
   its old value.
   
   This changes that, to instead append, retaining whatever was there
   even if it was ill-formed Unicode.
   
   An alternative change could be to panic when the old value is
   ill-formed Unicode. This commit allows and appends to the old
   value, rather than panicking or keeping and documenting the
   previous behavior of discarding the old value, because the appended
   sequence ` winsymlinks:nativestrict` is effective at causing
   fixture scripts to attempt to create actual symlinks even if
   the preceding code point is an unpaired Unicode high surrogate.
 - Omit other high-scoped config in fixtures
   In addition to keeping fixture scripts from receiving global and
   system scope Git configuration variables, as was already done, this
   also omits configuration variables from high scopes similar to or
   above the system scope, associated with the Git installation but
   separate from the system scope.
   
   The main and possibly only case where this happens is the "unknown"
   scope associated with an Apple Git installation on macOS. This is a
   file usually located under `/Library` or `/Applications`.
   
   This is done by using `GIT_CONFIG_NOSYSTEM`, which suppresses both
   the system scope and this separate "unknown" scope, instead of by
   settng `GIT_CONFIG_SYSTEM` to a path like `/dev/null`. The latter
   approach continues to be used to omit global scope config via
   `GIT_CONFIG_GLOBAL` (as `git` recognized no `GIT_CONFIG_NOGLOBAL`).
 - Omit system/global config in fixtures regardless of contents
   This uses the null device, `/dev/null` on Unix-like systems and
   `NUL` on Windows, as the value of `GIT_CONFIG_SYSTEM` and
   `GIT_CONFIG_GLOBAL` when `gix-testtols` runs test fixture shell
   scripts.
   
   `/dev/null` is explicitly recommended for this purpose, when
   setting those environment variables for the purpose of preventing
   configuration files from being read, in the Git documentation:
   
   - https://git-scm.com/docs/git#Documentation/git.txt-codeGITCONFIGGLOBALcode
   
   On Windows, `NUL` is an analogue of `/dev/null`. Even in the
   unusual scenario that a `\\?\` prefixed UNC path is used to create
   an actual file named `NUL` in the directory the fixture script
   operates in, the relative path `NUL` still resolves to the null
   device and not to that file.
   
   The previous behavior was to use a value of `:` on Unix-like
   systems or `-` on Windows. But these were really just unusual but
   valid paths, such that files of those names could exist in any
   location. `git` furthermore treats them as paths: a `:` is not
   special in these environment variables because they hold a single
   path rather than a list of paths, and a `-` is not special (for
   example, it does not specify stdin) because it appears in an
   environment variable rather than a command-line argument.
   
   While `:` and `-` are unusual filenames, this code is used in
   testing, including of edge cases where unusual files may be used.
   So this change may make the test tools slightly more robust.
 - Let `gix_testtools::Env` undo multiple changes to the same var
   Previously, an `Env` instance would restore the original state on
   drop if no more than one modification was made to any one variable
   through it, but would restore an intermediate state if the same
   variable was ever set multiple times, unset multiple times, or both
   set and unset in any order.
   
   The state it would restore for each variable was its state
   immediately before the most recent modification (through the `Env`
   instance) that affected it, rather than its original state before
   the first time it was modified through that `Env` instance.
   
   This fixes that by undoing the changes in the opposite of the order
   they were made.
 - assure archives are unique if their generator-scripts are called with arguments.
   Previously there was a race condition that would cause archives to be created either with
   or without arguments, depending on which test was run first.
   
   After its creation, they wouldn't be looked at again as on disk they would already be available
   in their usable form.

### Other

 - Fix description of `gix_testtools::Env::unset`
   The `unset` method inadvertently had the same docstring as `set`,
   even though this was not correct for `unset`. This fixes that, and
   also rewords the `Env` docstring to better account for the ability
   to unset.

### New Features (BREAKING)

 - on Windows, also instruct msys to create real symlinks
   This will only reliably work on with developer setups, but that
   seems fair to assume.
   If this causes problems, it's fine to make it opt-in as well.

### Bug Fixes (BREAKING)

 - don't panic, instead provide an error when fixture script fails.
   This makes introspection easier, even though we still have to print to
   script output to stderr in order to make it legible.

### Commit Statistics

 - 104 commits contributed to the release over the course of 296 calendar days.
 - 307 days passed between releases.
 - 22 commits were understood as [conventional](https://www.conventionalcommits.org).
 - 2 unique issues were worked on: #1440, #1443

### Thanks Clippy

[Clippy](https://github.com/rust-lang/rust-clippy) helped 6 times to make code idiomatic. 

### Commit Details

 * **#1440**
    - Assure archives are unique if their generator-scripts are called with arguments. (8a0fedb)
 * **#1443**
    - On Windows, also instruct msys to create real symlinks (0899c2e)
 * **Uncategorized**
    - Prepare new testtools release (070f5f6)
    - Merge pull request #1935 from pierrechevalier83/fix_1923 (3b1bef7)
    - J fmt (c3c6504)
    - Thanks clippy (6f009d7)
    - Merge pull request #1968 from GitoxideLabs/dependabot/cargo/cargo-bd18780e40 (46227e6)
    - Bump the cargo group with 40 updates (06bf1e1)
    - Merge pull request #1825 from DianaNites/diananites-reftable (edb449c)
    - Don't panic, instead provide an error when fixture script fails. (692caeb)
    - Merge pull request #1949 from GitoxideLabs/dependabot/cargo/cargo-6893e2988a (b5e9059)
    - Bump the cargo group with 21 updates (68e6b2e)
    - Merge pull request #1895 from EliahKagan/run-ci/s390x (705b86d)
    - Move `env` subcommand to `internal-tools` (809fb2f)
    - Test `gix_testtools::umask()` on Android targets (c19bf1d)
    - Add `env` testtools subcommand to show the environment (8d596b4)
    - Show unexpected stderr in `umask` panic message (07022ee)
    - Merge pull request #1864 from EliahKagan/run-ci/bash-program (97d50a3)
    - Add `jtt bash-program` (`jtt bp`) to show `bash_program()` (720a23f)
    - Document `gix_testtools::bash_program()` and make it public (47234b6)
    - Look for bash in `(git root)/bin`, then `(git root)/usr/bin` (0b45baf)
    - Look for bash in `(git root)/usr/bin`, not `(git root)/bin` (73d30d7)
    - Prefer `/` over `\` in `bash.exe` path (for fixtures) (ba76201)
    - Merge pull request #1854 from GitoxideLabs/montly-report (16a248b)
    - Thanks clippy (8e96ed3)
    - Merge pull request #1822 from epage/w7 (11ac79c)
    - Upgrade to Winnow 0.7 (fdc57e7)
    - Upgrade to Winnow 0.6.26 (783c4e6)
    - Merge pull request #1815 from EliahKagan/quadratic (ffb73b5)
    - Comment forthcoming dependency changes for gix-testtools (6990f76)
    - Merge pull request #1764 from EliahKagan/finalize-entry (12f672f)
    - Refactor (4d5e656)
    - Fix an MSRV incompatibility (61174e5)
    - Add `gix_testtools::umask`, safe but only meant for tests (8e7fb99)
    - Merge pull request #1752 from GitoxideLabs/git-shell (1ca480a)
    - Make a note to use `env::git_login_shell()` in testtools when available. (3aff1e5)
    - Thanks clippy (9193b05)
    - Merge pull request #1733 from GitoxideLabs/fix-testools (df5cead)
    - Fix check to detect `git-lfs` managed files that weren't checked out. (93cb5ba)
    - Merge pull request #1705 from GitoxideLabs/merge (520c832)
    - Create a more local lock when creating writable fixtures. (8b694a6)
    - Merge pull request #1712 from EliahKagan/run-ci/git-bash (fadf106)
    - Fix an ambiguous `expect` message (1f6a866)
    - Run test fixture scripts on Windows with Git Bash (fe3f2d1)
    - Refine `EXEC_PATH` validation in `spawn_git_daemon` (479c06b)
    - Run `cargo fmt` (da03932)
    - Use consistent `git` command name in gix-testtools (e30c070)
    - Rename `parse_gix_version` to `parse_git_version` (01737ad)
    - Merge pull request #1687 from EliahKagan/run-ci/32bit (aeaebec)
    - Add `size_ok` for asserting size is not too big (77c3c59)
    - Merge pull request #1612 from Byron/merge (37c1e4c)
    - Thanks clippy (af03832)
    - Merge pull request #1606 from EliahKagan/fixture-timeout (8c9e827)
    - Double the fixture lock timeout (39323c3)
    - Merge pull request #1594 from EliahKagan/comments (ab8880f)
    - Copyedit `configure_command` comment (56dbcd5)
    - Merge pull request #1592 from EliahKagan/tools-cfgcmd (5e783de)
    - Note that how we set `MSYS` ignores `env`/`env_remove` calls (4a25ef5)
    - Use more compact notation (0e1e6a9)
    - Broaden `args` param of `configure_command` (c202084)
    - Merge pull request #1590 from EliahKagan/run-ci/check-clean (4f92140)
    - Merge pull request #1591 from EliahKagan/run-ci/deps-via-worktree (c485a2b)
    - Thanks clippy (94c6d70)
    - Recognize `GIX_TEST_CREATE_ARCHIVES_EVEN_ON_CI` (03d5a68)
    - Rename create_archive_if_{not_on_ci -> we_should} (8b51b3a)
    - Copyedit `create_archive_if_not_on_ci` comments (6963b37)
    - In gix-testtools use `ignore` and `index` via `gix_worktree` (f7f24e5)
    - Merge pull request #1581 from EliahKagan/fixture-env (4044ffb)
    - Merge pull request #1580 from EliahKagan/msys (d00235a)
    - Unset other env vars related to `GIT_DIR` for fixtures (9d4dd12)
    - Remove `configure_command_msys*` tests at least for now (c38d9b9)
    - Append to preexisting `MSYS` env var even if ill-formed (8dc5d7a)
    - Start testing how the MSYS env var is customized (fbd4908)
    - Merge pull request #1571 from EliahKagan/fixture-config (0e2f831)
    - Run `cargo fmt` (91e065c)
    - Omit other high-scoped config in fixtures (a879d22)
    - Test that env for fixture scripts has only command-scope config (d576b32)
    - Merge pull request #1570 from EliahKagan/tools-nulldev (6f128dd)
    - Minor refactors (50fcd7e)
    - Don't assert that `tempfile::TempDir` cleans up (15bb2e3)
    - Avoid `File::create_new` for compatibility with project MSRV (40ac226)
    - Thanks clippy (2d7abaf)
    - Omit system/global config in fixtures regardless of contents (3cf9fc1)
    - Verify that we really write the strangely named test files (d7dca27)
    - Test on Windows with an actual file called `NUL` (f71d596)
    - Refactor the test for readability (7186eed)
    - Fix assertion messages and expected exit status (a2dc5d8)
    - Test that the system/global scopes are really cleared (d5b61df)
    - Start testing that we clear system/global scopes for fixtures (85c5e2f)
    - Merge pull request #1560 from EliahKagan/run-ci/env-lifo (2972ea8)
    - Merge pull request #1557 from Byron/merge-base (649f588)
    - Move new tests up into a `tests` subdirectory (555164f)
    - Let `gix_testtools::Env` undo multiple changes to the same var (581957e)
    - Add tests for `gix_testtools::Env` (505151c)
    - Fix description of `gix_testtools::Env::unset` (3b17305)
    - Allow empty-docs (beba720)
    - Merge branch 'global-lints' (37ba461)
    - Workspace Clippy lint management (2e0ce50)
    - Merge pull request #1546 from nyurik/semilocons (f992fb7)
    - Add missing semicolons (ec69c88)
    - Update manifests (by cargo-smart-release) (0470df3)
    - Merge branch 'fix-windows-tests' (c2753b8)
    - Fix gix-archive tests for when symlinks are allowed (93e088a)
    - Merge branch 'fix-1440' (f87322e)

### Commit Statistics

 - 1 commit contributed to the release.
 - 0 commits were understood as [conventional](https://www.conventionalcommits.org).
 - 0 issues like '(#ID)' were seen in commit messages

### Commit Details

 * **Uncategorized**
    - Bump all prior pratch levels to majors (5f7f805)

### Commit Statistics

 - 1 commit contributed to the release.
 - 0 commits were understood as [conventional](https://www.conventionalcommits.org).
 - 0 issues like '(#ID)' were seen in commit messages

### Commit Details

 * **Uncategorized**
    - Bump all prior pratch levels to majors (5f7f805)

### Commit Statistics

 - 1 commit contributed to the release.
 - 0 commits were understood as [conventional](https://www.conventionalcommits.org).
 - 0 issues like '(#ID)' were seen in commit messages

### Commit Details

 * **Uncategorized**
    - Bump all prior pratch levels to majors (5f7f805)

### Commit Statistics

 - 1 commit contributed to the release.
 - 0 commits were understood as [conventional](https://www.conventionalcommits.org).
 - 0 issues like '(#ID)' were seen in commit messages

### Commit Details

 * **Uncategorized**
    - Bump all prior pratch levels to majors (5f7f805)

### Commit Statistics

 - 1 commit contributed to the release.
 - 0 commits were understood as [conventional](https://www.conventionalcommits.org).
 - 0 issues like '(#ID)' were seen in commit messages

### Commit Details

 * **Uncategorized**
    - Bump all prior pratch levels to majors (5f7f805)

### Commit Statistics

 - 1 commit contributed to the release.
 - 0 commits were understood as [conventional](https://www.conventionalcommits.org).
 - 0 issues like '(#ID)' were seen in commit messages

### Commit Details

 * **Uncategorized**
    - Bump all prior pratch levels to majors (5f7f805)

### Commit Statistics

 - 1 commit contributed to the release.
 - 0 commits were understood as [conventional](https://www.conventionalcommits.org).
 - 0 issues like '(#ID)' were seen in commit messages

### Commit Details

 * **Uncategorized**
    - Bump all prior pratch levels to majors (5f7f805)