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.
• 0 issues like '(#ID)' were seen in commit messages

Commit Details

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 b...

This is a bit empty as release notes got lost in a series of accidents, but it looks like it wouldn't have been too informative anyway.

Commit Statistics

• 1 commit contributed to the release.
• 0 commits were understood as conventional.
• 0 issues like '(#ID)' were seen in commit messages

Commit Details

Commit Statistics

• 1 commit contributed to the release.
• 0 commits were understood as conventional.
• 0 issues like '(#ID)' were seen in commit messages

Commit Details

Commit Statistics

• 1 commit contributed to the release.
• 0 commits were understood as conventional.
• 0 issues like '(#ID)' were seen in commit messages

Commit Details

Commit Statistics

• 1 commit contributed to the release.
• 0 commits were understood as conventional.
• 0 issues like '(#ID)' were seen in commit messages

Commit Details

Commit Statistics

• 1 commit contributed to the release.
• 0 commits were understood as conventional.
• 0 issues like '(#ID)' were seen in commit messages

Commit Details

Commit Statistics

• 1 commit contributed to the release.
• 0 commits were understood as conventional.
• 0 issues like '(#ID)' were seen in commit messages

Commit Details

Commit Statistics

• 1 commit contributed to the release.
• 0 commits were understood as conventional.
• 0 issues like '(#ID)' were seen in commit messages

Commit Details