gix-testtools v0.16.0

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 .gitignored 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.
• 2 unique issues were worked on: #1440, #1443

Thanks Clippy

Clippy helped 6 times to make code idiomatic.

Commit Details

view 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)