Changelog: https://github.com/git/git/blob/v2.55.0/Documentation/RelNotes/2.55.0.adoc
Packaging changes:
- disable the t1517 test, since it's clearly fragile when run against an
installed Git package
- change Rust argument handling to match the upstream project's switch
from Rust being opt-in to opt-out
- explicitly set `debug` to an empty string in the installCheck flags,
to avoid the test suite printing debug output and triggering new
failures in the test harness
- remove an osx/rust patch that has been fixed upstream
The existing update script is clearly broken, since it's trying to
update the package definition in a file that hasn't existed for a long
time. Replace it with a tested invocation of `nix-update`.
The problem was that Cargo didn't have a way to find a linker for the
build platform which is required to link the build script. So, when
cross compiling we add in the standard build -> build compiler so that
it can compile the build script.
This fix was taken from the ideas of @magicquark and @nwf in
https://github.com/NixOS/nixpkgs/issues/523378.
Fixes#523378
For easier overriding with `git.override` or `git.overrideAttrs`,
determine whether configuration related to running the install checks is
present based on whether the install checks are actually being run, not
on the function argument which may not be the same.
t7703-repack-geometric tests 11 and 12, added in upstream 6ce9d558ce
(first shipped in 2.53.0), assert that a no-op repack leaves the pack
directory untouched by comparing full `ls -l` output. The leading
`total N` block-count header is not stable on copy-on-write or
compressing filesystems such as ZFS, where delayed allocation can change
the reported value between two back-to-back invocations even though the
files are byte-identical. This makes gitMinimal's installCheck fail
nondeterministically on ZFS-backed builders.
Apply the upstream-submitted patch that strips that header before
comparing. Verified with 20 consecutive runs on ZFS.
Fixes#498789.
Link: https://lore.kernel.org/git/20260504101429.340123-1-joerg@thalheim.io/
Future versions of Git are going to require Rust, and Rust was added as
a "test balloon" in v2.52.0 so downstream distributions -- such as
ourselves -- can start ironing out the problems. Support for this was
added as an option in #476300 / 0869356f40 (git: add rust opt-in,
2025-12-31), but the default packaging wasn't changed at that time.
To get as much exposure for that as possible, default to enabling
compilation with Rust where possible. There are two exceptions that
don't currently work:
- gitMinimal, which is currently required to build Rust, so cannot
depend on it without creating a circular dependency. Fixing that
bootstrap issue is a future project.
- Platforms that don't have any support for Rust. There's not much we
can do about those!
0869356f40 (git: add rust opt-in, 2025-12-31) added rustc and cargo to
`buildInputs`, but they are needed only at build time, not at run-time.
This means they belong in `nativeBuildInputs`.
With v2.52.0, git now includes the option to use a rust implementation
of some core logic [1]. Using rust/cargo as part of the build process is
currently still optional, though expected to become mandatory in Git
v3.0.
In preparation, introduce cargo/rustc into the Git package build. This
is disabled by default and enabled via a new `rustSupport` argument to
mirror the fact that this is opt-in in Git itself.
[1]: lore.kernel.org/git/20251002-b4-pks-rust-breaking-change-v8-0-3a89fd5b1ce7@pks.im/
