[PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Patrick Steinhardt]

Hi,

this small patch series introduces Rust into the core of Git. This patch
series is designed as a test balloon, similar to how we introduced test
balloons for C99 features in the past. The goal is threefold:

  - Give us some time to experiment with Rust and introduce proper build
    infrastructure.

  - Give distributors time to ease into the new toolchain requirements.
    Introducing Rust is impossible for some platforms and hard for
    others.

  - Announce that Git 3.0 will make Rust a mandatory part of our build
    infrastructure.

The test balloon itself is quite uninteresting: I've chosen to convert
the "varint.c" subsystem, mostly because it is trivial and does not have
any dependencies. But it does allow us to verify that C to Rust interop
works as expected, and to play around with tooling. All tests pass with
the "varint.rs" implementation.

For now, the series only contains support for Meson. If we agree to go
down this route I'll also introduce support for Rust into our Makefiles
at a later point in time.

Furthermore missing is additional tooling:

  - At least one CI job to verify that Rust builds and works as
    expected.

  - Tooling and CI jobs to ensure that we have consistent formatting via
    `cargo format`.

And probably lots more. As said, the entire goal is for us to have an
easy playground that we can experiment on and develop the infrastructure
incrementally without yet having to commit to anything.

I'm mostly splitting out the topic of introducing Rust from the larger
series that introduce it into xdiff so that we can focus more on the
actual process of introducing Rust into Git and less on the potential
features that we want to build on top of it.

Thanks!

Patrick

---
Patrick Steinhardt (3):
      meson: add infrastructure to build internal Rust library
      rust: implement a test balloon via the "varint" subsystem
      BreakingChanges: announce Rust becoming mandatory

 Documentation/BreakingChanges.adoc | 20 +++++++++
 meson.build                        | 21 ++++++++-
 meson_options.txt                  |  2 +
 src/lib.rs                         |  1 +
 src/meson.build                    | 13 ++++++
 src/varint.rs                      | 92 ++++++++++++++++++++++++++++++++++++++
 6 files changed, 147 insertions(+), 2 deletions(-)


---
base-commit: 2462961280690837670d997bde64bd4ebf8ae66d
change-id: 20250904-b4-pks-rust-breaking-change-7167d9d3e37d

[PATCH RFC 1/3] meson: add infrastructure to build internal Rust library

[Patrick Steinhardt]

Add the infrastructure into Meson to build an internal Rust library.
Building the Rust parts of Git are for now entirely optional, as they
are mostly intended as a test balloon for both Git developers, but also
for distributors of Git. So for now, they may contain:

  - New features that are not mission critical to Git and that users can
    easily live without.

  - Alternative implementations of small subsystems.

If these test balloons are successful, we will eventually make Rust a
mandatory dependency for our build process in Git 3.0.

The availability of a Rust toolchain will be auto-detected by Meson at
setup time. This behaviour can be tweaked via the `-Drust=` feature
toggle.

Next to the linkable Rust library, also wire up tests that can be
executed via `meson test`. This allows us to use the native unit testing
capabilities of Rust.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 meson.build       | 16 +++++++++++++++-
 meson_options.txt |  2 ++
 src/lib.rs        |  0
 src/meson.build   | 12 ++++++++++++
 4 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index e8ec0eca165..1c0e98bbc14 100644
--- a/meson.build
+++ b/meson.build
@@ -1702,8 +1702,21 @@ version_def_h = custom_target(
 )
 libgit_sources += version_def_h
 
+libgit_libraries = [ ]
+
+if meson.version().version_compare('>=1.9.0')
+  rust_available = add_languages('rust', native: false, required: get_option('rust'))
+else
+  rust_available = false
+endif
+rust_option = get_option('rust').disable_auto_if(not rust_available)
+
+if rust_option.allowed() and meson.version().version_compare('>=1.9.0')
+  subdir('src')
+endif
+
 libgit = declare_dependency(
-  link_with: static_library('git',
+  link_with: libgit_libraries + static_library('git',
     sources: libgit_sources,
     c_args: libgit_c_args + [
       '-DGIT_VERSION_H="' + version_def_h.full_path() + '"',
@@ -2239,6 +2252,7 @@ summary({
   'pcre2': pcre2,
   'perl': perl_features_enabled,
   'python': target_python.found(),
+  'rust': rust_option.allowed(),
 }, section: 'Auto-detected features', bool_yn: true)
 
 summary({
diff --git a/meson_options.txt b/meson_options.txt
index 1668f260a18..143dee9237c 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -71,6 +71,8 @@ option('zlib_backend', type: 'combo', choices: ['auto', 'zlib', 'zlib-ng'], valu
 # Build tweaks.
 option('breaking_changes', type: 'boolean', value: false,
   description: 'Enable upcoming breaking changes.')
+option('rust', type: 'feature', value: 'auto',
+  description: 'Enable building with Rust.')
 option('macos_use_homebrew_gettext', type: 'boolean', value: true,
   description: 'Use gettext from Homebrew instead of the slightly-broken system-provided one.')
 
diff --git a/src/lib.rs b/src/lib.rs
new file mode 100644
index 00000000000..e69de29bb2d
diff --git a/src/meson.build b/src/meson.build
new file mode 100644
index 00000000000..2bd2045a8ab
--- /dev/null
+++ b/src/meson.build
@@ -0,0 +1,12 @@
+rustmod = import('rust')
+
+libgit_rs = static_library('git_rs',
+  sources: [
+    'lib.rs',
+  ],
+  rust_abi: 'c',
+)
+
+rustmod.test('git-rs', libgit_rs)
+
+libgit_libraries += libgit_rs

-- 
2.51.0.417.g1ba7204a04.dirty

Re: [PATCH RFC 1/3] meson: add infrastructure to build internal Rust library

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

> Add the infrastructure into Meson to build an internal Rust library.

I am a bit surprised that Meson needs to learn Rust now.  How have
you been dealing with contrib/libgit-{sys,rs}?

> Building the Rust parts of Git are for now entirely optional, as they
> are mostly intended as a test balloon for both Git developers, but also
> for distributors of Git. So for now, they may contain:
>
>   - New features that are not mission critical to Git and that users can
>     easily live without.
>
>   - Alternative implementations of small subsystems.
>
> If these test balloons are successful, we will eventually make Rust a
> mandatory dependency for our build process in Git 3.0.
>
> The availability of a Rust toolchain will be auto-detected by Meson at
> setup time. This behaviour can be tweaked via the `-Drust=` feature
> toggle.
>
> Next to the linkable Rust library, also wire up tests that can be
> executed via `meson test`. This allows us to use the native unit testing
> capabilities of Rust.

OK.

> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
>  meson.build       | 16 +++++++++++++++-
>  meson_options.txt |  2 ++
>  src/lib.rs        |  0
>  src/meson.build   | 12 ++++++++++++
>  4 files changed, 29 insertions(+), 1 deletion(-)

Re: [PATCH RFC 1/3] meson: add infrastructure to build internal Rust library

[Patrick Steinhardt]

On Thu, Sep 04, 2025 at 11:50:14AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > Add the infrastructure into Meson to build an internal Rust library.
> 
> I am a bit surprised that Meson needs to learn Rust now.  How have
> you been dealing with contrib/libgit-{sys,rs}?

Neither of these are wired up in Meson right now. There aren't really
any users, they don't expose a lot of functionality, and both of these
libraries aren't actively developed right now. So I didn't yet have any
motivation to wire them up just yet.

I also think we should reevaluate these once we officially support Rust
in core Git. It feels way more reasonable to design our new core Rust
code in a way that it can be pulled in as a crate right from the start.
Maybe it's just a matter of moving those libraries out of "contrib/" and
into our core Rust code?

Patrick

Re: [PATCH RFC 1/3] meson: add infrastructure to build internal Rust library

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2285 bytes --]

On 2025-09-04 at 14:26:43, Patrick Steinhardt wrote:
> Add the infrastructure into Meson to build an internal Rust library.
> Building the Rust parts of Git are for now entirely optional, as they
> are mostly intended as a test balloon for both Git developers, but also
> for distributors of Git. So for now, they may contain:
> 
>   - New features that are not mission critical to Git and that users can
>     easily live without.
> 
>   - Alternative implementations of small subsystems.
> 
> If these test balloons are successful, we will eventually make Rust a
> mandatory dependency for our build process in Git 3.0.
> 
> The availability of a Rust toolchain will be auto-detected by Meson at
> setup time. This behaviour can be tweaked via the `-Drust=` feature
> toggle.
> 
> Next to the linkable Rust library, also wire up tests that can be
> executed via `meson test`. This allows us to use the native unit testing
> capabilities of Rust.

I don't see any changes in this series that wire up the Makefile to do
the same thing.  Lots of people use the Makefile, or things based on the
Makefile like the autotools, so we'll want to make sure this
autodetection works there.  For instance, I build with the Makefile, we
build with it at work, and Debian builds only with the Makefile.

We also probably need to test this configuration in CI as well.

> diff --git a/meson.build b/meson.build
> index e8ec0eca165..1c0e98bbc14 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1702,8 +1702,21 @@ version_def_h = custom_target(
>  )
>  libgit_sources += version_def_h
>  
> +libgit_libraries = [ ]
> +
> +if meson.version().version_compare('>=1.9.0')

I think we need a different approach.  Debian 13, which was just
released, only supports meson 1.7.0, and you have to use testing or
unstable to get 1.9.0.  There are no versions of Ubuntu, released or
not, that support meson 1.9.0.

If we require this version, practically nobody is going to actually test
this case.

Our platform support policy implies that we should be requiring nothing
greater than meson 0.56.2, which is available in Debian 11 and has LTS
support until 2026-08-31.  Ubuntu 22.04 offers 0.61.2.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [PATCH RFC 1/3] meson: add infrastructure to build internal Rust library

[Junio C Hamano]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> I don't see any changes in this series that wire up the Makefile to do
> the same thing.  Lots of people use the Makefile, or things based on the
> Makefile like the autotools, so we'll want to make sure this
> autodetection works there.  For instance, I build with the Makefile, we
> build with it at work, and Debian builds only with the Makefile.

Yeah, that is a bit disappointing, but I was not surprised, as that
is what the cover letter promised to give us ;-)

> We also probably need to test this configuration in CI as well.
>
>> diff --git a/meson.build b/meson.build
>> index e8ec0eca165..1c0e98bbc14 100644
>> --- a/meson.build
>> +++ b/meson.build
>> @@ -1702,8 +1702,21 @@ version_def_h = custom_target(
>>  )
>>  libgit_sources += version_def_h
>>  
>> +libgit_libraries = [ ]
>> +
>> +if meson.version().version_compare('>=1.9.0')
>
> I think we need a different approach.  Debian 13, which was just
> released, only supports meson 1.7.0, and you have to use testing or
> unstable to get 1.9.0.  There are no versions of Ubuntu, released or
> not, that support meson 1.9.0.
>
> If we require this version, practically nobody is going to actually test
> this case.
>
> Our platform support policy implies that we should be requiring nothing
> greater than meson 0.56.2, which is available in Debian 11 and has LTS
> support until 2026-08-31.  Ubuntu 22.04 offers 0.61.2.

Thanks for reminding all of us.

Re: [PATCH RFC 1/3] meson: add infrastructure to build internal Rust library

[Patrick Steinhardt]

On Thu, Sep 04, 2025 at 03:46:53PM -0700, Junio C Hamano wrote:
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> 
> > I don't see any changes in this series that wire up the Makefile to do
> > the same thing.  Lots of people use the Makefile, or things based on the
> > Makefile like the autotools, so we'll want to make sure this
> > autodetection works there.  For instance, I build with the Makefile, we
> > build with it at work, and Debian builds only with the Makefile.
> 
> Yeah, that is a bit disappointing, but I was not surprised, as that
> is what the cover letter promised to give us ;-)

Yup. This series is currently RFC, so I was first seeking feedback on
it and encourage discussions on the general direction. I mostly did it
for Meson only because it was easier, but if we agree on the direction
of this patch series I'll implement it in our Makefile in subsequent
versions, as well.

> > We also probably need to test this configuration in CI as well.
> >
> >> diff --git a/meson.build b/meson.build
> >> index e8ec0eca165..1c0e98bbc14 100644
> >> --- a/meson.build
> >> +++ b/meson.build
> >> @@ -1702,8 +1702,21 @@ version_def_h = custom_target(
> >>  )
> >>  libgit_sources += version_def_h
> >>  
> >> +libgit_libraries = [ ]
> >> +
> >> +if meson.version().version_compare('>=1.9.0')
> >
> > I think we need a different approach.  Debian 13, which was just
> > released, only supports meson 1.7.0, and you have to use testing or
> > unstable to get 1.9.0.  There are no versions of Ubuntu, released or
> > not, that support meson 1.9.0.
> >
> > If we require this version, practically nobody is going to actually test
> > this case.
> >
> > Our platform support policy implies that we should be requiring nothing
> > greater than meson 0.56.2, which is available in Debian 11 and has LTS
> > support until 2026-08-31.  Ubuntu 22.04 offers 0.61.2.
> 
> Thanks for reminding all of us.

Eli mentioned that this version check shouldn't even be needed, so I can
probably drop it altogether. Will have a look.

Patrick

Re: [PATCH RFC 1/3] meson: add infrastructure to build internal Rust library

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 1126 bytes --]

On 9/4/25 6:06 PM, brian m. carlson wrote:

>> +if meson.version().version_compare('>=1.9.0')
> 
> I think we need a different approach.  Debian 13, which was just
> released, only supports meson 1.7.0, and you have to use testing or
> unstable to get 1.9.0.  There are no versions of Ubuntu, released or
> not, that support meson 1.9.0.
> 
> If we require this version, practically nobody is going to actually test
> this case.
> 
> Our platform support policy implies that we should be requiring nothing
> greater than meson 0.56.2, which is available in Debian 11 and has LTS
> support until 2026-08-31.  Ubuntu 22.04 offers 0.61.2.


Hmm. Patrick -- do you mind documenting why you decided to use this
version guard at all? Off the top of my head I'm not sure why you'd need
this.

In src/meson.build,

+libgit_rs = static_library('git_rs',
+  sources: [
+    'lib.rs',
+  ],
+  rust_abi: 'c',
+)



rust_abi is new in meson 1.3.0, but it's just a rename for clarity of
rust_crate_type, available since meson 0.42.0, so please use the
backwards-compatible name...


-- 
Eli Schwartz

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [PATCH RFC 1/3] meson: add infrastructure to build internal Rust library

[Patrick Steinhardt]

On Thu, Sep 04, 2025 at 09:16:03PM -0400, Eli Schwartz wrote:
> On 9/4/25 6:06 PM, brian m. carlson wrote:
> 
> >> +if meson.version().version_compare('>=1.9.0')
> > 
> > I think we need a different approach.  Debian 13, which was just
> > released, only supports meson 1.7.0, and you have to use testing or
> > unstable to get 1.9.0.  There are no versions of Ubuntu, released or
> > not, that support meson 1.9.0.
> > 
> > If we require this version, practically nobody is going to actually test
> > this case.
> > 
> > Our platform support policy implies that we should be requiring nothing
> > greater than meson 0.56.2, which is available in Debian 11 and has LTS
> > support until 2026-08-31.  Ubuntu 22.04 offers 0.61.2.
> 
> 
> Hmm. Patrick -- do you mind documenting why you decided to use this
> version guard at all? Off the top of my head I'm not sure why you'd need
> this.
> 
> In src/meson.build,
> 
> +libgit_rs = static_library('git_rs',
> +  sources: [
> +    'lib.rs',
> +  ],
> +  rust_abi: 'c',
> +)
> 
> 
> 
> rust_abi is new in meson 1.3.0, but it's just a rename for clarity of
> rust_crate_type, available since meson 0.42.0, so please use the
> backwards-compatible name...

Oh. I think I misunderstood the following sentence [1]:

    (Since 1.9.0) Rust supports mixed targets, but only supports using
    rustc as the linker for such targets. If you need to use a non-Rust
    linker, or support Meson < 1.9.0, see below.

I thought that only with Meson 1.9 you could link Rust libraries with C
libraries. But I guess this rather means that you can now have a single
target that has both '.c' and '.rs' sources?

In any way, thanks for the hint, will drop.

Patrick

[1]: https://mesonbuild.com/Rust.html#mixing-rust-and-nonrust-sources

Re: [PATCH RFC 1/3] meson: add infrastructure to build internal Rust library

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 1814 bytes --]

On 9/5/25 3:50 AM, Patrick Steinhardt wrote:
> On Thu, Sep 04, 2025 at 09:16:03PM -0400, Eli Schwartz wrote:
>> Hmm. Patrick -- do you mind documenting why you decided to use this
>> version guard at all? Off the top of my head I'm not sure why you'd need
>> this.
>>
>> In src/meson.build,
>>
>> +libgit_rs = static_library('git_rs',
>> +  sources: [
>> +    'lib.rs',
>> +  ],
>> +  rust_abi: 'c',
>> +)
>>
>>
>>
>> rust_abi is new in meson 1.3.0, but it's just a rename for clarity of
>> rust_crate_type, available since meson 0.42.0, so please use the
>> backwards-compatible name...
> 
> Oh. I think I misunderstood the following sentence [1]:
> 
>     (Since 1.9.0) Rust supports mixed targets, but only supports using
>     rustc as the linker for such targets. If you need to use a non-Rust
>     linker, or support Meson < 1.9.0, see below.
> 
> I thought that only with Meson 1.9 you could link Rust libraries with C
> libraries. But I guess this rather means that you can now have a single
> target that has both '.c' and '.rs' sources?
> 
> In any way, thanks for the hint, will drop.
> 
> Patrick
> 
> [1]: https://mesonbuild.com/Rust.html#mixing-rust-and-nonrust-sources


Yes -- a single target is something like a libXXXX.so or a libXXXX.a
file, and there are significant nuances in how a build system backend
needs to run rustc in order to emit the final C interface (or merge into
an executable). Once it is exported to C, though, it is "normal" C code
and anything may link to it freely, even for much older versions of Meson.

The previous (<1.9.0) gold standard for Rust / C interop in Meson, was
the far more well-trodden path of "use libraries, not *.o files" (which
is also more straightforward in cargo, of course ;)).


-- 
Eli Schwartz

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

[PATCH RFC 2/3] rust: implement a test balloon via the "varint" subsystem

[Patrick Steinhardt]

Implement a trivial test balloon for our Rust build infrastructure by
reimplementing the "varint.c" subsystem in Rust. This subsystem is
chosen because it is trivial to convert and because it doesn't have any
dependencies to other components of Git.

If support for Rust is enabled, we stop compiling "varint.c" and instead
compile and use "src/varint.rs".

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 meson.build     |  5 +++-
 src/lib.rs      |  1 +
 src/meson.build |  1 +
 src/varint.rs   | 92 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 98 insertions(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index 1c0e98bbc14..b52a68b0bb6 100644
--- a/meson.build
+++ b/meson.build
@@ -522,7 +522,6 @@ libgit_sources = [
   'usage.c',
   'userdiff.c',
   'utf8.c',
-  'varint.c',
   'version.c',
   'versioncmp.c',
   'walker.c',
@@ -1713,6 +1712,10 @@ rust_option = get_option('rust').disable_auto_if(not rust_available)
 
 if rust_option.allowed() and meson.version().version_compare('>=1.9.0')
   subdir('src')
+else
+  libgit_sources += [
+    'varint.c',
+  ]
 endif
 
 libgit = declare_dependency(
diff --git a/src/lib.rs b/src/lib.rs
index e69de29bb2d..9da70d8b57d 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -0,0 +1 @@
+pub mod varint;
diff --git a/src/meson.build b/src/meson.build
index 2bd2045a8ab..b3164fb5ed4 100644
--- a/src/meson.build
+++ b/src/meson.build
@@ -3,6 +3,7 @@ rustmod = import('rust')
 libgit_rs = static_library('git_rs',
   sources: [
     'lib.rs',
+    'varint.rs',
   ],
   rust_abi: 'c',
 )
diff --git a/src/varint.rs b/src/varint.rs
new file mode 100644
index 00000000000..3d41760a555
--- /dev/null
+++ b/src/varint.rs
@@ -0,0 +1,92 @@
+use std::os::raw::c_int;
+use std::os::raw::c_uchar;
+
+#[no_mangle]
+pub unsafe extern "C" fn decode_varint(bufp: *mut *const c_uchar) -> usize {
+    let mut buf = *bufp;
+    let mut c = *buf;
+    let mut val = usize::from(c & 127);
+
+    buf = buf.add(1);
+
+    while (c & 128) != 0 {
+        val += 1;
+        if val == 0 || val.leading_zeros() < 7 {
+            return 0; // overflow
+        }
+
+        c = *buf;
+        buf = buf.add(1);
+
+        val = (val << 7) + usize::from(c & 127);
+    }
+
+    *bufp = buf;
+    val
+}
+
+#[no_mangle]
+pub unsafe extern "C" fn encode_varint(value: usize, buf: *mut c_uchar) -> c_int {
+    let mut varint: [u8; 16] = [0; 16];
+    let mut pos = varint.len() - 1;
+
+    varint[pos] = (value & 127) as u8;
+
+    let mut value = value >> 7;
+    while value != 0 {
+        pos -= 1;
+        value -= 1;
+        varint[pos] = 128 | (value & 127) as u8;
+        value >>= 7;
+    }
+
+    if !buf.is_null() {
+        std::ptr::copy_nonoverlapping(varint.as_ptr().add(pos), buf, varint.len() - pos);
+    }
+
+    (varint.len() - pos) as c_int
+}
+
+#[cfg(test)]
+mod tests {
+    use super::*;
+
+    #[test]
+    fn test_decode_varint() {
+        unsafe {
+            assert_eq!(decode_varint(&mut [0x00].as_slice().as_ptr()), 0);
+            assert_eq!(decode_varint(&mut [0x01].as_slice().as_ptr()), 1);
+            assert_eq!(decode_varint(&mut [0x7f].as_slice().as_ptr()), 127);
+            assert_eq!(decode_varint(&mut [0x80, 0x00].as_slice().as_ptr()), 128);
+            assert_eq!(decode_varint(&mut [0x80, 0x01].as_slice().as_ptr()), 129);
+            assert_eq!(decode_varint(&mut [0x80, 0x7f].as_slice().as_ptr()), 255);
+        }
+    }
+
+    #[test]
+    fn test_encode_varint() {
+        unsafe {
+            let mut varint: [u8; 16] = [0; 16];
+
+            assert_eq!(encode_varint(0, std::ptr::null_mut()), 1);
+
+            assert_eq!(encode_varint(0, varint.as_mut_slice().as_mut_ptr()), 1);
+            assert_eq!(varint, [0; 16]);
+
+            assert_eq!(encode_varint(10, varint.as_mut_slice().as_mut_ptr()), 1);
+            assert_eq!(varint, [10, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+
+            assert_eq!(encode_varint(127, varint.as_mut_slice().as_mut_ptr()), 1);
+            assert_eq!(varint, [127, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+
+            assert_eq!(encode_varint(128, varint.as_mut_slice().as_mut_ptr()), 2);
+            assert_eq!(varint, [128, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+
+            assert_eq!(encode_varint(129, varint.as_mut_slice().as_mut_ptr()), 2);
+            assert_eq!(varint, [128, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+
+            assert_eq!(encode_varint(255, varint.as_mut_slice().as_mut_ptr()), 2);
+            assert_eq!(varint, [128, 127, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+        }
+    }
+}

-- 
2.51.0.417.g1ba7204a04.dirty

Re: [PATCH RFC 2/3] rust: implement a test balloon via the "varint" subsystem

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 986 bytes --]

On 2025-09-04 at 14:26:44, Patrick Steinhardt wrote:
> diff --git a/meson.build b/meson.build
> index 1c0e98bbc14..b52a68b0bb6 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -522,7 +522,6 @@ libgit_sources = [
>    'usage.c',
>    'userdiff.c',
>    'utf8.c',
> -  'varint.c',
>    'version.c',
>    'versioncmp.c',
>    'walker.c',
> @@ -1713,6 +1712,10 @@ rust_option = get_option('rust').disable_auto_if(not rust_available)
>  
>  if rust_option.allowed() and meson.version().version_compare('>=1.9.0')
>    subdir('src')
> +else
> +  libgit_sources += [
> +    'varint.c',
> +  ]
>  endif

Can we also add a #define constant when building?  For instance, if I'm
writing interop code in Rust, I'll need to be able to do something like
this:

    int do_foobar()
    {
    #ifdef RUST
      /* Call some code */
    #else
      die(_("interoperability not supported"));
    #endif
    }
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [PATCH RFC 2/3] rust: implement a test balloon via the "varint" subsystem

[Patrick Steinhardt]

On Thu, Sep 04, 2025 at 10:37:47PM +0000, brian m. carlson wrote:
> On 2025-09-04 at 14:26:44, Patrick Steinhardt wrote:
> > diff --git a/meson.build b/meson.build
> > index 1c0e98bbc14..b52a68b0bb6 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -1713,6 +1712,10 @@ rust_option = get_option('rust').disable_auto_if(not rust_available)
> >  
> >  if rust_option.allowed() and meson.version().version_compare('>=1.9.0')
> >    subdir('src')
> > +else
> > +  libgit_sources += [
> > +    'varint.c',
> > +  ]
> >  endif
> 
> Can we also add a #define constant when building?  For instance, if I'm
> writing interop code in Rust, I'll need to be able to do something like
> this:
> 
>     int do_foobar()
>     {
>     #ifdef RUST
>       /* Call some code */
>     #else
>       die(_("interoperability not supported"));
>     #endif
>     }

Sure, that sounds like a useful addition. I can add it to the next
version already if you want to, or we can add it at a later point once
it becomes needed.

Patrick

Re: [PATCH RFC 2/3] rust: implement a test balloon via the "varint" subsystem

[Ezekiel Newren]

On Thu, Sep 4, 2025 at 8:27 AM Patrick Steinhardt <ps@pks.im> wrote:
> Implement a trivial test balloon for our Rust build infrastructure by
> reimplementing the "varint.c" subsystem in Rust. This subsystem is
> chosen because it is trivial to convert and because it doesn't have any
> dependencies to other components of Git.

Huh, I thought Meson couldn't run Rust tests. It's refreshing to see
someone else try a different approach on bringing Rust to Git.

There are a few reasons why I picked Cargo instead of Meson to build Rust:
  1. Needs to work with make.
  2. I've heard that using crates in Meson is quite painful.
  3. My understanding is that someday in the distant future Rust will
supplant C in Git.
  3. The IDE RustRover only understands Cargo.

As I mentioned in another thread: The reason why I made Rust a hard
dependency is because it's easier to develop and talk about that way.
I'm open to suggestions on how to make Rust optional.

Re: [PATCH RFC 2/3] rust: implement a test balloon via the "varint" subsystem

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 3881 bytes --]

On 9/4/25 7:39 PM, Ezekiel Newren wrote:
> On Thu, Sep 4, 2025 at 8:27 AM Patrick Steinhardt <ps@pks.im> wrote:
>> Implement a trivial test balloon for our Rust build infrastructure by
>> reimplementing the "varint.c" subsystem in Rust. This subsystem is
>> chosen because it is trivial to convert and because it doesn't have any
>> dependencies to other components of Git.
> 
> Huh, I thought Meson couldn't run Rust tests. It's refreshing to see
> someone else try a different approach on bringing Rust to Git.
> 
> There are a few reasons why I picked Cargo instead of Meson to build Rust:
>   1. Needs to work with make.


If the rust code is defined as a crate, meson can auto-import that crate
via parsing Cargo.toml, so perhaps this can simply be done by creating a

[lib]
crate-type = 'cdylib'

and... importing it as a meson subproject. You'd be able to build it
with cargo build, if you really want to (and the Makefile may have to)
but Meson would not be limited to this.


>   2. I've heard that using crates in Meson is quite painful.


This is specific to build.rs, and it is "difficult" in the sense that
meson cannot compile build.rs into an executable depending on other crates.

Compiling it into an executable depending on other crates is a
prerequisite for running it and parsing its stdout into a list of
defines (rust calls them --cfg) to pass as command line flags for the
real build target.

Meson has official guidance for doing that work in-process by writing a
"plugin" meson.build:

https://mesonbuild.com/Wrap-dependency-system-manual.html#cargo-wraps

build.rs is not something which any crate likes to have anyway. Most
crates therefore don't. And don't have any problem being used by meson.


>   3. My understanding is that someday in the distant future Rust will
> supplant C in Git.


And you will want a build system that understands both compiling rust,
and installing files in general (cargo cannot do this) and installing a
quite wide variety of data files (implicitly the previous point means
cargo cannot do this either).

Who knows? Maybe in the "distant" future, Meson will have even more
additional support for Rust. I think I may have heard a rumor that Meson
is open source, so contributors will probably be welcome. I also heard
another rumor that QEMU has been contributing a lot to this, and Gnome
and Mesa as well.

If it's all part of the distant future anyway, we can *certainly* try to
help shape the future to fit our needs, and experiment with different
ways to achieve that.

...

BTW: running tests with cargo is a genuine nightmare hellscape. As a
linux distro packager, I don't know what is wrong with cargo but I sure
as heck know that if I run `cargo build` followed by `cargo test`, the
resulting binary, if installed, will have incorrect behavior.

https://gitweb.gentoo.org/repo/gentoo.git/commit/dev-util/ruff?id=f10d64828e9c33b2a1951c9a0e1fa84e4a736875

Meson has sane behavior here, because two completely different build
targets (a program and a unittest) don't create the *same* file.

I am very nervous about trusting cargo for predictable behavior.


>   3. The IDE RustRover only understands Cargo.

Since Meson 0.64 we generate the rust-analyzer official format for
integration:

https://mesonbuild.com/Rust.html#use-with-rustanalyzer

We're very much open to ideas about how to improve this but my
understanding was that rust itself expects you to use this special file
-- why doesn't RustRover use it?

Is RustRover (a very specific thirdparty IDE) a dealbreaker, one way or
another?


> As I mentioned in another thread: The reason why I made Rust a hard
> dependency is because it's easier to develop and talk about that way.
> I'm open to suggestions on how to make Rust optional.


-- 
Eli Schwartz

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [PATCH RFC 2/3] rust: implement a test balloon via the "varint" subsystem

[Patrick Steinhardt]

On Thu, Sep 04, 2025 at 10:00:45PM -0400, Eli Schwartz wrote:
> On 9/4/25 7:39 PM, Ezekiel Newren wrote:
> > On Thu, Sep 4, 2025 at 8:27 AM Patrick Steinhardt <ps@pks.im> wrote:
> >> Implement a trivial test balloon for our Rust build infrastructure by
> >> reimplementing the "varint.c" subsystem in Rust. This subsystem is
> >> chosen because it is trivial to convert and because it doesn't have any
> >> dependencies to other components of Git.
> > 
> > Huh, I thought Meson couldn't run Rust tests. It's refreshing to see
> > someone else try a different approach on bringing Rust to Git.
> > 
> > There are a few reasons why I picked Cargo instead of Meson to build Rust:
> >   1. Needs to work with make.
> 
> 
> If the rust code is defined as a crate, meson can auto-import that crate
> via parsing Cargo.toml, so perhaps this can simply be done by creating a
> 
> [lib]
> crate-type = 'cdylib'
> 
> and... importing it as a meson subproject. You'd be able to build it
> with cargo build, if you really want to (and the Makefile may have to)
> but Meson would not be limited to this.

That sounds like a sensible thing to do. Just to clarify, this doesn't
need the experimental Cargo wraps, right? Is there any documentation for
how to set this up?

Patrick

Re: [PATCH RFC 2/3] rust: implement a test balloon via the "varint" subsystem

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 1475 bytes --]

On 9/5/25 3:54 AM, Patrick Steinhardt wrote:
> On Thu, Sep 04, 2025 at 10:00:45PM -0400, Eli Schwartz wrote:

>> If the rust code is defined as a crate, meson can auto-import that crate
>> via parsing Cargo.toml, so perhaps this can simply be done by creating a
>>
>> [lib]
>> crate-type = 'cdylib'
>>
>> and... importing it as a meson subproject. You'd be able to build it
>> with cargo build, if you really want to (and the Makefile may have to)
>> but Meson would not be limited to this.
> 
> That sounds like a sensible thing to do. Just to clarify, this doesn't
> need the experimental Cargo wraps, right? Is there any documentation for
> how to set this up?


Experimental cargo wraps are new since 1.3.0

https://mesonbuild.com/Release-notes-for-1-3-0.html#automatic-fallback-to-cmake-and-cargo-subproject
https://mesonbuild.com/Wrap-dependency-system-manual.html#cargo-wraps

It operates by synthesizing a virtual `meson.build` file for you via
translation of ordinary Cargo.toml. A copy of the synthesized file is
written out to ${build_dir}/subprojects/foobar-1-rs/ (or whatever the
subproject is named), so you can actually see what a manually written
meson.build would look like.

And e.g. tweak it a bit. (Since it's a virtual file, it always writes
`meson_version : '>= currentver'` to avoid ever triggering "feature new"
warnings, and also stubs out `rust_dependency_map : {}`, but you can
delete both.)


-- 
Eli Schwartz

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [PATCH RFC 2/3] rust: implement a test balloon via the "varint" subsystem

[Ben Knoble]

> Le 4 sept. 2025 à 10:27, Patrick Steinhardt <ps@pks.im> a écrit :
> 
> Implement a trivial test balloon for our Rust build infrastructure by
> reimplementing the "varint.c" subsystem in Rust. This subsystem is
> chosen because it is trivial to convert and because it doesn't have any
> dependencies to other components of Git.
> 
> If support for Rust is enabled, we stop compiling "varint.c" and instead
> compile and use "src/varint.rs".
> 
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
> meson.build     |  5 +++-
> src/lib.rs      |  1 +
> src/meson.build |  1 +
> src/varint.rs   | 92 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 98 insertions(+), 1 deletion(-)
> 
> diff --git a/src/varint.rs b/src/varint.rs
> new file mode 100644
> index 00000000000..3d41760a555
> --- /dev/null
> +++ b/src/varint.rs
> @@ -0,0 +1,92 @@
> +use std::os::raw::c_int;
> +use std::os::raw::c_uchar;
> +
> +#[no_mangle]
> +pub unsafe extern "C" fn decode_varint(bufp: *mut *const c_uchar) -> usize {
> +    let mut buf = *bufp;
> +    let mut c = *buf;
> +    let mut val = usize::from(c & 127);
> +
> +    buf = buf.add(1);
> +
> +    while (c & 128) != 0 {
> +        val += 1;
> +        if val == 0 || val.leading_zeros() < 7 {
> +            return 0; // overflow

Hm. I thought overflows panic in debug builds, in which case checking afterwards is too late? Does unsafe change that?

Re: [PATCH RFC 2/3] rust: implement a test balloon via the "varint" subsystem

[Junio C Hamano]

Ben Knoble <ben.knoble@gmail.com> writes:

>> +#[no_mangle]
>> +pub unsafe extern "C" fn decode_varint(bufp: *mut *const c_uchar) -> usize {
>> +    let mut buf = *bufp;
>> +    let mut c = *buf;
>> +    let mut val = usize::from(c & 127);
>> +
>> +    buf = buf.add(1);
>> +
>> +    while (c & 128) != 0 {
>> +        val += 1;
>> +        if val == 0 || val.leading_zeros() < 7 {
>> +            return 0; // overflow
>
> Hm. I thought overflows panic in debug builds, in which case
> checking afterwards is too late? Does unsafe change that?

This code is a very faithful conversion from C so if somebody does
not read Rust well, they can safely refer to the original in C.

In either variant, the leading zero's check asks "can we shift val
by 7 bits to the left?" _before_ it actually shifts val (and or'es
in the lower bits of c), so the "overflow" check is "if we processed
any more data we _would_ overflow, so we stop before overflowing".

IOW, the code _is_ avoiding the "too late" condition.

This is a tangent, but as many people pointed out, calling this a
test balloon is misreading.  This is quite different from what we
traditionally called a test balloon, where 

 - we were already fairly sure that the construct is safe, but
   wanted to be extra careful to smoke out anybody who has trouble
   with it;

 - hence we use the construct in question in a place where nobody
   can compile it out, hoping that anybody with a system incapable
   of handling the construct in question would be broken badly,
   reporting the breakage to us;

 - this is done with an understanding that even a single "the
   compiler on this this platform with more than dozen thousands
   users cannot groke it" would automatically stop us, causing us to
   revert that test balloon code for _everybody_, refraining from
   using that construct for _everybody_ until the situation changes.

This thing is different at all points.  We are not "fairlu sure that
Rust is safe to use for everybody"  Far from it.  We are confident
that requiring Rust would break known people.  We are doing this not
because we intend to stop once we know of folks who would be broken.
Far from it.

It would really be nice to find a niche that can be a new optional
feature that is not essential to the functioning of the system
implemented in an already modularized part of the system (e.g., an
optional merge strategy, diff algorithm, built-in textconv filter, a
new ref backend, etc.).  Then we can introduce Rust, knowing that
some Rust-challenged systems will not be able to use these optional
features.  What Brian mentioned about two-hash interop feature,
being only available on Rust-capable systems, could be such an
optional feature, and if it can be done that way, that would be very
welcome.  If we can have Rust goodness soon enough without making it
mandatory in too short a timeframe, that would be ideal.

I already said that I find 6 months advance notice to folks on
Rust-challenged systems is way too short to be any good.  If the
only reason we give advance notice is because we want to make an
excuse of cutting them off sooner while being able to say that we
gave them advance notice, that may be sufficient.  But if we truly
want to help them by giving enough time to them so that they can
help their platform themselves, by lobbying, fundraising, or
otherwise campaigning to have usable Rust on their system, I really
do not think it is sufficient.

Thanks.

Re: [PATCH RFC 2/3] rust: implement a test balloon via the "varint" subsystem

[Patrick Steinhardt]

On Sun, Sep 07, 2025 at 09:39:08PM -0700, Junio C Hamano wrote:
> This is a tangent, but as many people pointed out, calling this a
> test balloon is misreading.  This is quite different from what we
> traditionally called a test balloon, where 
> 
>  - we were already fairly sure that the construct is safe, but
>    wanted to be extra careful to smoke out anybody who has trouble
>    with it;
> 
>  - hence we use the construct in question in a place where nobody
>    can compile it out, hoping that anybody with a system incapable
>    of handling the construct in question would be broken badly,
>    reporting the breakage to us;
> 
>  - this is done with an understanding that even a single "the
>    compiler on this this platform with more than dozen thousands
>    users cannot groke it" would automatically stop us, causing us to
>    revert that test balloon code for _everybody_, refraining from
>    using that construct for _everybody_ until the situation changes.
> 
> This thing is different at all points.  We are not "fairlu sure that
> Rust is safe to use for everybody"  Far from it.  We are confident
> that requiring Rust would break known people.  We are doing this not
> because we intend to stop once we know of folks who would be broken.
> Far from it.

That's fair. I still think that this conversion is viable though. The
main intent here is to start building the infrastructure for Rust, which
may take a bit of iteration to fully get there. And the earlier we start
with the process the better, so I think we should go ahead with this
regardless.

From that perspective it still feels like a test balloon to me. The
intent here is less to figure out whether anything breaks. It's more
that we need to have some Rust code in central parts of Git to be able
to tell whether our Rust infra works in the first place. And it allows
downstream packagers to give it a try, as well, so that they can start
to report any issues with our infra before it becomes mandatory.

I don't mind much whether we want to call it a "test balloon" or not.
But giving it a name helps, and "test balloon" is the closest match and
I don't really have a better name. If somebody else does I'm happy to
adapt the wording though.

> It would really be nice to find a niche that can be a new optional
> feature that is not essential to the functioning of the system
> implemented in an already modularized part of the system (e.g., an
> optional merge strategy, diff algorithm, built-in textconv filter, a
> new ref backend, etc.).  Then we can introduce Rust, knowing that
> some Rust-challenged systems will not be able to use these optional
> features.  What Brian mentioned about two-hash interop feature,
> being only available on Rust-capable systems, could be such an
> optional feature, and if it can be done that way, that would be very
> welcome.  If we can have Rust goodness soon enough without making it
> mandatory in too short a timeframe, that would be ideal.

I feel like this is something we should _also_ do. But for now I'd like
to continue with "varint.rs": it's easy to convert, self-contained and
allows us to iterate on our tooling while we don't have a better
subsystem or feature to convert yet.

> I already said that I find 6 months advance notice to folks on
> Rust-challenged systems is way too short to be any good.  If the
> only reason we give advance notice is because we want to make an
> excuse of cutting them off sooner while being able to say that we
> gave them advance notice, that may be sufficient.  But if we truly
> want to help them by giving enough time to them so that they can
> help their platform themselves, by lobbying, fundraising, or
> otherwise campaigning to have usable Rust on their system, I really
> do not think it is sufficient.

Yeah, agreed, six months feels insufficient. My current timeline
suggests roughly a year before we make it mandatory with 3.0 with
various in-between steps that gradually ease into Rust to alert
packagers. Which still may not be sufficient, but it should hopefully
okayish if we also commit to 1.5 years of security fixes.

In any case, the exact timeline very much is an open discussion point.

Patrick

Re: [PATCH RFC 2/3] rust: implement a test balloon via the "varint" subsystem

[Ben Knoble]

> Le 8 sept. 2025 à 00:39, Junio C Hamano <gitster@pobox.com> a écrit :
> 
> Ben Knoble <ben.knoble@gmail.com> writes:
> 
>>> +#[no_mangle]
>>> +pub unsafe extern "C" fn decode_varint(bufp: *mut *const c_uchar) -> usize {
>>> +    let mut buf = *bufp;
>>> +    let mut c = *buf;
>>> +    let mut val = usize::from(c & 127);
>>> +
>>> +    buf = buf.add(1);
>>> +
>>> +    while (c & 128) != 0 {
>>> +        val += 1;
>>> +        if val == 0 || val.leading_zeros() < 7 {
>>> +            return 0; // overflow
>> 
>> Hm. I thought overflows panic in debug builds, in which case
>> checking afterwards is too late? Does unsafe change that?
> 
> This code is a very faithful conversion from C so if somebody does
> not read Rust well, they can safely refer to the original in C.
> 
> In either variant, the leading zero's check asks "can we shift val
> by 7 bits to the left?" _before_ it actually shifts val (and or'es
> in the lower bits of c), so the "overflow" check is "if we processed
> any more data we _would_ overflow, so we stop before overflowing".
> 
> IOW, the code _is_ avoiding the "too late" condition.

Maybe I wasn’t clear, sorry: don’t we already have overflow if after val+=1 we also have val==0? In C with unsigned types AFAIK that’s the normal modular arithmetic, but I thought I recalled that such (unsigned) overflow panics in Rust in debug builds (not in release).

So that’s my « checking afterwards » above.

I’ll see if I can double-check my memory though. 

Re: [PATCH RFC 2/3] rust: implement a test balloon via the "varint" subsystem

[Junio C Hamano]

Ben Knoble <ben.knoble@gmail.com> writes:

>> Le 8 sept. 2025 à 00:39, Junio C Hamano <gitster@pobox.com> a écrit :
>> 
>> Ben Knoble <ben.knoble@gmail.com> writes:
>> 
>>>> +#[no_mangle]
>>>> +pub unsafe extern "C" fn decode_varint(bufp: *mut *const c_uchar) -> usize {
>>>> +    let mut buf = *bufp;
>>>> +    let mut c = *buf;
>>>> +    let mut val = usize::from(c & 127);
>>>> +
>>>> +    buf = buf.add(1);
>>>> +
>>>> +    while (c & 128) != 0 {
>>>> +        val += 1;
>>>> +        if val == 0 || val.leading_zeros() < 7 {
>>>> +            return 0; // overflow
>>> 
>>> Hm. I thought overflows panic in debug builds, in which case
>>> checking afterwards is too late? Does unsafe change that?
>> 
>> This code is a very faithful conversion from C so if somebody does
>> not read Rust well, they can safely refer to the original in C.
>> 
>> In either variant, the leading zero's check asks "can we shift val
>> by 7 bits to the left?" _before_ it actually shifts val (and or'es
>> in the lower bits of c), so the "overflow" check is "if we processed
>> any more data we _would_ overflow, so we stop before overflowing".
>> 
>> IOW, the code _is_ avoiding the "too late" condition.
>
> Maybe I wasn’t clear, sorry: don’t we already have overflow if
> after val+=1 we also have val==0? In C with unsigned types AFAIK
> that’s the normal modular arithmetic, but I thought I recalled
> that such (unsigned) overflow panics in Rust in debug builds (not
> in release).
>
> So that’s my « checking afterwards » above.
>
> I’ll see if I can double-check my memory though. 

Ahh, you meant "can we safely add 1 to val here without
overflowing?"

You probably are correct.  If val in the last round had top 7 bits
all 0 and we shifted the lower 7 bits of 'c' in, and if that made
val all 1 bit, then in the modular arithmetic, we may get val==0
after adding 1 to it, but that may indeed be "overflow"ing.

Thanks.

Re: [PATCH RFC 2/3] rust: implement a test balloon via the "varint" subsystem

[Patrick Steinhardt]

On Sun, Sep 07, 2025 at 04:07:17PM -0400, Ben Knoble wrote:
> > diff --git a/src/varint.rs b/src/varint.rs
> > new file mode 100644
> > index 00000000000..3d41760a555
> > --- /dev/null
> > +++ b/src/varint.rs
> > @@ -0,0 +1,92 @@
> > +use std::os::raw::c_int;
> > +use std::os::raw::c_uchar;
> > +
> > +#[no_mangle]
> > +pub unsafe extern "C" fn decode_varint(bufp: *mut *const c_uchar) -> usize {
> > +    let mut buf = *bufp;
> > +    let mut c = *buf;
> > +    let mut val = usize::from(c & 127);
> > +
> > +    buf = buf.add(1);
> > +
> > +    while (c & 128) != 0 {
> > +        val += 1;
> > +        if val == 0 || val.leading_zeros() < 7 {
> > +            return 0; // overflow
> 
> Hm. I thought overflows panic in debug builds, in which case checking
> afterwards is too late? Does unsafe change that?

I've added a test now and made this an explicit `wrapping_add()`.

Patrick

[PATCH RFC 3/3] BreakingChanges: announce Rust becoming mandatory

[Patrick Steinhardt]

Over the last couple of years the appetite for bringin Rust into the
codebase has grown significantly across the developer base. Introducing
Rust is a major change though and has ramifications for the whole
ecosystem:

  - Some platforms haven't yet been able to implement a Rust toolchain,
    even though it is possible in theory.

  - Some platforms don't have any support for Rust at all.

  - Some platforms may have to figure out how to fit Rust into their
    bootstrapping sequence.

Due to this, and given that Git is a critical piece of infrastructure
for the whole industry, we cannot just introduce such a heavyweight
dependency without doing our due diligence.

Instead, preceding commits have introduced a test balloon into our build
infrastructure that convert one tiny subsystem to use Rust. For now,
using Rust to build that subsystem is entirely optional -- if no Rust
support is available, we continue to use the C implementation. This test
balloon has the intention to give distributions time and let them ease
into our adoption of Rust.

Having multiple implementations of the same subsystem is not sustainable
though, and the plan is to eventually be able to use Rust freely all
across our codebase. As such, there is the intent to make Rust become a
mandatory part of our build process.

Add an announcement to our breaking changes that Rust will become
mandatory in Git 3.0. A (very careful and non-binding) estimate might be
that this major release might be released in the second half of next
year, which should give distributors enough time to prepare for the
change.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 Documentation/BreakingChanges.adoc | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/Documentation/BreakingChanges.adoc b/Documentation/BreakingChanges.adoc
index f8d2eba061..b72c4dd4a0 100644
--- a/Documentation/BreakingChanges.adoc
+++ b/Documentation/BreakingChanges.adoc
@@ -165,6 +165,26 @@ A prerequisite for this change is that the ecosystem is ready to support the
 "reftable" format. Most importantly, alternative implementations of Git like
 JGit, libgit2 and Gitoxide need to support it.
 
+* Git will require Rust as a mandatory part of the build process. While Git
+  already started to adopt Rust in the Git 2.52, all parts written in Rust are
+  optional for the time being. This includes:
++
+  ** Subsystems that have an alternative implementation in Rust to test
+     interoperability between our C and Rust codebase.
+  ** Newly written features that are not mission critical for a fully functional
+     Git client.
++
+Meson auto-detects the availability of a Rust toolchain and, if available,
+builds the optional Rust code. This can be changed by executing `meson configure
+-Drust=(enabled|disabled|auto)`.
++
+These changes are meant as test balloons to allow distributors of Git to prepare
+for Rust becoming a mandatory part of the build process. Once Git 3.0 is out,
+Rust becomes mandatory and it will not be possible anymore to build Git without
+it. The Git project will declare the last version before Git 3.0 to be a
+long-term support release that is maintained until alternate Rust backends like
+gcc-rs are able to build Git.
+
 === Removals
 
 * Support for grafting commits has long been superseded by git-replace(1).

-- 
2.51.0.417.g1ba7204a04.dirty

Re: [PATCH RFC 3/3] BreakingChanges: announce Rust becoming mandatory

[Eric Sunshine]

On Thu, Sep 4, 2025 at 10:30 AM Patrick Steinhardt <ps@pks.im> wrote:
> Over the last couple of years the appetite for bringin Rust into the
> codebase has grown significantly across the developer base. Introducing
> Rust is a major change though and has ramifications for the whole
> ecosystem:

s/bringin/bringing/

> Instead, preceding commits have introduced a test balloon into our build
> infrastructure that convert one tiny subsystem to use Rust. For now,
> using Rust to build that subsystem is entirely optional -- if no Rust
> support is available, we continue to use the C implementation. This test
> balloon has the intention to give distributions time and let them ease
> into our adoption of Rust.

If it's entirely optional and automatically disabled on platforms
which don't have Rust installed/available, then it isn't a test
balloon, is it? All previous test balloons in this project were
architected in such a way that Git would fail to build if the platform
in question lacked the feature being "test-ballooned", and the idea
was that packagers of those systems would alert the Git project about
the problem or somehow resolve it themselves via the platform's local
build infrastructure.

However, with the approach implemented here, Git will build as usual
on all platforms on which it already builds successfully, which means
that the Git project is unlikely to hear complaints from packagers,
especially if packagers haven't followed the relevant discussion
threads and are unaware that a Rust test is being conducted. Moreover,
the project has already heard from some packagers/maintainers that
Rust support is lacking or (currently) impossible, so the project
already has the sort of knowledge that a test balloon is intended to
elicit.

That's not to say that the changes implemented by this series can't be
valuable, but rather that for these patches to be valuable, you
probably need some way to advertise the test more loudly so that
packagers actually attempt the Rust build. One possible way to rectify
this shortcoming would be to enable the Rust code by default in the
Git project but give packagers a way to opt out of it if they can't
make it work on their platforms.

> Having multiple implementations of the same subsystem is not sustainable
> though, and the plan is to eventually be able to use Rust freely all
> across our codebase. As such, there is the intent to make Rust become a
> mandatory part of our build process.
>
> Add an announcement to our breaking changes that Rust will become
> mandatory in Git 3.0. A (very careful and non-binding) estimate might be
> that this major release might be released in the second half of next
> year, which should give distributors enough time to prepare for the
> change.
>
> Signed-off-by: Patrick Steinhardt <ps@pks.im>

Re: [PATCH RFC 3/3] BreakingChanges: announce Rust becoming mandatory

[Patrick Steinhardt]

On Thu, Sep 04, 2025 at 01:38:52PM -0400, Eric Sunshine wrote:
> On Thu, Sep 4, 2025 at 10:30 AM Patrick Steinhardt <ps@pks.im> wrote:
> > Over the last couple of years the appetite for bringin Rust into the
> > codebase has grown significantly across the developer base. Introducing
> > Rust is a major change though and has ramifications for the whole
> > ecosystem:
> 
> s/bringin/bringing/
> 
> > Instead, preceding commits have introduced a test balloon into our build
> > infrastructure that convert one tiny subsystem to use Rust. For now,
> > using Rust to build that subsystem is entirely optional -- if no Rust
> > support is available, we continue to use the C implementation. This test
> > balloon has the intention to give distributions time and let them ease
> > into our adoption of Rust.
> 
> If it's entirely optional and automatically disabled on platforms
> which don't have Rust installed/available, then it isn't a test
> balloon, is it? All previous test balloons in this project were
> architected in such a way that Git would fail to build if the platform
> in question lacked the feature being "test-ballooned", and the idea
> was that packagers of those systems would alert the Git project about
> the problem or somehow resolve it themselves via the platform's local
> build infrastructure.
> 
> However, with the approach implemented here, Git will build as usual
> on all platforms on which it already builds successfully, which means
> that the Git project is unlikely to hear complaints from packagers,
> especially if packagers haven't followed the relevant discussion
> threads and are unaware that a Rust test is being conducted. Moreover,
> the project has already heard from some packagers/maintainers that
> Rust support is lacking or (currently) impossible, so the project
> already has the sort of knowledge that a test balloon is intended to
> elicit.
> 
> That's not to say that the changes implemented by this series can't be
> valuable, but rather that for these patches to be valuable, you
> probably need some way to advertise the test more loudly so that
> packagers actually attempt the Rust build. One possible way to rectify
> this shortcoming would be to enable the Rust code by default in the
> Git project but give packagers a way to opt out of it if they can't
> make it work on their platforms.

Very true indeed. Thinking about this, how about we make this a
multi-step process?

  1. Introduce the feature as "auto"-detected on Meson and disabled in
     our Makefile. This allows us to get comfortable with the tooling
     and address any issues we find iteratively.

  2. Change Meson to default to "-Drust=enabled" and change our Makefile
     to make Rust opt-out instead of opt-in. Distros can still disable
     this, but should now be alert that something is upcoming.

  3. Remove the feature toggles altogether. Rust is now mandatory.

If this patch series here lands (1) would be the status quo. In one or
two releases we could then do (2). And with Git 3.0 we can finally do
(3).

I'll add this process to the BreakingChanges document to give readers
some guidance.

Patrick

[PATCH RFC v2 0/7] Introduce Rust and announce that it will become mandatorty

[Patrick Steinhardt]

Hi,

this small patch series introduces Rust into the core of Git. This patch
series is designed as a test balloon, similar to how we introduced test
balloons for C99 features in the past. The goal is threefold:

  - Give us some time to experiment with Rust and introduce proper build
    infrastructure.

  - Give distributors time to ease into the new toolchain requirements.
    Introducing Rust is impossible for some platforms and hard for
    others.

  - Announce that Git 3.0 will make Rust a mandatory part of our build
    infrastructure.

The test balloon itself is quite uninteresting: I've chosen to convert
the "varint.c" subsystem, mostly because it is trivial and does not have
any dependencies. But it does allow us to verify that C to Rust interop
works as expected, and to play around with tooling. All tests pass with
the "varint.rs" implementation.

For now, the series only contains support for Meson. If we agree to go
down this route I'll also introduce support for Rust into our Makefiles
at a later point in time.

Furthermore missing is additional tooling:

  - At least one CI job to verify that Rust builds and works as
    expected.

  - Tooling and CI jobs to ensure that we have consistent formatting via
    `cargo format`.

And probably lots more. As said, the entire goal is for us to have an
easy playground that we can experiment on and develop the infrastructure
incrementally without yet having to commit to anything.

I'm mostly splitting out the topic of introducing Rust from the larger
series that introduce it into xdiff so that we can focus more on the
actual process of introducing Rust into Git and less on the potential
features that we want to build on top of it.

Changes in v2:
  - Introduce support for building the Rust library via our Makefile.
  - Introduce a '-DWITH_RUST' define. This define is used to print
    whether or not Git is built with Rust via `git version
    --build-options`.
  - Adjust Meson to not depend on v1.9.0 and newer anymore.
  - Introduce a roadmap into our BreakingChanges document to explain how
    we'll iterate towards mandatory Rust support.
  - Rework the Fedora job to do a full compile-and-test run with Meson
    and breaking changes enabled.
  - Adapt our breaking-changes jobs to enable Rust support.
  - Link to v1: https://lore.kernel.org/r/20250904-b4-pks-rust-breaking-change-v1-0-3af1d25e0be9@pks.im

Thanks!

Patrick

---
Patrick Steinhardt (7):
      meson: add infrastructure to build internal Rust library
      Makefile: introduce infrastructure to build internal Rust library
      help: report on whether or not Rust is enabled
      rust: implement a test balloon via the "varint" subsystem
      BreakingChanges: announce Rust becoming mandatory
      ci: convert "pedantic" job into full build with breaking changes
      ci: enable Rust for breaking-changes jobs

 .github/workflows/main.yml         |  4 +-
 .gitignore                         |  2 +
 .gitlab-ci.yml                     |  4 +-
 Cargo.toml                         |  9 ++++
 Documentation/BreakingChanges.adoc | 36 +++++++++++++++
 Makefile                           | 47 ++++++++++++++++++-
 ci/install-dependencies.sh         |  4 +-
 ci/run-build-and-tests.sh          | 31 +++++--------
 help.c                             |  6 +++
 meson.build                        | 17 ++++++-
 meson_options.txt                  |  2 +
 src/lib.rs                         |  1 +
 src/meson.build                    | 16 +++++++
 src/varint.rs                      | 92 ++++++++++++++++++++++++++++++++++++++
 14 files changed, 240 insertions(+), 31 deletions(-)

Range-diff versus v1:

1:  4df400823c ! 1:  8f6e89bc7d meson: add infrastructure to build internal Rust library
    @@ meson.build: version_def_h = custom_target(
      
     +libgit_libraries = [ ]
     +
    -+if meson.version().version_compare('>=1.9.0')
    -+  rust_available = add_languages('rust', native: false, required: get_option('rust'))
    -+else
    -+  rust_available = false
    -+endif
    ++rust_available = add_languages('rust', native: false, required: get_option('rust'))
     +rust_option = get_option('rust').disable_auto_if(not rust_available)
    -+
    -+if rust_option.allowed() and meson.version().version_compare('>=1.9.0')
    ++if rust_option.allowed()
     +  subdir('src')
    ++  libgit_c_args += '-DWITH_RUST'
     +endif
     +
      libgit = declare_dependency(
    @@ src/lib.rs (new)
     
      ## src/meson.build (new) ##
     @@
    -+rustmod = import('rust')
    -+
     +libgit_rs = static_library('git_rs',
     +  sources: [
     +    'lib.rs',
     +  ],
    -+  rust_abi: 'c',
    ++  rust_crate_type: 'staticlib',
     +)
    -+
    -+rustmod.test('git-rs', libgit_rs)
    -+
     +libgit_libraries += libgit_rs
    ++
    ++# The 'rust' module was only introduced in Meson 1.0. Furthermore, the module
    ++# does not seem to work on macOS as expected right now. As such, we only
    ++# conditionally enable tests.
    ++if meson.version().version_compare('>=1.0.0') and host_machine.system() != 'darwin'
    ++  rustmod = import('rust')
    ++  rustmod.test('rust', libgit_rs)
    ++endif
-:  ---------- > 2:  cd1d642d04 Makefile: introduce infrastructure to build internal Rust library
-:  ---------- > 3:  e60a8353a4 help: report on whether or not Rust is enabled
2:  575f6de44d ! 4:  b27811aea4 rust: implement a test balloon via the "varint" subsystem
    @@ Commit message
     
         Signed-off-by: Patrick Steinhardt <ps@pks.im>
     
    + ## Makefile ##
    +@@ Makefile: LIB_OBJS += urlmatch.o
    + LIB_OBJS += usage.o
    + LIB_OBJS += userdiff.o
    + LIB_OBJS += utf8.o
    ++ifndef WITH_RUST
    + LIB_OBJS += varint.o
    ++endif
    + LIB_OBJS += version.o
    + LIB_OBJS += versioncmp.o
    + LIB_OBJS += walker.o
    +
      ## meson.build ##
     @@ meson.build: libgit_sources = [
        'usage.c',
    @@ meson.build: libgit_sources = [
        'versioncmp.c',
        'walker.c',
     @@ meson.build: rust_option = get_option('rust').disable_auto_if(not rust_available)
    - 
    - if rust_option.allowed() and meson.version().version_compare('>=1.9.0')
    + if rust_option.allowed()
        subdir('src')
    +   libgit_c_args += '-DWITH_RUST'
     +else
     +  libgit_sources += [
     +    'varint.c',
    @@ src/lib.rs
     +pub mod varint;
     
      ## src/meson.build ##
    -@@ src/meson.build: rustmod = import('rust')
    +@@
      libgit_rs = static_library('git_rs',
        sources: [
          'lib.rs',
     +    'varint.rs',
        ],
    -   rust_abi: 'c',
    +   rust_crate_type: 'staticlib',
      )
     
      ## src/varint.rs (new) ##
3:  e54393392a < -:  ---------- BreakingChanges: announce Rust becoming mandatory
-:  ---------- > 5:  d5946e0114 BreakingChanges: announce Rust becoming mandatory
-:  ---------- > 6:  0d367976de ci: convert "pedantic" job into full build with breaking changes
-:  ---------- > 7:  82086a5328 ci: enable Rust for breaking-changes jobs

---
base-commit: 2462961280690837670d997bde64bd4ebf8ae66d
change-id: 20250904-b4-pks-rust-breaking-change-7167d9d3e37d

[PATCH RFC v2 1/7] meson: add infrastructure to build internal Rust library

[Patrick Steinhardt]

Add the infrastructure into Meson to build an internal Rust library.
Building the Rust parts of Git are for now entirely optional, as they
are mostly intended as a test balloon for both Git developers, but also
for distributors of Git. So for now, they may contain:

  - New features that are not mission critical to Git and that users can
    easily live without.

  - Alternative implementations of small subsystems.

If these test balloons are successful, we will eventually make Rust a
mandatory dependency for our build process in Git 3.0.

The availability of a Rust toolchain will be auto-detected by Meson at
setup time. This behaviour can be tweaked via the `-Drust=` feature
toggle.

Next to the linkable Rust library, also wire up tests that can be
executed via `meson test`. This allows us to use the native unit testing
capabilities of Rust.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 meson.build       | 12 +++++++++++-
 meson_options.txt |  2 ++
 src/lib.rs        |  0
 src/meson.build   | 15 +++++++++++++++
 4 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index e8ec0eca165..5b2e9af1bf1 100644
--- a/meson.build
+++ b/meson.build
@@ -1702,8 +1702,17 @@ version_def_h = custom_target(
 )
 libgit_sources += version_def_h
 
+libgit_libraries = [ ]
+
+rust_available = add_languages('rust', native: false, required: get_option('rust'))
+rust_option = get_option('rust').disable_auto_if(not rust_available)
+if rust_option.allowed()
+  subdir('src')
+  libgit_c_args += '-DWITH_RUST'
+endif
+
 libgit = declare_dependency(
-  link_with: static_library('git',
+  link_with: libgit_libraries + static_library('git',
     sources: libgit_sources,
     c_args: libgit_c_args + [
       '-DGIT_VERSION_H="' + version_def_h.full_path() + '"',
@@ -2239,6 +2248,7 @@ summary({
   'pcre2': pcre2,
   'perl': perl_features_enabled,
   'python': target_python.found(),
+  'rust': rust_option.allowed(),
 }, section: 'Auto-detected features', bool_yn: true)
 
 summary({
diff --git a/meson_options.txt b/meson_options.txt
index 1668f260a18..143dee9237c 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -71,6 +71,8 @@ option('zlib_backend', type: 'combo', choices: ['auto', 'zlib', 'zlib-ng'], valu
 # Build tweaks.
 option('breaking_changes', type: 'boolean', value: false,
   description: 'Enable upcoming breaking changes.')
+option('rust', type: 'feature', value: 'auto',
+  description: 'Enable building with Rust.')
 option('macos_use_homebrew_gettext', type: 'boolean', value: true,
   description: 'Use gettext from Homebrew instead of the slightly-broken system-provided one.')
 
diff --git a/src/lib.rs b/src/lib.rs
new file mode 100644
index 00000000000..e69de29bb2d
diff --git a/src/meson.build b/src/meson.build
new file mode 100644
index 00000000000..eb752651d35
--- /dev/null
+++ b/src/meson.build
@@ -0,0 +1,15 @@
+libgit_rs = static_library('git_rs',
+  sources: [
+    'lib.rs',
+  ],
+  rust_crate_type: 'staticlib',
+)
+libgit_libraries += libgit_rs
+
+# The 'rust' module was only introduced in Meson 1.0. Furthermore, the module
+# does not seem to work on macOS as expected right now. As such, we only
+# conditionally enable tests.
+if meson.version().version_compare('>=1.0.0') and host_machine.system() != 'darwin'
+  rustmod = import('rust')
+  rustmod.test('rust', libgit_rs)
+endif

-- 
2.51.0.417.g1ba7204a04.dirty

Re: [PATCH RFC v2 1/7] meson: add infrastructure to build internal Rust library

[Justin Tobler]

On 25/09/05 01:50PM, Patrick Steinhardt wrote:
> +# The 'rust' module was only introduced in Meson 1.0. Furthermore, the module
> +# does not seem to work on macOS as expected right now. As such, we only
> +# conditionally enable tests.
> +if meson.version().version_compare('>=1.0.0') and host_machine.system() != 'darwin'
> +  rustmod = import('rust')
> +  rustmod.test('rust', libgit_rs)
> +endif

Out of curiousity, what is the problem that we are seeing with macOS? I
removed the darwin guard statement and didn't notice any problems when
running `meson test rust`. Is this a well known problem with the Rust
module?

-Justin

Re: [PATCH RFC v2 1/7] meson: add infrastructure to build internal Rust library

[Patrick Steinhardt]

On Fri, Sep 05, 2025 at 12:47:20PM -0500, Justin Tobler wrote:
> On 25/09/05 01:50PM, Patrick Steinhardt wrote:
> > +# The 'rust' module was only introduced in Meson 1.0. Furthermore, the module
> > +# does not seem to work on macOS as expected right now. As such, we only
> > +# conditionally enable tests.
> > +if meson.version().version_compare('>=1.0.0') and host_machine.system() != 'darwin'
> > +  rustmod = import('rust')
> > +  rustmod.test('rust', libgit_rs)
> > +endif
> 
> Out of curiousity, what is the problem that we are seeing with macOS? I
> removed the darwin guard statement and didn't notice any problems when
> running `meson test rust`. Is this a well known problem with the Rust
> module?

It's this:

    Rust linker for the host machine: rustc -C linker=clang ld64 1053.12
    WARNING: Unknown keyword argument(s) in target rustxx: prelink, pic, rust_abi.
    src/meson.build:12:10: ERROR: Fatal warnings enabled, aborting

I haven't yet found a time to look into it more in depth, and assume
that it's fixed in more recent versions of Meson.

Patrick

Re: [PATCH RFC v2 1/7] meson: add infrastructure to build internal Rust library

[Elijah Newren]

On Fri, Sep 5, 2025 at 4:51 AM Patrick Steinhardt <ps@pks.im> wrote:
>
> Add the infrastructure into Meson to build an internal Rust library.
> Building the Rust parts of Git are for now entirely optional, as they
> are mostly intended as a test balloon for both Git developers, but also
> for distributors of Git. So for now, they may contain:
>
>   - New features that are not mission critical to Git and that users can
>     easily live without.
>
>   - Alternative implementations of small subsystems.
>
> If these test balloons are successful, we will eventually make Rust a
> mandatory dependency for our build process in Git 3.0.

Okay.

> The availability of a Rust toolchain will be auto-detected by Meson at
> setup time. This behaviour can be tweaked via the `-Drust=` feature
> toggle.

This goes against what you said above, because it turns it into
something other than a test balloon.  As I've said elsewhere, I don't
think this part is helpful; it reduces the amount of notice that
distributors and platforms have about our intent to make Rust
mandatory.

> Next to the linkable Rust library, also wire up tests that can be
> executed via `meson test`. This allows us to use the native unit testing
> capabilities of Rust.

Cool.

> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
>  meson.build       | 12 +++++++++++-
>  meson_options.txt |  2 ++
>  src/lib.rs        |  0
>  src/meson.build   | 15 +++++++++++++++
>  4 files changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/meson.build b/meson.build
> index e8ec0eca165..5b2e9af1bf1 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1702,8 +1702,17 @@ version_def_h = custom_target(
>  )
>  libgit_sources += version_def_h
>
> +libgit_libraries = [ ]
> +
> +rust_available = add_languages('rust', native: false, required: get_option('rust'))
> +rust_option = get_option('rust').disable_auto_if(not rust_available)
> +if rust_option.allowed()
> +  subdir('src')
> +  libgit_c_args += '-DWITH_RUST'
> +endif
> +
>  libgit = declare_dependency(
> -  link_with: static_library('git',
> +  link_with: libgit_libraries + static_library('git',
>      sources: libgit_sources,
>      c_args: libgit_c_args + [
>        '-DGIT_VERSION_H="' + version_def_h.full_path() + '"',
> @@ -2239,6 +2248,7 @@ summary({
>    'pcre2': pcre2,
>    'perl': perl_features_enabled,
>    'python': target_python.found(),
> +  'rust': rust_option.allowed(),
>  }, section: 'Auto-detected features', bool_yn: true)
>
>  summary({
> diff --git a/meson_options.txt b/meson_options.txt
> index 1668f260a18..143dee9237c 100644
> --- a/meson_options.txt
> +++ b/meson_options.txt
> @@ -71,6 +71,8 @@ option('zlib_backend', type: 'combo', choices: ['auto', 'zlib', 'zlib-ng'], valu
>  # Build tweaks.
>  option('breaking_changes', type: 'boolean', value: false,
>    description: 'Enable upcoming breaking changes.')
> +option('rust', type: 'feature', value: 'auto',
> +  description: 'Enable building with Rust.')
>  option('macos_use_homebrew_gettext', type: 'boolean', value: true,
>    description: 'Use gettext from Homebrew instead of the slightly-broken system-provided one.')
>
> diff --git a/src/lib.rs b/src/lib.rs
> new file mode 100644
> index 00000000000..e69de29bb2d
> diff --git a/src/meson.build b/src/meson.build
> new file mode 100644
> index 00000000000..eb752651d35
> --- /dev/null
> +++ b/src/meson.build
> @@ -0,0 +1,15 @@
> +libgit_rs = static_library('git_rs',
> +  sources: [
> +    'lib.rs',
> +  ],
> +  rust_crate_type: 'staticlib',
> +)
> +libgit_libraries += libgit_rs
> +
> +# The 'rust' module was only introduced in Meson 1.0. Furthermore, the module
> +# does not seem to work on macOS as expected right now. As such, we only
> +# conditionally enable tests.
> +if meson.version().version_compare('>=1.0.0') and host_machine.system() != 'darwin'
> +  rustmod = import('rust')
> +  rustmod.test('rust', libgit_rs)
> +endif

Would it make sense to invoke 'cargo test' as one step of 'meson test'
on mac as an alternative, so that mac users also can run the tests?

Re: [PATCH RFC v2 1/7] meson: add infrastructure to build internal Rust library

[Patrick Steinhardt]

On Sat, Sep 06, 2025 at 09:54:18PM -0700, Elijah Newren wrote:
> On Fri, Sep 5, 2025 at 4:51 AM Patrick Steinhardt <ps@pks.im> wrote:
> >
> > Add the infrastructure into Meson to build an internal Rust library.
> > Building the Rust parts of Git are for now entirely optional, as they
> > are mostly intended as a test balloon for both Git developers, but also
> > for distributors of Git. So for now, they may contain:
> >
> >   - New features that are not mission critical to Git and that users can
> >     easily live without.
> >
> >   - Alternative implementations of small subsystems.
> >
> > If these test balloons are successful, we will eventually make Rust a
> > mandatory dependency for our build process in Git 3.0.
> 
> Okay.
> 
> > The availability of a Rust toolchain will be auto-detected by Meson at
> > setup time. This behaviour can be tweaked via the `-Drust=` feature
> > toggle.
> 
> This goes against what you said above, because it turns it into
> something other than a test balloon.  As I've said elsewhere, I don't
> think this part is helpful; it reduces the amount of notice that
> distributors and platforms have about our intent to make Rust
> mandatory.

See the BreakingChanges document later in this series, which talks about
this. Makes me wonder whether I should reverse the order of patches so
that the BreakingChanges are more prominent.

> > diff --git a/src/meson.build b/src/meson.build
> > new file mode 100644
> > index 00000000000..eb752651d35
> > --- /dev/null
> > +++ b/src/meson.build
> > @@ -0,0 +1,15 @@
> > +libgit_rs = static_library('git_rs',
> > +  sources: [
> > +    'lib.rs',
> > +  ],
> > +  rust_crate_type: 'staticlib',
> > +)
> > +libgit_libraries += libgit_rs
> > +
> > +# The 'rust' module was only introduced in Meson 1.0. Furthermore, the module
> > +# does not seem to work on macOS as expected right now. As such, we only
> > +# conditionally enable tests.
> > +if meson.version().version_compare('>=1.0.0') and host_machine.system() != 'darwin'
> > +  rustmod = import('rust')
> > +  rustmod.test('rust', libgit_rs)
> > +endif
> 
> Would it make sense to invoke 'cargo test' as one step of 'meson test'
> on mac as an alternative, so that mac users also can run the tests?

Maybe. I'll revisit the Meson code anyway to figure out how to get Cargo
support in there natively.

Patrick

[PATCH RFC v2 2/7] Makefile: introduce infrastructure to build internal Rust library

[Patrick Steinhardt]

Introduce infrastructure to build the internal Rust library. This
mirrors the infrastructure we have added to Meson in the preceding
commit. Developers can enable the infrastructure by passing the new
`WITH_RUST` build toggle.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 .gitignore |  2 ++
 Cargo.toml |  9 +++++++++
 Makefile   | 45 +++++++++++++++++++++++++++++++++++++++++++--
 3 files changed, 54 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index 1803023427..0833453cf6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,4 +1,6 @@
 /fuzz_corpora
+/target/
+/Cargo.lock
 /GIT-BUILD-DIR
 /GIT-BUILD-OPTIONS
 /GIT-CFLAGS
diff --git a/Cargo.toml b/Cargo.toml
new file mode 100644
index 0000000000..17a4f4da0c
--- /dev/null
+++ b/Cargo.toml
@@ -0,0 +1,9 @@
+[package]
+name = "git"
+version = "0.1.0"
+edition = "2021"
+
+[lib]
+crate-type = ["staticlib"]
+
+[dependencies]
diff --git a/Makefile b/Makefile
index 555b7f4dc3..e7b3c8e57b 100644
--- a/Makefile
+++ b/Makefile
@@ -483,6 +483,14 @@ include shared.mak
 # Define LIBPCREDIR=/foo/bar if your PCRE header and library files are
 # in /foo/bar/include and /foo/bar/lib directories.
 #
+# == Optional Rust support ==
+#
+# Define WITH_RUST if you want to include features and subsystems written in
+# Rust into Git. For now, Rust is still an optional feature of the build
+# process. With Git 3.0 though, Rust will always be enabled.
+#
+# Building Rust code requires Cargo.
+#
 # == SHA-1 and SHA-256 defines ==
 #
 # === SHA-1 backend ===
@@ -918,6 +926,11 @@ TEST_SHELL_PATH = $(SHELL_PATH)
 LIB_FILE = libgit.a
 XDIFF_LIB = xdiff/lib.a
 REFTABLE_LIB = reftable/libreftable.a
+ifdef DEBUG
+RUST_LIB = target/debug/libgit.a
+else
+RUST_LIB = target/release/libgit.a
+endif
 
 GENERATED_H += command-list.h
 GENERATED_H += config-list.h
@@ -1387,8 +1400,12 @@ CLAR_TEST_OBJS += $(UNIT_TEST_DIR)/unit-test.o
 
 UNIT_TEST_OBJS += $(UNIT_TEST_DIR)/test-lib.o
 
-# xdiff and reftable libs may in turn depend on what is in libgit.a
-GITLIBS = common-main.o $(LIB_FILE) $(XDIFF_LIB) $(REFTABLE_LIB) $(LIB_FILE)
+GITLIBS = common-main.o $(LIB_FILE) $(XDIFF_LIB) $(REFTABLE_LIB)
+ifdef WITH_RUST
+GITLIBS += $(RUST_LIB)
+endif
+# Other libs may in turn depend on what is in libgit.a.
+GITLIBS += $(LIB_FILE)
 EXTLIBS =
 
 GIT_USER_AGENT = git/$(GIT_VERSION)
@@ -1411,6 +1428,19 @@ BASIC_LDFLAGS =
 ARFLAGS = rcs
 PTHREAD_CFLAGS =
 
+# Rust flags
+CARGO_ARGS =
+ifndef V
+CARGO_ARGS += --quiet
+endif
+ifndef DEBUG
+CARGO_ARGS += --release
+endif
+
+ifdef WITH_RUST
+BASIC_CFLAGS += -DWITH_RUST
+endif
+
 # For the 'sparse' target
 SPARSE_FLAGS ?= -std=gnu99 -D__STDC_NO_VLA__
 SP_EXTRA_FLAGS =
@@ -2918,6 +2948,16 @@ scalar$X: scalar.o GIT-LDFLAGS $(GITLIBS)
 $(LIB_FILE): $(LIB_OBJS)
 	$(QUIET_AR)$(RM) $@ && $(AR) $(ARFLAGS) $@ $^
 
+$(RUST_LIB): FORCE
+	@OLD_STAT="$$(stat $@ 2>/dev/null)"; \
+	    cargo build $(CARGO_ARGS); \
+	    if test $$? != 0 || test x"$$OLD_STAT" != x"$$(stat $@ 2>/dev/null)"; then \
+		echo '   ' CARGO $@; \
+	    fi
+
+.PHONY: rust
+rust: $(RUST_LIB)
+
 $(XDIFF_LIB): $(XDIFF_OBJS)
 	$(QUIET_AR)$(RM) $@ && $(AR) $(ARFLAGS) $@ $^
 
@@ -3768,6 +3808,7 @@ clean: profile-clean coverage-clean cocciclean
 	$(RM) $(FUZZ_PROGRAMS)
 	$(RM) $(SP_OBJ)
 	$(RM) $(HCC)
+	$(RM) -r target/ Cargo.lock
 	$(RM) version-def.h
 	$(RM) -r $(dep_dirs) $(compdb_dir) compile_commands.json
 	$(RM) $(test_bindir_programs)

-- 
2.51.0.417.g1ba7204a04.dirty

Re: [PATCH RFC v2 2/7] Makefile: introduce infrastructure to build internal Rust library

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2939 bytes --]

On 2025-09-05 at 11:50:58, Patrick Steinhardt wrote:
> Introduce infrastructure to build the internal Rust library. This
> mirrors the infrastructure we have added to Meson in the preceding
> commit. Developers can enable the infrastructure by passing the new
> `WITH_RUST` build toggle.

The idea here seems great and I'm fully on board…

> diff --git a/Makefile b/Makefile
> index 555b7f4dc3..e7b3c8e57b 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -483,6 +483,14 @@ include shared.mak
>  # Define LIBPCREDIR=/foo/bar if your PCRE header and library files are
>  # in /foo/bar/include and /foo/bar/lib directories.
>  #
> +# == Optional Rust support ==
> +#
> +# Define WITH_RUST if you want to include features and subsystems written in
> +# Rust into Git. For now, Rust is still an optional feature of the build
> +# process. With Git 3.0 though, Rust will always be enabled.
> +#
> +# Building Rust code requires Cargo.
> +#
>  # == SHA-1 and SHA-256 defines ==
>  #
>  # === SHA-1 backend ===
> @@ -918,6 +926,11 @@ TEST_SHELL_PATH = $(SHELL_PATH)
>  LIB_FILE = libgit.a
>  XDIFF_LIB = xdiff/lib.a
>  REFTABLE_LIB = reftable/libreftable.a
> +ifdef DEBUG
> +RUST_LIB = target/debug/libgit.a
> +else
> +RUST_LIB = target/release/libgit.a
> +endif
>  
>  GENERATED_H += command-list.h
>  GENERATED_H += config-list.h
> @@ -1387,8 +1400,12 @@ CLAR_TEST_OBJS += $(UNIT_TEST_DIR)/unit-test.o
>  
>  UNIT_TEST_OBJS += $(UNIT_TEST_DIR)/test-lib.o
>  
> -# xdiff and reftable libs may in turn depend on what is in libgit.a
> -GITLIBS = common-main.o $(LIB_FILE) $(XDIFF_LIB) $(REFTABLE_LIB) $(LIB_FILE)
> +GITLIBS = common-main.o $(LIB_FILE) $(XDIFF_LIB) $(REFTABLE_LIB)
> +ifdef WITH_RUST
> +GITLIBS += $(RUST_LIB)
> +endif
> +# Other libs may in turn depend on what is in libgit.a.
> +GITLIBS += $(LIB_FILE)
>  EXTLIBS =
>  
>  GIT_USER_AGENT = git/$(GIT_VERSION)
> @@ -1411,6 +1428,19 @@ BASIC_LDFLAGS =
>  ARFLAGS = rcs
>  PTHREAD_CFLAGS =
>  
> +# Rust flags
> +CARGO_ARGS =
> +ifndef V
> +CARGO_ARGS += --quiet
> +endif
> +ifndef DEBUG
> +CARGO_ARGS += --release
> +endif
> +
> +ifdef WITH_RUST
> +BASIC_CFLAGS += -DWITH_RUST
> +endif

…but unfortunately, all of this code is above the `-include config.mak`
line, so if I set `WITH_RUST=1` in `config.mak`, it doesn't work: no
`target` directory is created and `git version --build-options` says
Rust isn't enabled.  (It does work if I specify `WITH_RUST=1` on the
command line, though.)

Might it be a better idea to place this with the conditional code
farther down so it's properly honoured when configured in `config.mak`
and friends?

I am very pleased by the fact that cargo is quiet by default, though,
and otherwise it seems to be well integrated into our build system.
This patch seems smaller than I was expecting, which is nice.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [PATCH RFC v2 2/7] Makefile: introduce infrastructure to build internal Rust library

[Patrick Steinhardt]

On Fri, Sep 05, 2025 at 08:21:54PM +0000, brian m. carlson wrote:
> On 2025-09-05 at 11:50:58, Patrick Steinhardt wrote:
> > diff --git a/Makefile b/Makefile
> > index 555b7f4dc3..e7b3c8e57b 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1411,6 +1428,19 @@ BASIC_LDFLAGS =
> >  ARFLAGS = rcs
> >  PTHREAD_CFLAGS =
> >  
> > +# Rust flags
> > +CARGO_ARGS =
> > +ifndef V
> > +CARGO_ARGS += --quiet
> > +endif
> > +ifndef DEBUG
> > +CARGO_ARGS += --release
> > +endif
> > +
> > +ifdef WITH_RUST
> > +BASIC_CFLAGS += -DWITH_RUST
> > +endif
> 
> …but unfortunately, all of this code is above the `-include config.mak`
> line, so if I set `WITH_RUST=1` in `config.mak`, it doesn't work: no
> `target` directory is created and `git version --build-options` says
> Rust isn't enabled.  (It does work if I specify `WITH_RUST=1` on the
> command line, though.)
> 
> Might it be a better idea to place this with the conditional code
> farther down so it's properly honoured when configured in `config.mak`
> and friends?

Oops, good catch!

Patrick

Re: [PATCH RFC v2 2/7] Makefile: introduce infrastructure to build internal Rust library

[Elijah Newren]

On Fri, Sep 5, 2025 at 4:51 AM Patrick Steinhardt <ps@pks.im> wrote:
>
> Introduce infrastructure to build the internal Rust library. This
> mirrors the infrastructure we have added to Meson in the preceding
> commit. Developers can enable the infrastructure by passing the new
> `WITH_RUST` build toggle.

So, again, this makes it not a test balloon, which reduces the amount
of notice distributors will get.  I'd prefer a WITHOUT_RUST build
toggle, so they get as much notice as possible.

> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
>  .gitignore |  2 ++
>  Cargo.toml |  9 +++++++++
>  Makefile   | 45 +++++++++++++++++++++++++++++++++++++++++++--
>  3 files changed, 54 insertions(+), 2 deletions(-)
>
> diff --git a/.gitignore b/.gitignore
> index 1803023427..0833453cf6 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -1,4 +1,6 @@
>  /fuzz_corpora
> +/target/
> +/Cargo.lock
>  /GIT-BUILD-DIR
>  /GIT-BUILD-OPTIONS
>  /GIT-CFLAGS
> diff --git a/Cargo.toml b/Cargo.toml
> new file mode 100644
> index 0000000000..17a4f4da0c
> --- /dev/null
> +++ b/Cargo.toml
> @@ -0,0 +1,9 @@
> +[package]
> +name = "git"
> +version = "0.1.0"
> +edition = "2021"
> +
> +[lib]
> +crate-type = ["staticlib"]
> +
> +[dependencies]
> diff --git a/Makefile b/Makefile
> index 555b7f4dc3..e7b3c8e57b 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -483,6 +483,14 @@ include shared.mak
>  # Define LIBPCREDIR=/foo/bar if your PCRE header and library files are
>  # in /foo/bar/include and /foo/bar/lib directories.
>  #
> +# == Optional Rust support ==
> +#
> +# Define WITH_RUST if you want to include features and subsystems written in
> +# Rust into Git. For now, Rust is still an optional feature of the build
> +# process. With Git 3.0 though, Rust will always be enabled.
> +#
> +# Building Rust code requires Cargo.
> +#
>  # == SHA-1 and SHA-256 defines ==
>  #
>  # === SHA-1 backend ===
> @@ -918,6 +926,11 @@ TEST_SHELL_PATH = $(SHELL_PATH)
>  LIB_FILE = libgit.a
>  XDIFF_LIB = xdiff/lib.a
>  REFTABLE_LIB = reftable/libreftable.a
> +ifdef DEBUG
> +RUST_LIB = target/debug/libgit.a
> +else
> +RUST_LIB = target/release/libgit.a
> +endif
>
>  GENERATED_H += command-list.h
>  GENERATED_H += config-list.h
> @@ -1387,8 +1400,12 @@ CLAR_TEST_OBJS += $(UNIT_TEST_DIR)/unit-test.o
>
>  UNIT_TEST_OBJS += $(UNIT_TEST_DIR)/test-lib.o
>
> -# xdiff and reftable libs may in turn depend on what is in libgit.a
> -GITLIBS = common-main.o $(LIB_FILE) $(XDIFF_LIB) $(REFTABLE_LIB) $(LIB_FILE)
> +GITLIBS = common-main.o $(LIB_FILE) $(XDIFF_LIB) $(REFTABLE_LIB)
> +ifdef WITH_RUST
> +GITLIBS += $(RUST_LIB)
> +endif
> +# Other libs may in turn depend on what is in libgit.a.
> +GITLIBS += $(LIB_FILE)
>  EXTLIBS =
>
>  GIT_USER_AGENT = git/$(GIT_VERSION)
> @@ -1411,6 +1428,19 @@ BASIC_LDFLAGS =
>  ARFLAGS = rcs
>  PTHREAD_CFLAGS =
>
> +# Rust flags
> +CARGO_ARGS =
> +ifndef V
> +CARGO_ARGS += --quiet
> +endif
> +ifndef DEBUG
> +CARGO_ARGS += --release
> +endif
> +
> +ifdef WITH_RUST
> +BASIC_CFLAGS += -DWITH_RUST
> +endif
> +
>  # For the 'sparse' target
>  SPARSE_FLAGS ?= -std=gnu99 -D__STDC_NO_VLA__
>  SP_EXTRA_FLAGS =
> @@ -2918,6 +2948,16 @@ scalar$X: scalar.o GIT-LDFLAGS $(GITLIBS)
>  $(LIB_FILE): $(LIB_OBJS)
>         $(QUIET_AR)$(RM) $@ && $(AR) $(ARFLAGS) $@ $^
>
> +$(RUST_LIB): FORCE
> +       @OLD_STAT="$$(stat $@ 2>/dev/null)"; \
> +           cargo build $(CARGO_ARGS); \
> +           if test $$? != 0 || test x"$$OLD_STAT" != x"$$(stat $@ 2>/dev/null)"; then \
> +               echo '   ' CARGO $@; \
> +           fi
> +
> +.PHONY: rust
> +rust: $(RUST_LIB)
> +
>  $(XDIFF_LIB): $(XDIFF_OBJS)
>         $(QUIET_AR)$(RM) $@ && $(AR) $(ARFLAGS) $@ $^
>
> @@ -3768,6 +3808,7 @@ clean: profile-clean coverage-clean cocciclean
>         $(RM) $(FUZZ_PROGRAMS)
>         $(RM) $(SP_OBJ)
>         $(RM) $(HCC)
> +       $(RM) -r target/ Cargo.lock
>         $(RM) version-def.h
>         $(RM) -r $(dep_dirs) $(compdb_dir) compile_commands.json
>         $(RM) $(test_bindir_programs)
>
> --
> 2.51.0.417.g1ba7204a04.dirty

Johannes provided some additional tooling (an extra library to
download from git-for-windows) that was needed for building and
linking against Rust on Windows, which Ezekiel incorporated into his
series.  Is that not needed here for some reason, or are we just not
discovering that it's needed since you haven't created a test balloon
yet?

Re: [PATCH RFC v2 2/7] Makefile: introduce infrastructure to build internal Rust library

[Patrick Steinhardt]

On Sat, Sep 06, 2025 at 09:58:44PM -0700, Elijah Newren wrote:
> On Fri, Sep 5, 2025 at 4:51 AM Patrick Steinhardt <ps@pks.im> wrote:
> > @@ -3768,6 +3808,7 @@ clean: profile-clean coverage-clean cocciclean
> >         $(RM) $(FUZZ_PROGRAMS)
> >         $(RM) $(SP_OBJ)
> >         $(RM) $(HCC)
> > +       $(RM) -r target/ Cargo.lock
> >         $(RM) version-def.h
> >         $(RM) -r $(dep_dirs) $(compdb_dir) compile_commands.json
> >         $(RM) $(test_bindir_programs)
> >
> > --
> > 2.51.0.417.g1ba7204a04.dirty
> 
> Johannes provided some additional tooling (an extra library to
> download from git-for-windows) that was needed for building and
> linking against Rust on Windows, which Ezekiel incorporated into his
> series.  Is that not needed here for some reason, or are we just not
> discovering that it's needed since you haven't created a test balloon
> yet?

As Rust is opt-in initially we can take it slow and first land a minimum
viable change with limited platform support. So I intentionally limited
the scope for now, but once this series lands we (or I) should iterate
and also bring up other platforms.

Patrick

Re: [PATCH RFC v2 2/7] Makefile: introduce infrastructure to build internal Rust library

[SZEDER Gábor]

On Fri, Sep 05, 2025 at 01:50:58PM +0200, Patrick Steinhardt wrote:
> Introduce infrastructure to build the internal Rust library. This
> mirrors the infrastructure we have added to Meson in the preceding
> commit. Developers can enable the infrastructure by passing the new
> `WITH_RUST` build toggle.
> 
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
>  .gitignore |  2 ++
>  Cargo.toml |  9 +++++++++
>  Makefile   | 45 +++++++++++++++++++++++++++++++++++++++++++--
>  3 files changed, 54 insertions(+), 2 deletions(-)

> diff --git a/Makefile b/Makefile
> index 555b7f4dc3..e7b3c8e57b 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -483,6 +483,14 @@ include shared.mak
>  # Define LIBPCREDIR=/foo/bar if your PCRE header and library files are
>  # in /foo/bar/include and /foo/bar/lib directories.
>  #
> +# == Optional Rust support ==
> +#
> +# Define WITH_RUST if you want to include features and subsystems written in
> +# Rust into Git. For now, Rust is still an optional feature of the build
> +# process. With Git 3.0 though, Rust will always be enabled.
> +#
> +# Building Rust code requires Cargo.
> +#
>  # == SHA-1 and SHA-256 defines ==
>  #
>  # === SHA-1 backend ===
> @@ -918,6 +926,11 @@ TEST_SHELL_PATH = $(SHELL_PATH)
>  LIB_FILE = libgit.a
>  XDIFF_LIB = xdiff/lib.a
>  REFTABLE_LIB = reftable/libreftable.a
> +ifdef DEBUG
> +RUST_LIB = target/debug/libgit.a
> +else
> +RUST_LIB = target/release/libgit.a
> +endif
>  
>  GENERATED_H += command-list.h
>  GENERATED_H += config-list.h
> @@ -1387,8 +1400,12 @@ CLAR_TEST_OBJS += $(UNIT_TEST_DIR)/unit-test.o
>  
>  UNIT_TEST_OBJS += $(UNIT_TEST_DIR)/test-lib.o
>  
> -# xdiff and reftable libs may in turn depend on what is in libgit.a
> -GITLIBS = common-main.o $(LIB_FILE) $(XDIFF_LIB) $(REFTABLE_LIB) $(LIB_FILE)
> +GITLIBS = common-main.o $(LIB_FILE) $(XDIFF_LIB) $(REFTABLE_LIB)
> +ifdef WITH_RUST
> +GITLIBS += $(RUST_LIB)
> +endif
> +# Other libs may in turn depend on what is in libgit.a.
> +GITLIBS += $(LIB_FILE)
>  EXTLIBS =
>  
>  GIT_USER_AGENT = git/$(GIT_VERSION)
> @@ -1411,6 +1428,19 @@ BASIC_LDFLAGS =
>  ARFLAGS = rcs
>  PTHREAD_CFLAGS =
>  
> +# Rust flags
> +CARGO_ARGS =
> +ifndef V
> +CARGO_ARGS += --quiet
> +endif
> +ifndef DEBUG
> +CARGO_ARGS += --release
> +endif
> +
> +ifdef WITH_RUST
> +BASIC_CFLAGS += -DWITH_RUST
> +endif
> +
>  # For the 'sparse' target
>  SPARSE_FLAGS ?= -std=gnu99 -D__STDC_NO_VLA__
>  SP_EXTRA_FLAGS =
> @@ -2918,6 +2948,16 @@ scalar$X: scalar.o GIT-LDFLAGS $(GITLIBS)
>  $(LIB_FILE): $(LIB_OBJS)
>  	$(QUIET_AR)$(RM) $@ && $(AR) $(ARFLAGS) $@ $^
>  
> +$(RUST_LIB): FORCE

Why is this target FORCE-d instead of declaring its dependencies?

> +	@OLD_STAT="$$(stat $@ 2>/dev/null)"; \
> +	    cargo build $(CARGO_ARGS); \
> +	    if test $$? != 0 || test x"$$OLD_STAT" != x"$$(stat $@ 2>/dev/null)"; then \
> +		echo '   ' CARGO $@; \
> +	    fi

This hides 'cargo's exit code from 'make', so a failure to build the
Rust components won't abort the build.  So once we have a successfully
built Rust library and were to inadvertently introduce a syntax error
into the Rust code:

  $ echo foo >src/varint.rs 
  $ make WITH_RUST=1
  error: expected one of `!` or `::`, found `<eof>`
   --> src/varint.rs:1:1
    |
  1 | foo
    | ^^^ expected one of `!` or `::`

  error: could not compile `git` (lib) due to previous error
      CARGO target/release/libgit.a
      SUBDIR git-gui
      SUBDIR gitk-git
      SUBDIR templates
  $ echo $?
  0

Also note that the error message is printed before the command that
produced that error; it should be the other way around.

> +
> +.PHONY: rust
> +rust: $(RUST_LIB)
> +
>  $(XDIFF_LIB): $(XDIFF_OBJS)
>  	$(QUIET_AR)$(RM) $@ && $(AR) $(ARFLAGS) $@ $^
>  
> @@ -3768,6 +3808,7 @@ clean: profile-clean coverage-clean cocciclean
>  	$(RM) $(FUZZ_PROGRAMS)
>  	$(RM) $(SP_OBJ)
>  	$(RM) $(HCC)
> +	$(RM) -r target/ Cargo.lock
>  	$(RM) version-def.h
>  	$(RM) -r $(dep_dirs) $(compdb_dir) compile_commands.json
>  	$(RM) $(test_bindir_programs)
> 
> -- 
> 2.51.0.417.g1ba7204a04.dirty
> 

Re: [PATCH RFC v2 2/7] Makefile: introduce infrastructure to build internal Rust library

[Patrick Steinhardt]

On Sun, Sep 07, 2025 at 05:26:53PM +0200, SZEDER Gábor wrote:
> On Fri, Sep 05, 2025 at 01:50:58PM +0200, Patrick Steinhardt wrote:
> > diff --git a/Makefile b/Makefile
> > index 555b7f4dc3..e7b3c8e57b 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -2918,6 +2948,16 @@ scalar$X: scalar.o GIT-LDFLAGS $(GITLIBS)
> >  $(LIB_FILE): $(LIB_OBJS)
> >  	$(QUIET_AR)$(RM) $@ && $(AR) $(ARFLAGS) $@ $^
> >  
> > +$(RUST_LIB): FORCE
> 
> Why is this target FORCE-d instead of declaring its dependencies?

I was mostly doing that because cargo itself doesn't take any arguments,
so it's quite easy for the list to grow stale. Let me adapt it though to
take proper dependencies for now.

Patrick

[PATCH RFC v2 3/7] help: report on whether or not Rust is enabled

[Patrick Steinhardt]

We're about to introduce support for Rust into the core of Git, where
some (trivial) subsystems are converted to Rust. These subsystems will
also retain a C implementation though as Rust is not yet mandatory.
Consequently, it now becomes possible for a Git version to have bugs
that are specific to whether or not it is built with Rust support
overall.

Expose information about whether or not Git was built with Rust via our
build info. This means that both `git version --build-options`, but also
`git bugreport` will now expose that bit of information. Hopefully, this
should make it easier for us to discover any Rust-specific issues.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 help.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/help.c b/help.c
index bb20498cfd..5854dd4a7e 100644
--- a/help.c
+++ b/help.c
@@ -791,6 +791,12 @@ void get_version_info(struct strbuf *buf, int show_build_options)
 		strbuf_addf(buf, "shell-path: %s\n", SHELL_PATH);
 		/* NEEDSWORK: also save and output GIT-BUILD_OPTIONS? */
 
+#if defined WITH_RUST
+		strbuf_addstr(buf, "rust: enabled\n");
+#else
+		strbuf_addstr(buf, "rust: disabled\n");
+#endif
+
 		if (fsmonitor_ipc__is_supported())
 			strbuf_addstr(buf, "feature: fsmonitor--daemon\n");
 #if defined LIBCURL_VERSION

-- 
2.51.0.417.g1ba7204a04.dirty

Re: [PATCH RFC v2 3/7] help: report on whether or not Rust is enabled

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 662 bytes --]

On 2025-09-05 at 11:50:59, Patrick Steinhardt wrote:
> diff --git a/help.c b/help.c
> index bb20498cfd..5854dd4a7e 100644
> --- a/help.c
> +++ b/help.c
> @@ -791,6 +791,12 @@ void get_version_info(struct strbuf *buf, int show_build_options)
>  		strbuf_addf(buf, "shell-path: %s\n", SHELL_PATH);
>  		/* NEEDSWORK: also save and output GIT-BUILD_OPTIONS? */
>  
> +#if defined WITH_RUST
> +		strbuf_addstr(buf, "rust: enabled\n");
> +#else
> +		strbuf_addstr(buf, "rust: disabled\n");
> +#endif
> +

I think this is a great idea and likely to be super helpful.  Thanks for
including it.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [PATCH RFC v2 3/7] help: report on whether or not Rust is enabled

[Elijah Newren]

On Fri, Sep 5, 2025 at 12:51 PM brian m. carlson
<sandals@crustytoothpaste.net> wrote:
>
> On 2025-09-05 at 11:50:59, Patrick Steinhardt wrote:
> > diff --git a/help.c b/help.c
> > index bb20498cfd..5854dd4a7e 100644
> > --- a/help.c
> > +++ b/help.c
> > @@ -791,6 +791,12 @@ void get_version_info(struct strbuf *buf, int show_build_options)
> >               strbuf_addf(buf, "shell-path: %s\n", SHELL_PATH);
> >               /* NEEDSWORK: also save and output GIT-BUILD_OPTIONS? */
> >
> > +#if defined WITH_RUST
> > +             strbuf_addstr(buf, "rust: enabled\n");
> > +#else
> > +             strbuf_addstr(buf, "rust: disabled\n");
> > +#endif
> > +
>
> I think this is a great idea and likely to be super helpful.  Thanks for
> including it.

Agreed, this is nice attention to detail that I would have overlooked.
Much appreciated.

[PATCH RFC v2 4/7] rust: implement a test balloon via the "varint" subsystem

[Patrick Steinhardt]

Implement a trivial test balloon for our Rust build infrastructure by
reimplementing the "varint.c" subsystem in Rust. This subsystem is
chosen because it is trivial to convert and because it doesn't have any
dependencies to other components of Git.

If support for Rust is enabled, we stop compiling "varint.c" and instead
compile and use "src/varint.rs".

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 Makefile        |  2 ++
 meson.build     |  5 +++-
 src/lib.rs      |  1 +
 src/meson.build |  1 +
 src/varint.rs   | 92 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 100 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index e7b3c8e57bf..8fd13a36db9 100644
--- a/Makefile
+++ b/Makefile
@@ -1209,7 +1209,9 @@ LIB_OBJS += urlmatch.o
 LIB_OBJS += usage.o
 LIB_OBJS += userdiff.o
 LIB_OBJS += utf8.o
+ifndef WITH_RUST
 LIB_OBJS += varint.o
+endif
 LIB_OBJS += version.o
 LIB_OBJS += versioncmp.o
 LIB_OBJS += walker.o
diff --git a/meson.build b/meson.build
index 5b2e9af1bf1..da9a8c8dea0 100644
--- a/meson.build
+++ b/meson.build
@@ -522,7 +522,6 @@ libgit_sources = [
   'usage.c',
   'userdiff.c',
   'utf8.c',
-  'varint.c',
   'version.c',
   'versioncmp.c',
   'walker.c',
@@ -1709,6 +1708,10 @@ rust_option = get_option('rust').disable_auto_if(not rust_available)
 if rust_option.allowed()
   subdir('src')
   libgit_c_args += '-DWITH_RUST'
+else
+  libgit_sources += [
+    'varint.c',
+  ]
 endif
 
 libgit = declare_dependency(
diff --git a/src/lib.rs b/src/lib.rs
index e69de29bb2d..9da70d8b57d 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -0,0 +1 @@
+pub mod varint;
diff --git a/src/meson.build b/src/meson.build
index eb752651d35..4fc793fb17d 100644
--- a/src/meson.build
+++ b/src/meson.build
@@ -1,6 +1,7 @@
 libgit_rs = static_library('git_rs',
   sources: [
     'lib.rs',
+    'varint.rs',
   ],
   rust_crate_type: 'staticlib',
 )
diff --git a/src/varint.rs b/src/varint.rs
new file mode 100644
index 00000000000..3d41760a555
--- /dev/null
+++ b/src/varint.rs
@@ -0,0 +1,92 @@
+use std::os::raw::c_int;
+use std::os::raw::c_uchar;
+
+#[no_mangle]
+pub unsafe extern "C" fn decode_varint(bufp: *mut *const c_uchar) -> usize {
+    let mut buf = *bufp;
+    let mut c = *buf;
+    let mut val = usize::from(c & 127);
+
+    buf = buf.add(1);
+
+    while (c & 128) != 0 {
+        val += 1;
+        if val == 0 || val.leading_zeros() < 7 {
+            return 0; // overflow
+        }
+
+        c = *buf;
+        buf = buf.add(1);
+
+        val = (val << 7) + usize::from(c & 127);
+    }
+
+    *bufp = buf;
+    val
+}
+
+#[no_mangle]
+pub unsafe extern "C" fn encode_varint(value: usize, buf: *mut c_uchar) -> c_int {
+    let mut varint: [u8; 16] = [0; 16];
+    let mut pos = varint.len() - 1;
+
+    varint[pos] = (value & 127) as u8;
+
+    let mut value = value >> 7;
+    while value != 0 {
+        pos -= 1;
+        value -= 1;
+        varint[pos] = 128 | (value & 127) as u8;
+        value >>= 7;
+    }
+
+    if !buf.is_null() {
+        std::ptr::copy_nonoverlapping(varint.as_ptr().add(pos), buf, varint.len() - pos);
+    }
+
+    (varint.len() - pos) as c_int
+}
+
+#[cfg(test)]
+mod tests {
+    use super::*;
+
+    #[test]
+    fn test_decode_varint() {
+        unsafe {
+            assert_eq!(decode_varint(&mut [0x00].as_slice().as_ptr()), 0);
+            assert_eq!(decode_varint(&mut [0x01].as_slice().as_ptr()), 1);
+            assert_eq!(decode_varint(&mut [0x7f].as_slice().as_ptr()), 127);
+            assert_eq!(decode_varint(&mut [0x80, 0x00].as_slice().as_ptr()), 128);
+            assert_eq!(decode_varint(&mut [0x80, 0x01].as_slice().as_ptr()), 129);
+            assert_eq!(decode_varint(&mut [0x80, 0x7f].as_slice().as_ptr()), 255);
+        }
+    }
+
+    #[test]
+    fn test_encode_varint() {
+        unsafe {
+            let mut varint: [u8; 16] = [0; 16];
+
+            assert_eq!(encode_varint(0, std::ptr::null_mut()), 1);
+
+            assert_eq!(encode_varint(0, varint.as_mut_slice().as_mut_ptr()), 1);
+            assert_eq!(varint, [0; 16]);
+
+            assert_eq!(encode_varint(10, varint.as_mut_slice().as_mut_ptr()), 1);
+            assert_eq!(varint, [10, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+
+            assert_eq!(encode_varint(127, varint.as_mut_slice().as_mut_ptr()), 1);
+            assert_eq!(varint, [127, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+
+            assert_eq!(encode_varint(128, varint.as_mut_slice().as_mut_ptr()), 2);
+            assert_eq!(varint, [128, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+
+            assert_eq!(encode_varint(129, varint.as_mut_slice().as_mut_ptr()), 2);
+            assert_eq!(varint, [128, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+
+            assert_eq!(encode_varint(255, varint.as_mut_slice().as_mut_ptr()), 2);
+            assert_eq!(varint, [128, 127, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+        }
+    }
+}

-- 
2.51.0.417.g1ba7204a04.dirty

Re: [PATCH RFC v2 4/7] rust: implement a test balloon via the "varint" subsystem

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

> diff --git a/src/varint.rs b/src/varint.rs
> new file mode 100644
> index 00000000000..3d41760a555
> --- /dev/null
> +++ b/src/varint.rs
> @@ -0,0 +1,92 @@
> +use std::os::raw::c_int;
> +use std::os::raw::c_uchar;
> +
> +#[no_mangle]
> +pub unsafe extern "C" fn decode_varint(bufp: *mut *const c_uchar) -> usize {
> +    let mut buf = *bufp;
> +    let mut c = *buf;
> +    let mut val = usize::from(c & 127);
> +
> +    buf = buf.add(1);
> +
> +    while (c & 128) != 0 {
> +        val += 1;
> +        if val == 0 || val.leading_zeros() < 7 {
> +            return 0; // overflow
> +        }
> +
> +        c = *buf;
> +        buf = buf.add(1);
> +
> +        val = (val << 7) + usize::from(c & 127);
> +    }
> +
> +    *bufp = buf;
> +    val
> +}

This (and the encoding side) looks quite faithful translation of the
original in C.  Interestingly, disassembly I saw looked a lot more
optimized than the C variant compiled with clang-19 -O2.  The
difference probably is largely due to its omitting frame pointer.

The comparison to detect overflow compiled to direct comparison with
0x1ffffffffffffff (both in C and rustc/LLVM), which was amusing,
too.

Re: [PATCH RFC v2 4/7] rust: implement a test balloon via the "varint" subsystem

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> ...  Interestingly, disassembly I saw looked a lot more
> optimized than the C variant compiled with clang-19 -O2.

That was a false alarm.  With right compilation option passed, C
version of decode_varint() compiled to identical assembly as what
rustc/llvm produced.

Re: [PATCH RFC v2 4/7] rust: implement a test balloon via the "varint" subsystem

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1091 bytes --]

On 2025-09-05 at 22:39:12, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> 
> > ...  Interestingly, disassembly I saw looked a lot more
> > optimized than the C variant compiled with clang-19 -O2.
> 
> That was a false alarm.  With right compilation option passed, C
> version of decode_varint() compiled to identical assembly as what
> rustc/llvm produced.

That's not unexpected, I'd say, especially since the code is very
similar and uses very similar data structures, including pointers.

However, as we adopt Rust more in the future, we may see some
performance optimizations because Rust allows making more guarantees
about data.  For instance, the C compiler must deal with the fact that
you can cast a const pointer to a non-const pointer, but Rust does not
allow you cast or transmute an immutable slice to a mutable one or
access it mutably at the same time, so the compiler can then assume that
the data will not be modified, including by another thread, and optimize
accordingly.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

[PATCH RFC v2 5/7] BreakingChanges: announce Rust becoming mandatory

[Patrick Steinhardt]

Over the last couple of years the appetite for bringin Rust into the
codebase has grown significantly across the developer base. Introducing
Rust is a major change though and has ramifications for the whole
ecosystem:

  - Some platforms haven't yet been able to implement a Rust toolchain,
    even though it is possible in theory.

  - Some platforms don't have any support for Rust at all.

  - Some platforms may have to figure out how to fit Rust into their
    bootstrapping sequence.

Due to this, and given that Git is a critical piece of infrastructure
for the whole industry, we cannot just introduce such a heavyweight
dependency without doing our due diligence.

Instead, preceding commits have introduced a test balloon into our build
infrastructure that convert one tiny subsystem to use Rust. For now,
using Rust to build that subsystem is entirely optional -- if no Rust
support is available, we continue to use the C implementation. This test
balloon has the intention to give distributions time and let them ease
into our adoption of Rust.

Having multiple implementations of the same subsystem is not sustainable
though, and the plan is to eventually be able to use Rust freely all
across our codebase. As such, there is the intent to make Rust become a
mandatory part of our build process.

Add an announcement to our breaking changes that Rust will become
mandatory in Git 3.0. A (very careful and non-binding) estimate might be
that this major release might be released in the second half of next
year, which should give distributors enough time to prepare for the
change.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 Documentation/BreakingChanges.adoc | 36 ++++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/Documentation/BreakingChanges.adoc b/Documentation/BreakingChanges.adoc
index f8d2eba061..dbb15b6a57 100644
--- a/Documentation/BreakingChanges.adoc
+++ b/Documentation/BreakingChanges.adoc
@@ -165,6 +165,42 @@ A prerequisite for this change is that the ecosystem is ready to support the
 "reftable" format. Most importantly, alternative implementations of Git like
 JGit, libgit2 and Gitoxide need to support it.
 
+* Git will require Rust as a mandatory part of the build process. While Git
+  already started to adopt Rust in the Git 2.52, all parts written in Rust are
+  optional for the time being. This includes:
++
+  ** Subsystems that have an alternative implementation in Rust to test
+     interoperability between our C and Rust codebase.
+  ** Newly written features that are not mission critical for a fully functional
+     Git client.
++
+These changes are meant as test balloons to allow distributors of Git to prepare
+for Rust becoming a mandatory part of the build process. There will be multiple
+milestones for the introduction of Rust:
++
+1. Initially, with Git 2.52, support for Rust will be auto-detected by Rust and
+   disabled in our Makefile so that the project can sort out the initial
+   infrastructure.
+2. In Git 2.53, support for Rust will be made mandatory in case Git is compiled
+   with breaking changes. Breaking changes can be enabled for Meson by saying
+   `meson configure -Dbreaking_changes=true` and for Makefiles via `make
+   WITH_BREAKING_CHANGES=YesPlease`. It will still be possible to compile with
+   breaking changes, but explicitly disable Rust.
+3. In Git 2.54, both build systems will default-enable support for Rust so that
+   builds will break if Rust is not available on the build host. The use of Rust
+   can still be explicitly disabled via build flags.
+4. In Git 3.0, the build options will be removed and support for Rust is
+   mandatory.
++
+You can explicitly ask both Meson and our Makefile-based system to enable Rust
+by saying `meson configure -Drust=enabled` and `make WITH_RUST=YesPlease`,
+respectively.
++
+The Git project will declare the last version before Git 3.0 to be a long-term
+support release that is maintained until alternate Rust backends like gcc-rs are
+able to build Git. The Git project may need to rely on distributions to help
+with identifying and backporting important bugfixes.
+
 === Removals
 
 * Support for grafting commits has long been superseded by git-replace(1).

-- 
2.51.0.417.g1ba7204a04.dirty

Re: [PATCH RFC v2 5/7] BreakingChanges: announce Rust becoming mandatory

[Matthias Aßhauer]

On Fri, 5 Sep 2025, Patrick Steinhardt wrote:

> Over the last couple of years the appetite for bringin Rust into the
> codebase has grown significantly across the developer base. Introducing
> Rust is a major change though and has ramifications for the whole
> ecosystem:
>
>  - Some platforms haven't yet been able to implement a Rust toolchain,
>    even though it is possible in theory.
>
>  - Some platforms don't have any support for Rust at all.

What's the difference between these two kinds of platform? It should be 
theoretically possible to build rust tooling for all of them, right?

>  - Some platforms may have to figure out how to fit Rust into their
>    bootstrapping sequence.
>
> Due to this, and given that Git is a critical piece of infrastructure
> for the whole industry, we cannot just introduce such a heavyweight
> dependency without doing our due diligence.
>
> Instead, preceding commits have introduced a test balloon into our build
> infrastructure that convert one tiny subsystem to use Rust. For now,
> using Rust to build that subsystem is entirely optional -- if no Rust
> support is available, we continue to use the C implementation. This test
> balloon has the intention to give distributions time and let them ease
> into our adoption of Rust.
>
> Having multiple implementations of the same subsystem is not sustainable
> though, and the plan is to eventually be able to use Rust freely all
> across our codebase. As such, there is the intent to make Rust become a
> mandatory part of our build process.
>
> Add an announcement to our breaking changes that Rust will become
> mandatory in Git 3.0. A (very careful and non-binding) estimate might be
> that this major release might be released in the second half of next
> year, which should give distributors enough time to prepare for the
> change.
>
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
> Documentation/BreakingChanges.adoc | 36 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/Documentation/BreakingChanges.adoc b/Documentation/BreakingChanges.adoc
> index f8d2eba061..dbb15b6a57 100644
> --- a/Documentation/BreakingChanges.adoc
> +++ b/Documentation/BreakingChanges.adoc
> @@ -165,6 +165,42 @@ A prerequisite for this change is that the ecosystem is ready to support the
> "reftable" format. Most importantly, alternative implementations of Git like
> JGit, libgit2 and Gitoxide need to support it.
>
> +* Git will require Rust as a mandatory part of the build process. While Git
> +  already started to adopt Rust in the Git 2.52, all parts written in Rust are
> +  optional for the time being. This includes:
> ++
> +  ** Subsystems that have an alternative implementation in Rust to test
> +     interoperability between our C and Rust codebase.
> +  ** Newly written features that are not mission critical for a fully functional
> +     Git client.
> ++
> +These changes are meant as test balloons to allow distributors of Git to prepare
> +for Rust becoming a mandatory part of the build process. There will be multiple
> +milestones for the introduction of Rust:
> ++
> +1. Initially, with Git 2.52, support for Rust will be auto-detected by Rust and

Support for Rust will be detected by Rust? Should that say "by Meson"?

> +   disabled in our Makefile so that the project can sort out the initial
> +   infrastructure.
> +2. In Git 2.53, support for Rust will be made mandatory in case Git is compiled
> +   with breaking changes. Breaking changes can be enabled for Meson by saying
> +   `meson configure -Dbreaking_changes=true` and for Makefiles via `make
> +   WITH_BREAKING_CHANGES=YesPlease`. It will still be possible to compile with
> +   breaking changes, but explicitly disable Rust.

Mandatory, but not mandatory? opt-out?

> +3. In Git 2.54, both build systems will default-enable support for Rust so that
> +   builds will break if Rust is not available on the build host. The use of Rust
> +   can still be explicitly disabled via build flags.

I assume you mean that we will default to building with Rust, even when 
building without breaking changes, but I feel like the wording could be 
more explicit.

Assuming packagers read this when 2.52 is released, 2.54 would give them 
roughly 16-26 ish weeks of a heads up, assuming our typical 8-13 week 
development cycles.

> +4. In Git 3.0, the build options will be removed and support for Rust is
> +   mandatory.
> ++
> +You can explicitly ask both Meson and our Makefile-based system to enable Rust
> +by saying `meson configure -Drust=enabled` and `make WITH_RUST=YesPlease`,
> +respectively.
> ++
> +The Git project will declare the last version before Git 3.0 to be a long-term
> +support release that is maintained until alternate Rust backends like gcc-rs are
> +able to build Git. The Git project may need to rely on distributions to help

Do we want to commit to promising support until gccrs is ready? What if 
gccrs ends up abandoned? Or takes an unexpectedly long time to reach a 
stage where it can build Git? It might make sense to give this LTS release 
a time limit instead, or in addidtion.

> +with identifying and backporting important bugfixes.
> +
> === Removals
>
> * Support for grafting commits has long been superseded by git-replace(1).
>
> -- 
> 2.51.0.417.g1ba7204a04.dirty
>
>

Re: [PATCH RFC v2 5/7] BreakingChanges: announce Rust becoming mandatory

[Patrick Steinhardt]

On Fri, Sep 05, 2025 at 02:45:46PM +0200, Matthias Aßhauer wrote:
> On Fri, 5 Sep 2025, Patrick Steinhardt wrote:
> > Over the last couple of years the appetite for bringin Rust into the
> > codebase has grown significantly across the developer base. Introducing
> > Rust is a major change though and has ramifications for the whole
> > ecosystem:
> > 
> >  - Some platforms haven't yet been able to implement a Rust toolchain,
> >    even though it is possible in theory.
> > 
> >  - Some platforms don't have any support for Rust at all.
> 
> What's the difference between these two kinds of platform? It should be
> theoretically possible to build rust tooling for all of them, right?

The first platform is something where Rust just hasn't been wired up
yet. This involves for Cygwin, or the Darwin ports of Gentoo's portage
tree. Rust is available for those platforms in theory, but in practice
it's not there yet.

The second platform is where there is no Rust compiler available at all.
So for example NonStop, Intel Itanium, Alpha.

I'll try to clarify this in the next version.

> > diff --git a/Documentation/BreakingChanges.adoc b/Documentation/BreakingChanges.adoc
> > index f8d2eba061..dbb15b6a57 100644
> > --- a/Documentation/BreakingChanges.adoc
> > +++ b/Documentation/BreakingChanges.adoc
> > @@ -165,6 +165,42 @@ A prerequisite for this change is that the ecosystem is ready to support the
> > "reftable" format. Most importantly, alternative implementations of Git like
> > JGit, libgit2 and Gitoxide need to support it.
> > 
> > +* Git will require Rust as a mandatory part of the build process. While Git
> > +  already started to adopt Rust in the Git 2.52, all parts written in Rust are
> > +  optional for the time being. This includes:
> > ++
> > +  ** Subsystems that have an alternative implementation in Rust to test
> > +     interoperability between our C and Rust codebase.
> > +  ** Newly written features that are not mission critical for a fully functional
> > +     Git client.
> > ++
> > +These changes are meant as test balloons to allow distributors of Git to prepare
> > +for Rust becoming a mandatory part of the build process. There will be multiple
> > +milestones for the introduction of Rust:
> > ++
> > +1. Initially, with Git 2.52, support for Rust will be auto-detected by Rust and
> 
> Support for Rust will be detected by Rust? Should that say "by Meson"?

Ah, yes.

> > +   disabled in our Makefile so that the project can sort out the initial
> > +   infrastructure.
> > +2. In Git 2.53, support for Rust will be made mandatory in case Git is compiled
> > +   with breaking changes. Breaking changes can be enabled for Meson by saying
> > +   `meson configure -Dbreaking_changes=true` and for Makefiles via `make
> > +   WITH_BREAKING_CHANGES=YesPlease`. It will still be possible to compile with
> > +   breaking changes, but explicitly disable Rust.
> 
> Mandatory, but not mandatory? opt-out?

True, this reads a bit awkward.

> > +3. In Git 2.54, both build systems will default-enable support for Rust so that
> > +   builds will break if Rust is not available on the build host. The use of Rust
> > +   can still be explicitly disabled via build flags.
> 
> I assume you mean that we will default to building with Rust, even when
> building without breaking changes, but I feel like the wording could be more
> explicit.
> 
> Assuming packagers read this when 2.52 is released, 2.54 would give them
> roughly 16-26 ish weeks of a heads up, assuming our typical 8-13 week
> development cycles.

Ok.

Does this revised version of the plan read better to you?

    1. Initially, with Git 2.52, support for Rust will be auto-detected by Meson and
       disabled in our Makefile so that the project can sort out the initial
       infrastructure.
    2. In Git 2.53, support for Rust will be enabled by default in case Git is
       compiled with breaking changes. Breaking changes can be enabled for Meson by
       saying `meson configure -Dbreaking_changes=true` and for Makefile-based
       builds via `make WITH_BREAKING_CHANGES=YesPlease`. It will still be possible
       to compile with breaking changes, but explicitly disable Rust.
    3. In Git 2.54, both build systems will default-enable support for Rust even
       when breaking changes aren't enabled. Consequently, builds will break by
       default if Rust is not available on the build host. The use of Rust can still
       be explicitly disabled via build flags.
    4. In Git 3.0, the build options will be removed and support for Rust is
       mandatory.

> > +4. In Git 3.0, the build options will be removed and support for Rust is
> > +   mandatory.
> > ++
> > +You can explicitly ask both Meson and our Makefile-based system to enable Rust
> > +by saying `meson configure -Drust=enabled` and `make WITH_RUST=YesPlease`,
> > +respectively.
> > ++
> > +The Git project will declare the last version before Git 3.0 to be a long-term
> > +support release that is maintained until alternate Rust backends like gcc-rs are
> > +able to build Git. The Git project may need to rely on distributions to help
> 
> Do we want to commit to promising support until gccrs is ready? What if
> gccrs ends up abandoned? Or takes an unexpectedly long time to reach a stage
> where it can build Git? It might make sense to give this LTS release a time
> limit instead, or in addidtion.

Yeah, I wasn't quite clear on that one, either. An alternative:

  - We will maintain the LTS release for 8 release cycles, which equates
    to roughly two years. It sounds like a lot, but recent security
    releases have stretched quite far into the past.

  - If there are still dependents after these two years we will hand
    over maintainership of the LTS branch to dependents. So they will be
    responsible for the backporting.

This really only is a suggestion though. I'm especially waiting for
Junio's feedback here to see whether he thinks that this is a reasonable
thing to do.

Patrick

Re: [PATCH RFC v2 5/7] BreakingChanges: announce Rust becoming mandatory

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 1324 bytes --]

On 9/5/25 9:38 AM, Patrick Steinhardt wrote:

>> Do we want to commit to promising support until gccrs is ready? What if
>> gccrs ends up abandoned? Or takes an unexpectedly long time to reach a stage
>> where it can build Git? It might make sense to give this LTS release a time
>> limit instead, or in addidtion.
> 
> Yeah, I wasn't quite clear on that one, either. An alternative:
> 
>   - We will maintain the LTS release for 8 release cycles, which equates
>     to roughly two years. It sounds like a lot, but recent security
>     releases have stretched quite far into the past.
> 
>   - If there are still dependents after these two years we will hand
>     over maintainership of the LTS branch to dependents. So they will be
>     responsible for the backporting.
> 
> This really only is a suggestion though. I'm especially waiting for
> Junio's feedback here to see whether he thinks that this is a reasonable
> thing to do.


This seems reasonable to me -- people who still need that LTS should be
allowed to ensure it still works, and be expected to commit to the bit
-- but with the emphasis that I would consider it absolutely mandatory
that the git project accepts to host that branch, and it won't just
exist in some other shadowy corner of the internet.


-- 
Eli Schwartz

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [PATCH RFC v2 5/7] BreakingChanges: announce Rust becoming mandatory

[Patrick Steinhardt]

On Fri, Sep 05, 2025 at 10:38:16AM -0400, Eli Schwartz wrote:
> On 9/5/25 9:38 AM, Patrick Steinhardt wrote:
> 
> >> Do we want to commit to promising support until gccrs is ready? What if
> >> gccrs ends up abandoned? Or takes an unexpectedly long time to reach a stage
> >> where it can build Git? It might make sense to give this LTS release a time
> >> limit instead, or in addidtion.
> > 
> > Yeah, I wasn't quite clear on that one, either. An alternative:
> > 
> >   - We will maintain the LTS release for 8 release cycles, which equates
> >     to roughly two years. It sounds like a lot, but recent security
> >     releases have stretched quite far into the past.
> > 
> >   - If there are still dependents after these two years we will hand
> >     over maintainership of the LTS branch to dependents. So they will be
> >     responsible for the backporting.
> > 
> > This really only is a suggestion though. I'm especially waiting for
> > Junio's feedback here to see whether he thinks that this is a reasonable
> > thing to do.
> 
> 
> This seems reasonable to me -- people who still need that LTS should be
> allowed to ensure it still works, and be expected to commit to the bit
> -- but with the emphasis that I would consider it absolutely mandatory
> that the git project accepts to host that branch, and it won't just
> exist in some other shadowy corner of the internet.

Oh, yes, that's what I meant to imply. We hand over maintainership, but
it should ultimately still be sent to the Git mailing list, have proper
reviews and be merged by Junio.

I'll reword this accordingly.

Patrick

Re: [PATCH RFC v2 5/7] BreakingChanges: announce Rust becoming mandatory

[Elijah Newren]

On Fri, Sep 5, 2025 at 6:38 AM Patrick Steinhardt <ps@pks.im> wrote:
>
> On Fri, Sep 05, 2025 at 02:45:46PM +0200, Matthias Aßhauer wrote:

> > Do we want to commit to promising support until gccrs is ready? What if
> > gccrs ends up abandoned? Or takes an unexpectedly long time to reach a stage
> > where it can build Git? It might make sense to give this LTS release a time
> > limit instead, or in addidtion.
>
> Yeah, I wasn't quite clear on that one, either. An alternative:
>
>   - We will maintain the LTS release for 8 release cycles, which equates
>     to roughly two years. It sounds like a lot, but recent security
>     releases have stretched quite far into the past.
>
>   - If there are still dependents after these two years we will hand
>     over maintainership of the LTS branch to dependents. So they will be
>     responsible for the backporting.
>
> This really only is a suggestion though. I'm especially waiting for
> Junio's feedback here to see whether he thinks that this is a reasonable
> thing to do.

Over at https://lore.kernel.org/git/xmqqplc43o7c.fsf@gitster.g/, Junio
said multiple years isn't something he's willing to promise, but
suggests 18 months might be doable.

I have a suspicion that if you want a promised level of support,
you'll not only get something less than what distributors want, but
something far less than we'll provide in practice.  I'm curious if the
alternative wording over at
https://lore.kernel.org/git/CABPp-BG3Zcw63vNziy86MvYNubefn1SmPvXefpqpA=a+42KT8A@mail.gmail.com/
is more likely to be realistic:

"We'll weigh the severity of each security issue and the cost to
backport and give the last C-only version significant extra weight in
our considerations"

I know it may not be what distributors want, but overpromising also
has deleterious effects, so...

Re: [PATCH RFC v2 5/7] BreakingChanges: announce Rust becoming mandatory

[Patrick Steinhardt]

On Sat, Sep 06, 2025 at 10:31:07PM -0700, Elijah Newren wrote:
> On Fri, Sep 5, 2025 at 6:38 AM Patrick Steinhardt <ps@pks.im> wrote:
> >
> > On Fri, Sep 05, 2025 at 02:45:46PM +0200, Matthias Aßhauer wrote:
> 
> > > Do we want to commit to promising support until gccrs is ready? What if
> > > gccrs ends up abandoned? Or takes an unexpectedly long time to reach a stage
> > > where it can build Git? It might make sense to give this LTS release a time
> > > limit instead, or in addidtion.
> >
> > Yeah, I wasn't quite clear on that one, either. An alternative:
> >
> >   - We will maintain the LTS release for 8 release cycles, which equates
> >     to roughly two years. It sounds like a lot, but recent security
> >     releases have stretched quite far into the past.
> >
> >   - If there are still dependents after these two years we will hand
> >     over maintainership of the LTS branch to dependents. So they will be
> >     responsible for the backporting.
> >
> > This really only is a suggestion though. I'm especially waiting for
> > Junio's feedback here to see whether he thinks that this is a reasonable
> > thing to do.
> 
> Over at https://lore.kernel.org/git/xmqqplc43o7c.fsf@gitster.g/, Junio
> said multiple years isn't something he's willing to promise, but
> suggests 18 months might be doable.
> 
> I have a suspicion that if you want a promised level of support,
> you'll not only get something less than what distributors want, but
> something far less than we'll provide in practice.  I'm curious if the
> alternative wording over at
> https://lore.kernel.org/git/CABPp-BG3Zcw63vNziy86MvYNubefn1SmPvXefpqpA=a+42KT8A@mail.gmail.com/
> is more likely to be realistic:
> 
> "We'll weigh the severity of each security issue and the cost to
> backport and give the last C-only version significant extra weight in
> our considerations"
> 
> I know it may not be what distributors want, but overpromising also
> has deleterious effects, so...

I think at least for the security releases we should promise to handle
those. I do not think it's sensible to have a release branch that is
still officially supported, but that contains known vulnerabilities.

Historically this wasn't too much of a problem, either. We always aim to
keep security fixes as minimal as possible, which also helps with the
backporting process. Our last security release for example even spanned
over 8 releases, so if that's anything to go by we even underpromise :)

Patrick

Re: [PATCH RFC v2 5/7] BreakingChanges: announce Rust becoming mandatory

[Phillip Wood]

On 05/09/2025 13:45, Matthias Aßhauer wrote:
> On Fri, 5 Sep 2025, Patrick Steinhardt wrote:
> 
>> ++
>> +The Git project will declare the last version before Git 3.0 to be a 
>> long-term
>> +support release that is maintained until alternate Rust backends like 
>> gcc-rs are
>> +able to build Git. The Git project may need to rely on distributions 
>> to help
> 
> Do we want to commit to promising support until gccrs is ready? What if 
> gccrs ends up abandoned? Or takes an unexpectedly long time to reach a 
> stage where it can build Git? It might make sense to give this LTS 
> release a time limit instead, or in addidtion.

Yes, this feels way too open ended. I think we need to be realistic 
about how long we can offer security updates for an LTS version. A lot 
of the security updates are written by developers at companies that have 
very little or no commercial interest in platforms that don't support 
rust. While those companies do have an interest in helping to keep the 
wider ecosystem secure it is hard to see them funding security work on 
niche systems indefinitely. Giving platforms without a rust compiler two 
or three years to either port rust or prepare to take on the work of 
security updates for their platform themselves seems like a more 
realistic balance to me.

Thanks

Phillip

Re: [PATCH RFC v2 5/7] BreakingChanges: announce Rust becoming mandatory

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 4016 bytes --]

On 9/5/25 8:45 AM, Matthias Aßhauer wrote:
> 
> 
> On Fri, 5 Sep 2025, Patrick Steinhardt wrote:
> 
>> Over the last couple of years the appetite for bringin Rust into the
>> codebase has grown significantly across the developer base. Introducing
>> Rust is a major change though and has ramifications for the whole
>> ecosystem:
>>
>>  - Some platforms haven't yet been able to implement a Rust toolchain,
>>    even though it is possible in theory.
>>
>>  - Some platforms don't have any support for Rust at all.
> 
> What's the difference between these two kinds of platform? It should be
> theoretically possible to build rust tooling for all of them, right?


LLVM is theoretically an open source project. So is Rust. We can ask
people on those platforms how successful they have been at the political
side of convincing the Rust project to allowlist the platforms inside
low-level case statements of platform-specific defines, in order to
attempt the first round of "try running make, see what breaks and start
fixing it".

Hint: it did not go well, in the sense that the rust maintainers even
accepted the validity of making a proposal in the first place.

LLVM is easier to work with, at least in that sense. But not all
platforms are supported by LLVM either, and you do need a stable release
of LLVM to support the platform before you can begin work on rust at all.

That is the advantage of GCC-rs -- it has much broader platform support,
so if the rust frontend works at all, it will likely also work on the
specific platform you care about (and the GCC developers usually don't
bite, even if you want to enable experimental support for new platforms).



>> +The Git project will declare the last version before Git 3.0 to be a
>> long-term
>> +support release that is maintained until alternate Rust backends like
>> gcc-rs are
>> +able to build Git. The Git project may need to rely on distributions
>> to help
> 
> Do we want to commit to promising support until gccrs is ready? What if
> gccrs ends up abandoned? Or takes an unexpectedly long time to reach a
> stage where it can build Git? It might make sense to give this LTS
> release a time limit instead, or in addidtion.


Well, that will one way or another mean users of such platforms cannot
use git at all, not even old versions, lest they be hacked. Bit of a
problem for an application that mainly exists for the purpose of
communicating over the network. I suppose such platforms can finally
leave the world of DVCSes, given:

- jj, breezy, and mercurial all use rust already
- bitkeeper and monotone are dead
- darcs is written in GHC (haskell) which is far less available than
  rust

Maybe it will be the great subversion renaissance.

...

At any rate I do not expect GCC-rs to be abandoned, huge effort has been
put into it, many people are interested, they have funding to work on
it, and projects such as the Linux kernel want to see it exist because
they depend on GCC for their C code, want to have Rust code, and the
kernel security mitigations depend in part on being able to use the same
bytecode format for all code, to enable LTO and CFI visibility across
languages.

It is quite *unreasonable* to assume that interest will fade. No more
than to assume that *Git*s interest in Rust will fade. The chances of it
being *abandoned* without https://github.com/rust-lang/rust itself
supporting at least all interesting Linux Kernel architectures including
use of GCC as an alternative codegen backend, are... very low, in my
opinion.

Obviously, lacking the ability to prophesize the future, no one can know
if it will "takes an unexpectedly long time". Although again,
significant interest and all that. Not sure that would be my biggest
worry. They seem to be making reasonably effective use of their time
projections so far, though I will be happy to take correction if someone
knows something I've missed...


-- 
Eli Schwartz

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [PATCH RFC v2 5/7] BreakingChanges: announce Rust becoming mandatory

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 6058 bytes --]

On 2025-09-05 at 14:32:49, Eli Schwartz wrote:
> LLVM is theoretically an open source project. So is Rust. We can ask
> people on those platforms how successful they have been at the political
> side of convincing the Rust project to allowlist the platforms inside
> low-level case statements of platform-specific defines, in order to
> attempt the first round of "try running make, see what breaks and start
> fixing it".
> 
> Hint: it did not go well, in the sense that the rust maintainers even
> accepted the validity of making a proposal in the first place.
> 
> LLVM is easier to work with, at least in that sense. But not all
> platforms are supported by LLVM either, and you do need a stable release
> of LLVM to support the platform before you can begin work on rust at all.

It is possible to build with a custom LLVM because all of the
distributions do it, so it is possible to build the work out of tree and
then add it when everything is ready.  I mentioned elsewhere in the
discussions that LLVM upstream said that work on IA-64 could continue
out of tree and then it could be re-added if there was sufficient
maintenance and support, so this is at least in theory a viable option.

If LLVM and Rust upstreams are just completely unreasonable and won't
accept certain platforms at all (which I doubt), then distros can carry
patches.  It's not pretty and it's a bunch of hassle, but it's common.

I'll also say that LLVM is a pretty useful piece of software that most
distros will want to have.  It provides clangd, which is one of the the
major C and C++ LSPs; it's used by Doxygen, which is a major
documentation generator; and it's used by Mesa and PostgreSQL, which are
pieces of software people will want to use.  And, as well, it provides a
complete compiler toolchain.  So I think there are compelling reasons
why porting LLVM is valuable functionality to have anyway, in addition
to the fact that it also gets you most of the way towards Rust (and a
variety of other, less common languages).

> That is the advantage of GCC-rs -- it has much broader platform support,
> so if the rust frontend works at all, it will likely also work on the
> specific platform you care about (and the GCC developers usually don't
> bite, even if you want to enable experimental support for new platforms).

I agree gccrs is a great project and of course I want it to succeed.
Clearly having multiple independent implementations makes it easier to
find bugs and increases portability.  And if it means that we get better
platform support, fantastic.

However, if your complaint is that Rust upstream will not allow
platform-specific defines and other incremental work without support in
LLVM or other core toolchain components, then I don't see how gccrs is
going to convince them otherwise.  I also pointed out elsewhere that the
compiler is but one part of the equation and that libstd and libcore,
which are shared between the implementations, plus their dependencies,
are absolutely required for Rust to work on any platform.  If Rust
upstream doesn't allow support for the standard libraries, then distros
will have to carry patches, gccrs or not.

To be clear, I do support this kind of incremental work since it's a
valuable way to do large projects (and it's what I did for SHA-256 in
Git and am doing for SHA-1/SHA-256 interop), but saying, "brian and
other Git contributors say this is a good idea" may not be more
convincing.  To the extent I can encourage this kind of thing, I am
happy to do so, though.

> > Do we want to commit to promising support until gccrs is ready? What if
> > gccrs ends up abandoned? Or takes an unexpectedly long time to reach a
> > stage where it can build Git? It might make sense to give this LTS
> > release a time limit instead, or in addidtion.

I think a two-year limit is reasonable.  As anyone who speaks Spanish
will tell you, there's a degree of uncertainty when speculating about
the future, so we cannot guarantee that gccrs, however promising it
might currently appear, will be usable or viable in that time.  We
cannot agree to backport patches forever if gccrs doesn't materialize,
so a time limit seems like a good idea.

_However_, I will state that I am interested in seeing if we can get
mrustc to build Git's Rust code.  I understand that it is not intended
to do that (it's intended primarily to bootstrap Rust) and it definitely
will require some patches to get working, but I think it's at least a
possibility and it seems like a much lower effort way to solve the
problem.  It will probably involve some inconvenience on our part
because it's very limited in its toolchain and fake cargo, but I would
be willing to deal with said inconvenience for the purposes of
portability.  And it works now and is (for its limited purpose) actively
maintained.

> Well, that will one way or another mean users of such platforms cannot
> use git at all, not even old versions, lest they be hacked. Bit of a
> problem for an application that mainly exists for the purpose of
> communicating over the network. I suppose such platforms can finally
> leave the world of DVCSes, given:
> 
> - jj, breezy, and mercurial all use rust already
> - bitkeeper and monotone are dead
> - darcs is written in GHC (haskell) which is far less available than
>   rust

There are other Git-compatible options.  There's Game of Trees, which
uses Git repositories and is being designed by OpenBSD.  It isn't
drop-in compatible, since it's designed to meet the OpenBSD team's
needs, but it appears to be basically functional (and is shipped in
Debian, no less).

There's also libgit2 and Dulwich, which also implement Git repositories.

So there are options for people who want to use Git on platforms that
don't support Rust.  I suspect that the lack of Git on certain platforms
will actually be more of a problem for those platforms than for Git,
though.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [PATCH RFC v2 5/7] BreakingChanges: announce Rust becoming mandatory

[Elijah Newren]

On Fri, Sep 5, 2025 at 4:51 AM Patrick Steinhardt <ps@pks.im> wrote:
>
> Over the last couple of years the appetite for bringin Rust into the
> codebase has grown significantly across the developer base. Introducing
> Rust is a major change though and has ramifications for the whole
> ecosystem:
>
>   - Some platforms haven't yet been able to implement a Rust toolchain,
>     even though it is possible in theory.
>
>   - Some platforms don't have any support for Rust at all.
>
>   - Some platforms may have to figure out how to fit Rust into their
>     bootstrapping sequence.
>
> Due to this, and given that Git is a critical piece of infrastructure
> for the whole industry, we cannot just introduce such a heavyweight
> dependency without doing our due diligence.
>
> Instead, preceding commits have introduced a test balloon into our build
> infrastructure that convert one tiny subsystem to use Rust.  For now,
> using Rust to build that subsystem is entirely optional -- if no Rust
> support is available, we continue to use the C implementation. This test
> balloon has the intention to give distributions time and let them ease
> into our adoption of Rust.

This paragraph appears to contradict itself -- it says we introduced a
test balloon, but then explains how the test balloon isn't actually a
test balloon (i.e. that we simply silently use the C implementation if
Rust isn't available).

> Having multiple implementations of the same subsystem is not sustainable
> though, and the plan is to eventually be able to use Rust freely all
> across our codebase. As such, there is the intent to make Rust become a
> mandatory part of our build process.
>
> Add an announcement to our breaking changes that Rust will become
> mandatory in Git 3.0. A (very careful and non-binding) estimate might be
> that this major release might be released in the second half of next
> year, which should give distributors enough time to prepare for the
> change.

While I disagree with lumping the change with 3.0, I appreciate the
goal to provide additional notice.  I think it really ought to be part
of the release notes for 2.52 instead of the BreakingChanges document,
but having some kind of announcement is the most important part.
Thanks for proposing some wording.

> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
>  Documentation/BreakingChanges.adoc | 36 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 36 insertions(+)
>
> diff --git a/Documentation/BreakingChanges.adoc b/Documentation/BreakingChanges.adoc
> index f8d2eba061..dbb15b6a57 100644
> --- a/Documentation/BreakingChanges.adoc
> +++ b/Documentation/BreakingChanges.adoc
> @@ -165,6 +165,42 @@ A prerequisite for this change is that the ecosystem is ready to support the
>  "reftable" format. Most importantly, alternative implementations of Git like
>  JGit, libgit2 and Gitoxide need to support it.
>
> +* Git will require Rust as a mandatory part of the build process. While Git
> +  already started to adopt Rust in the Git 2.52, all parts written in Rust are
> +  optional for the time being. This includes:

This isn't quite accurate; perhaps:

...While Git already started to adopt Rust into the core in Git 2.52
(and as an optional "contrib" component back in Git 2.49), all
parts...

> ++
> +  ** Subsystems that have an alternative implementation in Rust to test
> +     interoperability between our C and Rust codebase.
> +  ** Newly written features that are not mission critical for a fully functional
> +     Git client.
> ++
> +These changes are meant as test balloons to allow distributors of Git to prepare
> +for Rust becoming a mandatory part of the build process. There will be multiple
> +milestones for the introduction of Rust:
> ++
> +1. Initially, with Git 2.52, support for Rust will be auto-detected by Rust and
> +   disabled in our Makefile so that the project can sort out the initial
> +   infrastructure.
> +2. In Git 2.53, support for Rust will be made mandatory in case Git is compiled
> +   with breaking changes. Breaking changes can be enabled for Meson by saying
> +   `meson configure -Dbreaking_changes=true` and for Makefiles via `make
> +   WITH_BREAKING_CHANGES=YesPlease`. It will still be possible to compile with
> +   breaking changes, but explicitly disable Rust.

As stated in https://lore.kernel.org/git/20250904-b4-pks-rust-breaking-change-v1-0-3af1d25e0be9@pks.im/T/#mf9283df5e7724fd00a6fe23e1777b77fcdf0c12d,
I don't see how these two step help at all, and think we should jump
straight to step 3 with Git 2.52.

> +3. In Git 2.54, both build systems will default-enable support for Rust so that
> +   builds will break if Rust is not available on the build host. The use of Rust
> +   can still be explicitly disabled via build flags.
> +4. In Git 3.0, the build options will be removed and support for Rust is
> +   mandatory.
> ++
> +You can explicitly ask both Meson and our Makefile-based system to enable Rust
> +by saying `meson configure -Drust=enabled` and `make WITH_RUST=YesPlease`,
> +respectively.

I think we should instead allow folks to ask Meson and Maskfile to
disable Rust, otherwise we haven't provided a test balloon yet.

> ++
> +The Git project will declare the last version before Git 3.0 to be a long-term
> +support release that is maintained until alternate Rust backends like gcc-rs are
> +able to build Git. The Git project may need to rely on distributions to help
> +with identifying and backporting important bugfixes.

I disagree with tying the timeline to gcc-rs being able to build git;
I think that part of this paragraph should be stricken.

[PATCH RFC v2 6/7] ci: convert "pedantic" job into full build with breaking changes

[Patrick Steinhardt]

The "pedantic" CI job is building on Fedora with `DEVOPTS=pedantic`.
This build flag doesn't do anything anymore starting with 6a8cbc41ba
(developer: enable pedantic by default, 2021-09-03), where we have
flipped the default so that developers have to opt-out of pedantic
builds via the "no-pedantic" option. As such, all this job really does
is to do a normal build on Fedora, which isn't all that interesting.

Convert that job into a full build-and-test job that uses Meson with
breaking changes enabled. This plugs two gaps:

  - We now test on another distro that we didn't run tests on
    beforehand.

  - We verify that breaking changes work as expected with Meson.

Furthermore, in a subsequent commit we'll modify both jobs that use
breaking changes to also enable Rust. By converting the Fedora job to
use Meson, we ensure that we test our Rust build infrastructure for both
build systems.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 .github/workflows/main.yml |  4 ++--
 .gitlab-ci.yml             |  4 ++--
 ci/install-dependencies.sh |  2 +-
 ci/run-build-and-tests.sh  | 29 ++++++++---------------------
 4 files changed, 13 insertions(+), 26 deletions(-)

diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index d122e79415..393ea4d1cc 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -379,6 +379,8 @@ jobs:
         - jobname: linux-breaking-changes
           cc: gcc
           image: ubuntu:rolling
+        - jobname: fedora-breaking-changes-meson
+          image: fedora:latest
         - jobname: linux-leaks
           image: ubuntu:rolling
           cc: gcc
@@ -396,8 +398,6 @@ jobs:
         # Supported until 2025-04-02.
         - jobname: linux32
           image: i386/ubuntu:focal
-        - jobname: pedantic
-          image: fedora:latest
         # A RHEL 8 compatible distro.  Supported until 2029-05-31.
         - jobname: almalinux-8
           image: almalinux:8
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index af10ebb59a..4248506909 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -45,6 +45,8 @@ test:linux:
       - jobname: linux-breaking-changes
         image: ubuntu:20.04
         CC: gcc
+      - jobname: fedora-breaking-changes-meson
+        image: fedora:latest
       - jobname: linux-TEST-vars
         image: ubuntu:20.04
         CC: gcc
@@ -58,8 +60,6 @@ test:linux:
       - jobname: linux-asan-ubsan
         image: ubuntu:rolling
         CC: clang
-      - jobname: pedantic
-        image: fedora:latest
       - jobname: linux-musl-meson
         image: alpine:latest
       - jobname: linux32
diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh
index d061a47293..4eaf3514d6 100755
--- a/ci/install-dependencies.sh
+++ b/ci/install-dependencies.sh
@@ -31,7 +31,7 @@ alpine-*)
 	;;
 fedora-*|almalinux-*)
 	dnf -yq update >/dev/null &&
-	dnf -yq install shadow-utils sudo make gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null
+	dnf -yq install shadow-utils sudo meson ninja pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null
 	;;
 ubuntu-*|i386/ubuntu-*|debian-*)
 	# Required so that apt doesn't wait for user input on certain packages.
diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index 01823fd0f1..3680446649 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -5,12 +5,11 @@
 
 . ${0%/*}/lib.sh
 
-run_tests=t
-
 case "$jobname" in
-linux-breaking-changes)
+fedora-breaking-changes-musl|linux-breaking-changes)
 	export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
 	export WITH_BREAKING_CHANGES=YesPlease
+	MESONFLAGS="$MESONFLAGS -Dbreaking_changes=true"
 	;;
 linux-TEST-vars)
 	export OPENSSL_SHA1_UNSAFE=YesPlease
@@ -36,12 +35,6 @@ linux-sha256)
 linux-reftable|linux-reftable-leaks|osx-reftable)
 	export GIT_TEST_DEFAULT_REF_FORMAT=reftable
 	;;
-pedantic)
-	# Don't run the tests; we only care about whether Git can be
-	# built.
-	export DEVOPTS=pedantic
-	run_tests=
-	;;
 esac
 
 case "$jobname" in
@@ -54,21 +47,15 @@ case "$jobname" in
 		-Dtest_output_directory="${TEST_OUTPUT_DIRECTORY:-$(pwd)/t}" \
 		$MESONFLAGS
 	group "Build" meson compile -C build --
-	if test -n "$run_tests"
-	then
-		group "Run tests" meson test -C build --print-errorlogs --test-args="$GIT_TEST_OPTS" || (
-			./t/aggregate-results.sh "${TEST_OUTPUT_DIRECTORY:-t}/test-results"
-			handle_failed_tests
-		)
-	fi
+	group "Run tests" meson test -C build --print-errorlogs --test-args="$GIT_TEST_OPTS" || (
+		./t/aggregate-results.sh "${TEST_OUTPUT_DIRECTORY:-t}/test-results"
+		handle_failed_tests
+	)
 	;;
 *)
 	group Build make
-	if test -n "$run_tests"
-	then
-		group "Run tests" make test ||
-		handle_failed_tests
-	fi
+	group "Run tests" make test ||
+	handle_failed_tests
 	;;
 esac
 

-- 
2.51.0.417.g1ba7204a04.dirty

Re: [PATCH RFC v2 6/7] ci: convert "pedantic" job into full build with breaking changes

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

>  fedora-*|almalinux-*)
>  	dnf -yq update >/dev/null &&
> -	dnf -yq install shadow-utils sudo make gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null
> +	dnf -yq install shadow-utils sudo meson ninja pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null

This drops "make" and adds "meson ninja pkg-config".

https://github.com/git/git/actions/runs/17506343802/job/49765327830

seems to indicate that AlmaLinux is unable to find meson and ninja.

Re: [PATCH RFC v2 6/7] ci: convert "pedantic" job into full build with breaking changes

[Patrick Steinhardt]

On Sat, Sep 06, 2025 at 05:21:50PM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> >  fedora-*|almalinux-*)
> >  	dnf -yq update >/dev/null &&
> > -	dnf -yq install shadow-utils sudo make gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null
> > +	dnf -yq install shadow-utils sudo meson ninja pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null
> 
> This drops "make" and adds "meson ninja pkg-config".
> 
> https://github.com/git/git/actions/runs/17506343802/job/49765327830
> 
> seems to indicate that AlmaLinux is unable to find meson and ninja.

Oh, I completely missed that we have AlmaLinux in our pipelines.
Should've taken a closer look seeing the above case statement. Will fix.

Patrick

[PATCH RFC v2 7/7] ci: enable Rust for breaking-changes jobs

[Patrick Steinhardt]

Enable Rust for our breaking-changes jobs so that we can verify that the
build infrastructure and the converted Rust subsystems work as expected.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 ci/install-dependencies.sh | 4 ++--
 ci/run-build-and-tests.sh  | 2 ++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh
index 4eaf3514d6..4c58c7238e 100755
--- a/ci/install-dependencies.sh
+++ b/ci/install-dependencies.sh
@@ -31,7 +31,7 @@ alpine-*)
 	;;
 fedora-*|almalinux-*)
 	dnf -yq update >/dev/null &&
-	dnf -yq install shadow-utils sudo meson ninja pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null
+	dnf -yq install shadow-utils sudo meson ninja pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel rustc >/dev/null
 	;;
 ubuntu-*|i386/ubuntu-*|debian-*)
 	# Required so that apt doesn't wait for user input on certain packages.
@@ -58,7 +58,7 @@ ubuntu-*|i386/ubuntu-*|debian-*)
 		make libssl-dev libcurl4-openssl-dev libexpat-dev wget sudo default-jre \
 		tcl tk gettext zlib1g-dev perl-modules liberror-perl libauthen-sasl-perl \
 		libemail-valid-perl libio-pty-perl libio-socket-ssl-perl libnet-smtp-ssl-perl libdbd-sqlite3-perl libcgi-pm-perl \
-		libsecret-1-dev libpcre2-dev meson ninja-build pkg-config \
+		libsecret-1-dev libpcre2-dev meson ninja-build pkg-config cargo \
 		${CC_PACKAGE:-${CC:-gcc}} $PYTHON_PACKAGE
 
 	case "$distro" in
diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index 3680446649..c718bd101a 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -9,7 +9,9 @@ case "$jobname" in
 fedora-breaking-changes-musl|linux-breaking-changes)
 	export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
 	export WITH_BREAKING_CHANGES=YesPlease
+	export WITH_RUST=YesPlease
 	MESONFLAGS="$MESONFLAGS -Dbreaking_changes=true"
+	MESONFLAGS="$MESONFLAGS -Drust=enabled"
 	;;
 linux-TEST-vars)
 	export OPENSSL_SHA1_UNSAFE=YesPlease

-- 
2.51.0.417.g1ba7204a04.dirty

Re: [PATCH RFC v2 7/7] ci: enable Rust for breaking-changes jobs

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2160 bytes --]

On 2025-09-05 at 11:51:03, Patrick Steinhardt wrote:
> diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh
> index 4eaf3514d6..4c58c7238e 100755
> --- a/ci/install-dependencies.sh
> +++ b/ci/install-dependencies.sh
> @@ -31,7 +31,7 @@ alpine-*)
>  	;;
>  fedora-*|almalinux-*)
>  	dnf -yq update >/dev/null &&
> -	dnf -yq install shadow-utils sudo meson ninja pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null
> +	dnf -yq install shadow-utils sudo meson ninja pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel rustc >/dev/null

I know nothing about how Fedora packages Rust.  Do we need a cargo
package here as well, is that automatically included, or is it
unnecessary?

>  ubuntu-*|i386/ubuntu-*|debian-*)
>  	# Required so that apt doesn't wait for user input on certain packages.
> @@ -58,7 +58,7 @@ ubuntu-*|i386/ubuntu-*|debian-*)
>  		make libssl-dev libcurl4-openssl-dev libexpat-dev wget sudo default-jre \
>  		tcl tk gettext zlib1g-dev perl-modules liberror-perl libauthen-sasl-perl \
>  		libemail-valid-perl libio-pty-perl libio-socket-ssl-perl libnet-smtp-ssl-perl libdbd-sqlite3-perl libcgi-pm-perl \
> -		libsecret-1-dev libpcre2-dev meson ninja-build pkg-config \
> +		libsecret-1-dev libpcre2-dev meson ninja-build pkg-config cargo \
>  		${CC_PACKAGE:-${CC:-gcc}} $PYTHON_PACKAGE

Seems reasonable.  That will definitely pull in rustc as well.

>  	case "$distro" in
> diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
> index 3680446649..c718bd101a 100755
> --- a/ci/run-build-and-tests.sh
> +++ b/ci/run-build-and-tests.sh
> @@ -9,7 +9,9 @@ case "$jobname" in
>  fedora-breaking-changes-musl|linux-breaking-changes)
>  	export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
>  	export WITH_BREAKING_CHANGES=YesPlease
> +	export WITH_RUST=YesPlease
>  	MESONFLAGS="$MESONFLAGS -Dbreaking_changes=true"
> +	MESONFLAGS="$MESONFLAGS -Drust=enabled"

Looks good.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [PATCH RFC v2 7/7] ci: enable Rust for breaking-changes jobs

[Patrick Steinhardt]

On Fri, Sep 05, 2025 at 07:56:13PM +0000, brian m. carlson wrote:
> On 2025-09-05 at 11:51:03, Patrick Steinhardt wrote:
> > diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh
> > index 4eaf3514d6..4c58c7238e 100755
> > --- a/ci/install-dependencies.sh
> > +++ b/ci/install-dependencies.sh
> > @@ -31,7 +31,7 @@ alpine-*)
> >  	;;
> >  fedora-*|almalinux-*)
> >  	dnf -yq update >/dev/null &&
> > -	dnf -yq install shadow-utils sudo meson ninja pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null
> > +	dnf -yq install shadow-utils sudo meson ninja pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel rustc >/dev/null
> 
> I know nothing about how Fedora packages Rust.  Do we need a cargo
> package here as well, is that automatically included, or is it
> unnecessary?

Fedora uses Meson, which doesn't (yet?) need Cargo for the build infra.
I'll probably adapt this eventually to use the Cargo wraps, at which
point in time we'll need it as well.

Patrick

Re: [PATCH RFC v2 7/7] ci: enable Rust for breaking-changes jobs

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

> diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
> index 3680446649..c718bd101a 100755
> --- a/ci/run-build-and-tests.sh
> +++ b/ci/run-build-and-tests.sh
> @@ -9,7 +9,9 @@ case "$jobname" in
>  fedora-breaking-changes-musl|linux-breaking-changes)
>  	export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
>  	export WITH_BREAKING_CHANGES=YesPlease
> +	export WITH_RUST=YesPlease
>  	MESONFLAGS="$MESONFLAGS -Dbreaking_changes=true"
> +	MESONFLAGS="$MESONFLAGS -Drust=enabled"
>  	;;
>  linux-TEST-vars)
>  	export OPENSSL_SHA1_UNSAFE=YesPlease

This had a slight interaction with other topics in flight that
targets 3.0 boundary.  I believe the resolution I did was correct,
but please double check for sanity.

Thanks.

Re: [PATCH RFC v2 7/7] ci: enable Rust for breaking-changes jobs

[Patrick Steinhardt]

On Fri, Sep 05, 2025 at 02:00:11PM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
> > index 3680446649..c718bd101a 100755
> > --- a/ci/run-build-and-tests.sh
> > +++ b/ci/run-build-and-tests.sh
> > @@ -9,7 +9,9 @@ case "$jobname" in
> >  fedora-breaking-changes-musl|linux-breaking-changes)
> >  	export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
> >  	export WITH_BREAKING_CHANGES=YesPlease
> > +	export WITH_RUST=YesPlease
> >  	MESONFLAGS="$MESONFLAGS -Dbreaking_changes=true"
> > +	MESONFLAGS="$MESONFLAGS -Drust=enabled"
> >  	;;
> >  linux-TEST-vars)
> >  	export OPENSSL_SHA1_UNSAFE=YesPlease
> 
> This had a slight interaction with other topics in flight that
> targets 3.0 boundary.  I believe the resolution I did was correct,
> but please double check for sanity.

Yup, the resolution looks good to me. Thanks!

Patrick

Re: [PATCH RFC v2 0/7] Introduce Rust and announce that it will become mandatorty

[Phillip Wood]

Hi Patrick

On 05/09/2025 12:50, Patrick Steinhardt wrote:
> Hi,
> 
> this small patch series introduces Rust into the core of Git. This patch
> series is designed as a test balloon, similar to how we introduced test
> balloons for C99 features in the past. The goal is threefold:
> 
>    - Give us some time to experiment with Rust and introduce proper build
>      infrastructure.
> 
>    - Give distributors time to ease into the new toolchain requirements.
>      Introducing Rust is impossible for some platforms and hard for
>      others.

These sound good

>    - Announce that Git 3.0 will make Rust a mandatory part of our build
>      infrastructure.

I'm not sure if we really want to wait that long. So far Git 3.0 has 
been about user facing changes rather than build requirements. In [1] I 
suggested a period of six months from the initial announcement to making 
rust mandatory to allow distributors time to either adjust their build 
procedures or notify their users that they will only be offering 
security updates in the future.
> The test balloon itself is quite uninteresting: I've chosen to convert
> the "varint.c" subsystem, mostly because it is trivial and does not have
> any dependencies. But it does allow us to verify that C to Rust interop
> works as expected, and to play around with tooling. All tests pass with
> the "varint.rs" implementation.
> 
> For now, the series only contains support for Meson. If we agree to go
> down this route I'll also introduce support for Rust into our Makefiles
> at a later point in time.

It looks like this version does include the necessary Makefile changes 
which is great. I do think though, that for the test balloon to be 
valuable, we need make building with rust the default with an error 
message that tells people how to build without rust if that fails. 
Otherwise it is easy for people building on platforms without rust 
support to miss that we're going to be making it mandatory soon.

Thanks

Phillip

[1] 
https://lore.kernel.org/git/ba386547-10e0-45e2-95ad-c47e84919abf@gmail.com

> Furthermore missing is additional tooling:
> 
>    - At least one CI job to verify that Rust builds and works as
>      expected.
> 
>    - Tooling and CI jobs to ensure that we have consistent formatting via
>      `cargo format`.
> 
> And probably lots more. As said, the entire goal is for us to have an
> easy playground that we can experiment on and develop the infrastructure
> incrementally without yet having to commit to anything.
> 
> I'm mostly splitting out the topic of introducing Rust from the larger
> series that introduce it into xdiff so that we can focus more on the
> actual process of introducing Rust into Git and less on the potential
> features that we want to build on top of it.
> 
> Changes in v2:
>    - Introduce support for building the Rust library via our Makefile.
>    - Introduce a '-DWITH_RUST' define. This define is used to print
>      whether or not Git is built with Rust via `git version
>      --build-options`.
>    - Adjust Meson to not depend on v1.9.0 and newer anymore.
>    - Introduce a roadmap into our BreakingChanges document to explain how
>      we'll iterate towards mandatory Rust support.
>    - Rework the Fedora job to do a full compile-and-test run with Meson
>      and breaking changes enabled.
>    - Adapt our breaking-changes jobs to enable Rust support.
>    - Link to v1: https://lore.kernel.org/r/20250904-b4-pks-rust-breaking-change-v1-0-3af1d25e0be9@pks.im
> 
> Thanks!
> 
> Patrick
> 
> ---
> Patrick Steinhardt (7):
>        meson: add infrastructure to build internal Rust library
>        Makefile: introduce infrastructure to build internal Rust library
>        help: report on whether or not Rust is enabled
>        rust: implement a test balloon via the "varint" subsystem
>        BreakingChanges: announce Rust becoming mandatory
>        ci: convert "pedantic" job into full build with breaking changes
>        ci: enable Rust for breaking-changes jobs
> 
>   .github/workflows/main.yml         |  4 +-
>   .gitignore                         |  2 +
>   .gitlab-ci.yml                     |  4 +-
>   Cargo.toml                         |  9 ++++
>   Documentation/BreakingChanges.adoc | 36 +++++++++++++++
>   Makefile                           | 47 ++++++++++++++++++-
>   ci/install-dependencies.sh         |  4 +-
>   ci/run-build-and-tests.sh          | 31 +++++--------
>   help.c                             |  6 +++
>   meson.build                        | 17 ++++++-
>   meson_options.txt                  |  2 +
>   src/lib.rs                         |  1 +
>   src/meson.build                    | 16 +++++++
>   src/varint.rs                      | 92 ++++++++++++++++++++++++++++++++++++++
>   14 files changed, 240 insertions(+), 31 deletions(-)
> 
> Range-diff versus v1:
> 
> 1:  4df400823c ! 1:  8f6e89bc7d meson: add infrastructure to build internal Rust library
>      @@ meson.build: version_def_h = custom_target(
>        
>       +libgit_libraries = [ ]
>       +
>      -+if meson.version().version_compare('>=1.9.0')
>      -+  rust_available = add_languages('rust', native: false, required: get_option('rust'))
>      -+else
>      -+  rust_available = false
>      -+endif
>      ++rust_available = add_languages('rust', native: false, required: get_option('rust'))
>       +rust_option = get_option('rust').disable_auto_if(not rust_available)
>      -+
>      -+if rust_option.allowed() and meson.version().version_compare('>=1.9.0')
>      ++if rust_option.allowed()
>       +  subdir('src')
>      ++  libgit_c_args += '-DWITH_RUST'
>       +endif
>       +
>        libgit = declare_dependency(
>      @@ src/lib.rs (new)
>       
>        ## src/meson.build (new) ##
>       @@
>      -+rustmod = import('rust')
>      -+
>       +libgit_rs = static_library('git_rs',
>       +  sources: [
>       +    'lib.rs',
>       +  ],
>      -+  rust_abi: 'c',
>      ++  rust_crate_type: 'staticlib',
>       +)
>      -+
>      -+rustmod.test('git-rs', libgit_rs)
>      -+
>       +libgit_libraries += libgit_rs
>      ++
>      ++# The 'rust' module was only introduced in Meson 1.0. Furthermore, the module
>      ++# does not seem to work on macOS as expected right now. As such, we only
>      ++# conditionally enable tests.
>      ++if meson.version().version_compare('>=1.0.0') and host_machine.system() != 'darwin'
>      ++  rustmod = import('rust')
>      ++  rustmod.test('rust', libgit_rs)
>      ++endif
> -:  ---------- > 2:  cd1d642d04 Makefile: introduce infrastructure to build internal Rust library
> -:  ---------- > 3:  e60a8353a4 help: report on whether or not Rust is enabled
> 2:  575f6de44d ! 4:  b27811aea4 rust: implement a test balloon via the "varint" subsystem
>      @@ Commit message
>       
>           Signed-off-by: Patrick Steinhardt <ps@pks.im>
>       
>      + ## Makefile ##
>      +@@ Makefile: LIB_OBJS += urlmatch.o
>      + LIB_OBJS += usage.o
>      + LIB_OBJS += userdiff.o
>      + LIB_OBJS += utf8.o
>      ++ifndef WITH_RUST
>      + LIB_OBJS += varint.o
>      ++endif
>      + LIB_OBJS += version.o
>      + LIB_OBJS += versioncmp.o
>      + LIB_OBJS += walker.o
>      +
>        ## meson.build ##
>       @@ meson.build: libgit_sources = [
>          'usage.c',
>      @@ meson.build: libgit_sources = [
>          'versioncmp.c',
>          'walker.c',
>       @@ meson.build: rust_option = get_option('rust').disable_auto_if(not rust_available)
>      -
>      - if rust_option.allowed() and meson.version().version_compare('>=1.9.0')
>      + if rust_option.allowed()
>          subdir('src')
>      +   libgit_c_args += '-DWITH_RUST'
>       +else
>       +  libgit_sources += [
>       +    'varint.c',
>      @@ src/lib.rs
>       +pub mod varint;
>       
>        ## src/meson.build ##
>      -@@ src/meson.build: rustmod = import('rust')
>      +@@
>        libgit_rs = static_library('git_rs',
>          sources: [
>            'lib.rs',
>       +    'varint.rs',
>          ],
>      -   rust_abi: 'c',
>      +   rust_crate_type: 'staticlib',
>        )
>       
>        ## src/varint.rs (new) ##
> 3:  e54393392a < -:  ---------- BreakingChanges: announce Rust becoming mandatory
> -:  ---------- > 5:  d5946e0114 BreakingChanges: announce Rust becoming mandatory
> -:  ---------- > 6:  0d367976de ci: convert "pedantic" job into full build with breaking changes
> -:  ---------- > 7:  82086a5328 ci: enable Rust for breaking-changes jobs
> 
> ---
> base-commit: 2462961280690837670d997bde64bd4ebf8ae66d
> change-id: 20250904-b4-pks-rust-breaking-change-7167d9d3e37d
> 
> 

Re: [PATCH RFC v2 0/7] Introduce Rust and announce that it will become mandatorty

[Patrick Steinhardt]

On Fri, Sep 05, 2025 at 03:14:25PM +0100, Phillip Wood wrote:
> On 05/09/2025 12:50, Patrick Steinhardt wrote:
> > this small patch series introduces Rust into the core of Git. This patch
> > series is designed as a test balloon, similar to how we introduced test
> > balloons for C99 features in the past. The goal is threefold:
> > 
> >    - Give us some time to experiment with Rust and introduce proper build
> >      infrastructure.
> > 
> >    - Give distributors time to ease into the new toolchain requirements.
> >      Introducing Rust is impossible for some platforms and hard for
> >      others.
> 
> These sound good
> 
> >    - Announce that Git 3.0 will make Rust a mandatory part of our build
> >      infrastructure.
> 
> I'm not sure if we really want to wait that long. So far Git 3.0 has been
> about user facing changes rather than build requirements. In [1] I suggested
> a period of six months from the initial announcement to making rust
> mandatory to allow distributors time to either adjust their build procedures
> or notify their users that they will only be offering security updates in
> the future.

More on that below.

> > The test balloon itself is quite uninteresting: I've chosen to convert
> > the "varint.c" subsystem, mostly because it is trivial and does not have
> > any dependencies. But it does allow us to verify that C to Rust interop
> > works as expected, and to play around with tooling. All tests pass with
> > the "varint.rs" implementation.
> > 
> > For now, the series only contains support for Meson. If we agree to go
> > down this route I'll also introduce support for Rust into our Makefiles
> > at a later point in time.
> 
> It looks like this version does include the necessary Makefile changes which
> is great. I do think though, that for the test balloon to be valuable, we
> need make building with rust the default with an error message that tells
> people how to build without rust if that fails. Otherwise it is easy for
> people building on platforms without rust support to miss that we're going
> to be making it mandatory soon.

I have a plan layed out in the BreakingChanges document that mentions
how I'm proposing to do the transition:

  1. We introduce it with auto-detection for Meson and default-disabled
     for our Makefile in Git 2.52.

  2. We enable Rust by default in case WITH_BREAKING_CHANGES is enabled
     in Git 2.53.

  3. We always enable Rust by default in Git 2.54.

  4. We unconditionally enable Rust in Git 3.0.

This is basically gradually tightening the screws, which both gives us
time to build the infra and gives downstream time to become aware of the
change and adapt.

I think making it mandatory in Git 3.0 makes sense because I also
propose to make the last version without mandatory Rust be an LTS
version. And if we connect that with it being the last version before
3.0 I think that's an additional benefit, as there will be other
breaking changes in 3.0.

In the end it kind of hinges on when we think we want to release Git
3.0. If we can agree on the above plan, we could also think about making
Git 2.55 become 3.0 instead. That'd be in a bit less than a year from
now, which I think is a good timeframe for that breaking release. I
personally don't see a reason to push it out into the future for way
longer than that, and it would be good anyway if we built some consensus
around its release date.

Patrick

Re: [PATCH RFC v2 0/7] Introduce Rust and announce that it will become mandatorty

[Elijah Newren]

On Fri, Sep 5, 2025 at 7:29 AM Patrick Steinhardt <ps@pks.im> wrote:
>

> > It looks like this version does include the necessary Makefile changes which
> > is great. I do think though, that for the test balloon to be valuable, we
> > need make building with rust the default with an error message that tells
> > people how to build without rust if that fails. Otherwise it is easy for
> > people building on platforms without rust support to miss that we're going
> > to be making it mandatory soon.
>
> I have a plan layed out in the BreakingChanges document that mentions
> how I'm proposing to do the transition:
>
>   1. We introduce it with auto-detection for Meson and default-disabled
>      for our Makefile in Git 2.52.
>
>   2. We enable Rust by default in case WITH_BREAKING_CHANGES is enabled
>      in Git 2.53.
>
>   3. We always enable Rust by default in Git 2.54.

I don't see how steps 1 & 2 help at all.  We now know we want to make
Rust mandatory eventually, and should provide distributors and
platforms as much notice as possible so they are aware.  But what
you've proposed is another libgit-rs or libgit-sys -- an optional
component that no one will know about unless they go looking for it.
I don't see how those two steps provide any incremental help to
anybody over what libgit-rs and libgit-sys have done.  From my point
of view, Rust should be enabled by default in Git 2.52, with a simple
knob provided to let distributors/platforms/users turn it off and
build without it.

>   4. We unconditionally enable Rust in Git 3.0.
>
> This is basically gradually tightening the screws, which both gives us
> time to build the infra and gives downstream time to become aware of the
> change and adapt.
>
> I think making it mandatory in Git 3.0 makes sense because I also
> propose to make the last version without mandatory Rust be an LTS
> version. And if we connect that with it being the last version before
> 3.0 I think that's an additional benefit, as there will be other
> breaking changes in 3.0.
>
> In the end it kind of hinges on when we think we want to release Git
> 3.0. If we can agree on the above plan, we could also think about making
> Git 2.55 become 3.0 instead. That'd be in a bit less than a year from
> now, which I think is a good timeframe for that breaking release. I
> personally don't see a reason to push it out into the future for way
> longer than that, and it would be good anyway if we built some consensus
> around its release date.

I see your plan, but I agree with Phillip that I don't see why it
makes sense to lump the Rust transition with the 3.0 transition.

Setting that aside for a moment, the idea of Git 2.55 becoming 3.0
seems like a good idea to me, assuming that doesn't rush brian on the
sha1/sha256 interop (since I think that's probably the paramount
feature of 3.0).

Re: [PATCH RFC v2 0/7] Introduce Rust and announce that it will become mandatorty

[Patrick Steinhardt]

On Sat, Sep 06, 2025 at 09:31:02PM -0700, Elijah Newren wrote:
> On Fri, Sep 5, 2025 at 7:29 AM Patrick Steinhardt <ps@pks.im> wrote:
> > > It looks like this version does include the necessary Makefile changes which
> > > is great. I do think though, that for the test balloon to be valuable, we
> > > need make building with rust the default with an error message that tells
> > > people how to build without rust if that fails. Otherwise it is easy for
> > > people building on platforms without rust support to miss that we're going
> > > to be making it mandatory soon.
> >
> > I have a plan layed out in the BreakingChanges document that mentions
> > how I'm proposing to do the transition:
> >
> >   1. We introduce it with auto-detection for Meson and default-disabled
> >      for our Makefile in Git 2.52.
> >
> >   2. We enable Rust by default in case WITH_BREAKING_CHANGES is enabled
> >      in Git 2.53.
> >
> >   3. We always enable Rust by default in Git 2.54.
> 
> I don't see how steps 1 & 2 help at all.  We now know we want to make
> Rust mandatory eventually, and should provide distributors and
> platforms as much notice as possible so they are aware.  But what
> you've proposed is another libgit-rs or libgit-sys -- an optional
> component that no one will know about unless they go looking for it.
> I don't see how those two steps provide any incremental help to
> anybody over what libgit-rs and libgit-sys have done.  From my point
> of view, Rust should be enabled by default in Git 2.52, with a simple
> knob provided to let distributors/platforms/users turn it off and
> build without it.

It helps because it allows us to slowly build out the infrastructure. We
don't yet need answers to every question that we currently have if we
initially have the Rust infra default-disabled.

I very much expect that there'll be some issues with our initial first
steps. So I'd rather want to avoid to expose developers or distros to
these issues directly, because that might train them to immediately
disable Rust right from the start.

> >   4. We unconditionally enable Rust in Git 3.0.
> >
> > This is basically gradually tightening the screws, which both gives us
> > time to build the infra and gives downstream time to become aware of the
> > change and adapt.
> >
> > I think making it mandatory in Git 3.0 makes sense because I also
> > propose to make the last version without mandatory Rust be an LTS
> > version. And if we connect that with it being the last version before
> > 3.0 I think that's an additional benefit, as there will be other
> > breaking changes in 3.0.
> >
> > In the end it kind of hinges on when we think we want to release Git
> > 3.0. If we can agree on the above plan, we could also think about making
> > Git 2.55 become 3.0 instead. That'd be in a bit less than a year from
> > now, which I think is a good timeframe for that breaking release. I
> > personally don't see a reason to push it out into the future for way
> > longer than that, and it would be good anyway if we built some consensus
> > around its release date.
> 
> I see your plan, but I agree with Phillip that I don't see why it
> makes sense to lump the Rust transition with the 3.0 transition.

I don't necessarily think we need to do it with 3.0, agreed. But as
Junio mentioned [1], 6 months feels too short for him to make Rust
mandatory, so we're realistically looking at a period of at least one
year to make this happen.

So it felt like a good match to tie these two together. The primary
motivation is that other breaking changes that we introduce with 3.0 may
cause minor inconveniences, as well. So that means that we help not only
non-Rust platforms with the proposed LTS release, but also potentially
others.

That being said, I really hope that most of the other changes should be
rather uneventful. I don't want to create a Python 3-style split.

> Setting that aside for a moment, the idea of Git 2.55 becoming 3.0
> seems like a good idea to me, assuming that doesn't rush brian on the
> sha1/sha256 interop (since I think that's probably the paramount
> feature of 3.0).

Yeah, the interop is definitely an important factor and the last part
that I think is still missing for Git 3.0 to become viable.

Patrick

Re: [PATCH RFC v2 0/7] Introduce Rust and announce that it will become mandatorty

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 3223 bytes --]

On 2025-09-08 at 06:44:08, Patrick Steinhardt wrote:
> > Setting that aside for a moment, the idea of Git 2.55 becoming 3.0
> > seems like a good idea to me, assuming that doesn't rush brian on the
> > sha1/sha256 interop (since I think that's probably the paramount
> > feature of 3.0).
> 
> Yeah, the interop is definitely an important factor and the last part
> that I think is still missing for Git 3.0 to become viable.

I am definitely working on this at the moment and here's what I have
working:

* Pack index v3
* Fetching and pushing for full (non-shallow, non-partial) clones
  without submodules

And I'm working on these:

* The new binary loose object map (I was debugging round-tripping this
  morning)
* Shallow fetches (which, due to the quarantine usage, need a binary
  loose object map rather than the `loose-object-idx` file, since the
  quarantine can't merge the two `loose-object-idx` files together)

And then I'll get to these:

* Shallow pushes
* Partial clone
* Garbage collecting and repacking binary loose object maps
* Submodule handling in the protocol

I will need to switch soon to writing my presentation for Git Merge,
though, but afterwards I'm going to go back through the testsuite and
see what else is failing.  I expect partial and shallow clones to fix a
lot of the remaining tests, but there are still going to be some
problems to deal with.

Note that shallow and partial clones where the server supports only
one algorithm won't work with interoperability, since those lack full
data and the client side won't be able to map the objects between
algorithms.  There's also the problem that accepting submodule mappings
introduces a security risk, since it's possible for the other side to
send commit A in SHA-1 but commit B in SHA-256 and there's no real way
to detect that unless you have the submodule on your side.

I may end up asking for some assistance in polishing and sending in what
I have.  Most of what I have is reasonably good quality[0] and should be
bisectable, but I'm up to 81 patches before the Rust part of the code
(which so far has 12 patches) and I'm worried I won't be able to both
write it and get it sent in in nice-sized series before 3.0 is likely to
happen.

Alternatively, we could maybe accept that interoperability is a
nice-to-have for Git 3.0 and not an essential.  It's not mentioned in
the BreakingChanges document, so it's perhaps not a requirement.  We
could also have someone work on this as part of their job to get it
handled more quickly[1].

Finally, I am currently interested in working on the interop code (but
have no problem handing it off if that works better for the project),
but I cannot guarantee that I will absolutely have time or inclination
to continue.

[0] There are some patches marked WIP with a reason as to why they need
work, but those are few and far between.
[1] I think it's unlikely that this will be able to be me for reasons
which I cannot share at the moment but hope to be able to later on,
maybe at the Contributor Summit.  I'll keep an eye out in case it
becomes possible, though.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [PATCH RFC v2 0/7] Introduce Rust and announce that it will become mandatorty

[Patrick Steinhardt]

On Mon, Sep 08, 2025 at 11:00:29PM +0000, brian m. carlson wrote:
> I may end up asking for some assistance in polishing and sending in what
> I have.  Most of what I have is reasonably good quality[0] and should be
> bisectable, but I'm up to 81 patches before the Rust part of the code
> (which so far has 12 patches) and I'm worried I won't be able to both
> write it and get it sent in in nice-sized series before 3.0 is likely to
> happen.

Oh, I didn't expect it to be that much work. In any case, I would be
happy to help out with this effort in case there's anything concrete we
can do here.

> Alternatively, we could maybe accept that interoperability is a
> nice-to-have for Git 3.0 and not an essential.  It's not mentioned in
> the BreakingChanges document, so it's perhaps not a requirement.  We
> could also have someone work on this as part of their job to get it
> handled more quickly[1].

I wouldn't mind that outcome, either.

> Finally, I am currently interested in working on the interop code (but
> have no problem handing it off if that works better for the project),
> but I cannot guarantee that I will absolutely have time or inclination
> to continue.

That is very fair indeed. I don't have the intention to force anybody's
hands with the proposed 3.0 timeline.

Patrick

Re: [PATCH RFC v2 0/7] Introduce Rust and announce that it will become mandatorty

[Elijah Newren]

On Sun, Sep 7, 2025 at 11:44 PM Patrick Steinhardt <ps@pks.im> wrote:
>
> On Sat, Sep 06, 2025 at 09:31:02PM -0700, Elijah Newren wrote:
> > On Fri, Sep 5, 2025 at 7:29 AM Patrick Steinhardt <ps@pks.im> wrote:
[...]
> > > I have a plan layed out in the BreakingChanges document that mentions
> > > how I'm proposing to do the transition:
> > >
> > >   1. We introduce it with auto-detection for Meson and default-disabled
> > >      for our Makefile in Git 2.52.
> > >
> > >   2. We enable Rust by default in case WITH_BREAKING_CHANGES is enabled
> > >      in Git 2.53.
> > >
> > >   3. We always enable Rust by default in Git 2.54.
> >
> > I don't see how steps 1 & 2 help at all.  We now know we want to make
> > Rust mandatory eventually, and should provide distributors and
> > platforms as much notice as possible so they are aware.  But what
> > you've proposed is another libgit-rs or libgit-sys -- an optional
> > component that no one will know about unless they go looking for it.
> > I don't see how those two steps provide any incremental help to
> > anybody over what libgit-rs and libgit-sys have done.  From my point
> > of view, Rust should be enabled by default in Git 2.52, with a simple
> > knob provided to let distributors/platforms/users turn it off and
> > build without it.
>
> It helps because it allows us to slowly build out the infrastructure. We
> don't yet need answers to every question that we currently have if we
> initially have the Rust infra default-disabled.

One of the things I find very unfortunate about this series, is we
have a new contributor who was trying to send in patches, and instead
of providing feedback, suggesting alternatives, or asking if he'd do
it differently (which he actually said he was willing to do [1]), it
sends out a competing patch series to replace his instead.  (And this
happened shortly after someone else interjected patches because of
interest in the first area he touched, forcing him to pivot once
already[2].)  Further, despite him having solved how to get it running
on all platforms we run in CI with some big help from the
git-for-windows folks, this series discards all of that.  It lends to
a feeling that he might be working on important and interesting
topics, but his changes aren't welcome and it's not worth providing
feedback for him to modify them to become so.  That's almost certainly
not your intent, but that is the effect that sending a competing patch
series likely is going to have.

[1] https://lore.kernel.org/git/CAH=ZcbBLAKaE733_2_2qbFTYCfwGq37RfF-Z3vaKL1ZR49msAA@mail.gmail.com/
[2] https://lore.kernel.org/git/xmqqzfbvfxs6.fsf@gitster.g/

> I very much expect that there'll be some issues with our initial first
> steps. So I'd rather want to avoid to expose developers or distros to
> these issues directly, because that might train them to immediately
> disable Rust right from the start.

I don't understand why that matters.  The whole point you gave to
motivate this series was to make distributors aware that mandatory
Rust is coming.  If they disable it early on, that requires them to
have been made aware, so mission achieved.  Making it optional and
off-by-default means they get no notice until multiple releases down
the road until you do turn it on, shortening the window they have to
be alerted and prepared.  To me, this feels like you're snatching
defeat from the jaws of victory.

Re: [PATCH RFC v2 0/7] Introduce Rust and announce that it will become mandatorty

[Patrick Steinhardt]

On Mon, Sep 08, 2025 at 11:33:45PM -0700, Elijah Newren wrote:
> On Sun, Sep 7, 2025 at 11:44 PM Patrick Steinhardt <ps@pks.im> wrote:
> >
> > On Sat, Sep 06, 2025 at 09:31:02PM -0700, Elijah Newren wrote:
> > > On Fri, Sep 5, 2025 at 7:29 AM Patrick Steinhardt <ps@pks.im> wrote:
> [...]
> > > > I have a plan layed out in the BreakingChanges document that mentions
> > > > how I'm proposing to do the transition:
> > > >
> > > >   1. We introduce it with auto-detection for Meson and default-disabled
> > > >      for our Makefile in Git 2.52.
> > > >
> > > >   2. We enable Rust by default in case WITH_BREAKING_CHANGES is enabled
> > > >      in Git 2.53.
> > > >
> > > >   3. We always enable Rust by default in Git 2.54.
> > >
> > > I don't see how steps 1 & 2 help at all.  We now know we want to make
> > > Rust mandatory eventually, and should provide distributors and
> > > platforms as much notice as possible so they are aware.  But what
> > > you've proposed is another libgit-rs or libgit-sys -- an optional
> > > component that no one will know about unless they go looking for it.
> > > I don't see how those two steps provide any incremental help to
> > > anybody over what libgit-rs and libgit-sys have done.  From my point
> > > of view, Rust should be enabled by default in Git 2.52, with a simple
> > > knob provided to let distributors/platforms/users turn it off and
> > > build without it.
> >
> > It helps because it allows us to slowly build out the infrastructure. We
> > don't yet need answers to every question that we currently have if we
> > initially have the Rust infra default-disabled.
> 
> One of the things I find very unfortunate about this series, is we
> have a new contributor who was trying to send in patches, and instead
> of providing feedback, suggesting alternatives, or asking if he'd do
> it differently (which he actually said he was willing to do [1]), it
> sends out a competing patch series to replace his instead.  (And this
> happened shortly after someone else interjected patches because of
> interest in the first area he touched, forcing him to pivot once
> already[2].)  Further, despite him having solved how to get it running
> on all platforms we run in CI with some big help from the
> git-for-windows folks, this series discards all of that.  It lends to
> a feeling that he might be working on important and interesting
> topics, but his changes aren't welcome and it's not worth providing
> feedback for him to modify them to become so.  That's almost certainly
> not your intent, but that is the effect that sending a competing patch
> series likely is going to have.
> 
> [1] https://lore.kernel.org/git/CAH=ZcbBLAKaE733_2_2qbFTYCfwGq37RfF-Z3vaKL1ZR49msAA@mail.gmail.com/
> [2] https://lore.kernel.org/git/xmqqzfbvfxs6.fsf@gitster.g/

First to say: I'm not trying to say that his changes are not welcome
here. What I'm trying to do with my patch series is to reconcile the
different camps that we have in our project and to find a way forward so
that Ezekiels work eventually becomes unblocked.

And regarding the Windows changes: yes, I haven't picked those yet. I
wanted to first get to a minimum working proposal so that we can focus
the discussion more on the roadmap, which I think is the more important
discussion compared to the technical discussion.

As I mentioned, I do plan to implement Windows support as a next step
once we have agreed on the initial baseline.

Patrick

Re: [PATCH RFC v2 0/7] Introduce Rust and announce that it will become mandatorty

[Phillip Wood]

Hi Patrick

On 05/09/2025 15:28, Patrick Steinhardt wrote:
> On Fri, Sep 05, 2025 at 03:14:25PM +0100, Phillip Wood wrote:
>>
>> It looks like this version does include the necessary Makefile changes which
>> is great. I do think though, that for the test balloon to be valuable, we
>> need make building with rust the default with an error message that tells
>> people how to build without rust if that fails. Otherwise it is easy for
>> people building on platforms without rust support to miss that we're going
>> to be making it mandatory soon.
> 
> I have a plan layed out in the BreakingChanges document that mentions
> how I'm proposing to do the transition:
> 
>    1. We introduce it with auto-detection for Meson and default-disabled
>       for our Makefile in Git 2.52.

I'm not sure how much this helps us. You've said elsewhere that you 
don't want to be inundated with bug reports which is fair enough, but 
I'm fairly skeptical that we're going to get enough people enabling this 
get a useful amount of early feedback. So I wonder if it would be better 
just to bite the bullet and enable it by default from the start. I think 
I saw Elijah making a similar argument elsewhere in this thread.
> In the end it kind of hinges on when we think we want to release Git
> 3.0. If we can agree on the above plan, we could also think about making
> Git 2.55 become 3.0 instead. That'd be in a bit less than a year from
> now, which I think is a good timeframe for that breaking release. I
> personally don't see a reason to push it out into the future for way
> longer than that, and it would be good anyway if we built some consensus
> around its release date.

It would definitely be good to firm up the date for a Git 3.0 release. 
I've been thinking whether there are any config defaults we might want 
to change like "commit.verbose" and "merge.conflictStyle" and enabling 
"--reapply-cherry-pick --empty=false" by default for "git rebase". 
Having a firm deadline would focus my mind!

Thanks

Phillip


> Patrick

Re: [PATCH RFC v2 0/7] Introduce Rust and announce that it will become mandatorty

[Patrick Steinhardt]

On Tue, Sep 09, 2025 at 10:12:39AM +0100, Phillip Wood wrote:
> On 05/09/2025 15:28, Patrick Steinhardt wrote:
> > On Fri, Sep 05, 2025 at 03:14:25PM +0100, Phillip Wood wrote:
> > > 
> > > It looks like this version does include the necessary Makefile changes which
> > > is great. I do think though, that for the test balloon to be valuable, we
> > > need make building with rust the default with an error message that tells
> > > people how to build without rust if that fails. Otherwise it is easy for
> > > people building on platforms without rust support to miss that we're going
> > > to be making it mandatory soon.
> > 
> > I have a plan layed out in the BreakingChanges document that mentions
> > how I'm proposing to do the transition:
> > 
> >    1. We introduce it with auto-detection for Meson and default-disabled
> >       for our Makefile in Git 2.52.
> 
> I'm not sure how much this helps us. You've said elsewhere that you don't
> want to be inundated with bug reports which is fair enough, but I'm fairly
> skeptical that we're going to get enough people enabling this get a useful
> amount of early feedback. So I wonder if it would be better just to bite the
> bullet and enable it by default from the start. I think I saw Elijah making
> a similar argument elsewhere in this thread.

The patch series may not be ready for all platforms yet though. Windows
support is still untested and probably not working, so I first need to
get that done. This is basically the reason why I'm proposing to have it
auto-detected at first: I want to be able to iterate without breaking
any platforms yet.

How about we do a compromise: we initially introduce it
default-disabled, but default-enable it in the next release already
instead of first tying it to `-Dbreaking_changes=true`? That would
accelerate the proposed timeline a bit.

Patrick

Re: [PATCH RFC v2 0/7] Introduce Rust and announce that it will become mandatorty

[Phillip Wood]

On 10/09/2025 09:21, Patrick Steinhardt wrote:
> On Tue, Sep 09, 2025 at 10:12:39AM +0100, Phillip Wood wrote:
>> On 05/09/2025 15:28, Patrick Steinhardt wrote:
>>> 
>>> I have a plan layed out in the BreakingChanges document that mentions
>>> how I'm proposing to do the transition:
>>>
>>>     1. We introduce it with auto-detection for Meson and default-disabled
>>>        for our Makefile in Git 2.52.
>>
>> I'm not sure how much this helps us. You've said elsewhere that you don't
>> want to be inundated with bug reports which is fair enough, but I'm fairly
>> skeptical that we're going to get enough people enabling this get a useful
>> amount of early feedback. So I wonder if it would be better just to bite the
>> bullet and enable it by default from the start. I think I saw Elijah making
>> a similar argument elsewhere in this thread.
> 
> The patch series may not be ready for all platforms yet though. Windows
> support is still untested and probably not working, so I first need to
> get that done. This is basically the reason why I'm proposing to have it
> auto-detected at first: I want to be able to iterate without breaking
> any platforms yet.
> 
> How about we do a compromise: we initially introduce it
> default-disabled, but default-enable it in the next release already
> instead of first tying it to `-Dbreaking_changes=true`? That would
> accelerate the proposed timeline a bit.

If we really can't get the windows support working before the next 
release then making it disabled by default on that platform makes sense 
and in that case it is probably simpler to make the default the same 
across all platforms. It would be nice to get the windows side working, 
I had assumed that would be fairly easy because the patches exist in 
Ezekiel's series but maybe I'm missing something. I'm also hopeless at 
keeping track of when the next release is so maybe there isn't much time.

Thanks

Phillip

Re: [PATCH RFC v2 0/7] Introduce Rust and announce that it will become mandatorty

[Patrick Steinhardt]

On Wed, Sep 10, 2025 at 10:32:02AM +0100, Phillip Wood wrote:
> On 10/09/2025 09:21, Patrick Steinhardt wrote:
> > On Tue, Sep 09, 2025 at 10:12:39AM +0100, Phillip Wood wrote:
> > > On 05/09/2025 15:28, Patrick Steinhardt wrote:
> > > > 
> > > > I have a plan layed out in the BreakingChanges document that mentions
> > > > how I'm proposing to do the transition:
> > > > 
> > > >     1. We introduce it with auto-detection for Meson and default-disabled
> > > >        for our Makefile in Git 2.52.
> > > 
> > > I'm not sure how much this helps us. You've said elsewhere that you don't
> > > want to be inundated with bug reports which is fair enough, but I'm fairly
> > > skeptical that we're going to get enough people enabling this get a useful
> > > amount of early feedback. So I wonder if it would be better just to bite the
> > > bullet and enable it by default from the start. I think I saw Elijah making
> > > a similar argument elsewhere in this thread.
> > 
> > The patch series may not be ready for all platforms yet though. Windows
> > support is still untested and probably not working, so I first need to
> > get that done. This is basically the reason why I'm proposing to have it
> > auto-detected at first: I want to be able to iterate without breaking
> > any platforms yet.
> > 
> > How about we do a compromise: we initially introduce it
> > default-disabled, but default-enable it in the next release already
> > instead of first tying it to `-Dbreaking_changes=true`? That would
> > accelerate the proposed timeline a bit.
> 
> If we really can't get the windows support working before the next release
> then making it disabled by default on that platform makes sense and in that
> case it is probably simpler to make the default the same across all
> platforms. It would be nice to get the windows side working, I had assumed
> that would be fairly easy because the patches exist in Ezekiel's series but
> maybe I'm missing something. I'm also hopeless at keeping track of when the
> next release is so maybe there isn't much time.

Oh, it's probably not going to be hard, and yes, I'll pick the patches
from Ezekiel's series in the follow-up.

My intention here is to focus more on the overall roadmap in this patch
series though, so I'm trying to keep it as simple as possible initially.
Agreeing on the roadmap is the more important thing, and seeing that we
talk about a timeline that is going to stretch across at least a year I
don't see a reason why we would need to rush making this opt-out rather
than opt-in.

One step at a time :)

Patrick

[PATCH RFC v3 0/8] Introduce Rust and announce that it will become mandatorty

[Patrick Steinhardt]

Hi,

this small patch series introduces Rust into the core of Git. This patch
series is designed as a test balloon, similar to how we introduced test
balloons for C99 features in the past. The goal is threefold:

  - Give us some time to experiment with Rust and introduce proper build
    infrastructure.

  - Give distributors time to ease into the new toolchain requirements.
    Introducing Rust is impossible for some platforms and hard for
    others.

  - Announce that Git 3.0 will make Rust a mandatory part of our build
    infrastructure.

The test balloon itself is quite uninteresting: I've chosen to convert
the "varint.c" subsystem, mostly because it is trivial and does not have
any dependencies. But it does allow us to verify that C to Rust interop
works as expected, and to play around with tooling. All tests pass with
the "varint.rs" implementation.

For now, the series only contains support for Meson. If we agree to go
down this route I'll also introduce support for Rust into our Makefiles
at a later point in time.

Furthermore missing is additional tooling:

  - At least one CI job to verify that Rust builds and works as
    expected.

  - Tooling and CI jobs to ensure that we have consistent formatting via
    `cargo format`.

And probably lots more. As said, the entire goal is for us to have an
easy playground that we can experiment on and develop the infrastructure
incrementally without yet having to commit to anything.

I'm mostly splitting out the topic of introducing Rust from the larger
series that introduce it into xdiff so that we can focus more on the
actual process of introducing Rust into Git and less on the potential
features that we want to build on top of it.

Changes in v2:
  - Introduce support for building the Rust library via our Makefile.
  - Introduce a '-DWITH_RUST' define. This define is used to print
    whether or not Git is built with Rust via `git version
    --build-options`.
  - Adjust Meson to not depend on v1.9.0 and newer anymore.
  - Introduce a roadmap into our BreakingChanges document to explain how
    we'll iterate towards mandatory Rust support.
  - Rework the Fedora job to do a full compile-and-test run with Meson
    and breaking changes enabled.
  - Adapt our breaking-changes jobs to enable Rust support.
  - Link to v1: https://lore.kernel.org/r/20250904-b4-pks-rust-breaking-change-v1-0-3af1d25e0be9@pks.im

Changes in v3:
  - Reorder all uses of `WITH_RUST` after the include of "config.mak".
  - Add a test to verify overflow behaviour in Rust and explicitly use
    `add_wrapping()`.
  - Use explicit dependencies for the Rust library in our Makefile.
  - Fix Alma Linux CI job.
  - Stop tying maintenance of our LTS release to the availability of
    gcc-rs.
  - Add a fallback to Meson to use cargo directly.
  - I've fixed the Rust edition to 2018 for now. This is intentionally
    conservative so that we might be able to use Rust 1.49. For now, we
    don't have any reason to use a newer edition, either. So let's take
    the oldest version we can live with for now and then bump it as
    required.
  - Link to v2: https://lore.kernel.org/r/20250905-b4-pks-rust-breaking-change-v2-0-6939cbf4a0b8@pks.im

Thanks!

Patrick

---
Patrick Steinhardt (8):
      meson: add infrastructure to build internal Rust library
      Makefile: reorder sources after includes
      Makefile: introduce infrastructure to build internal Rust library
      help: report on whether or not Rust is enabled
      rust: implement a test balloon via the "varint" subsystem
      BreakingChanges: announce Rust becoming mandatory
      ci: convert "pedantic" job into full build with breaking changes
      ci: enable Rust for breaking-changes jobs

 .github/workflows/main.yml         |   4 +-
 .gitignore                         |   1 +
 .gitlab-ci.yml                     |   4 +-
 Cargo.lock                         |  22 ++++
 Cargo.toml                         |   9 ++
 Documentation/BreakingChanges.adoc |  41 +++++++
 Makefile                           | 214 ++++++++++++++++++++++---------------
 ci/install-dependencies.sh         |   8 +-
 ci/run-build-and-tests.sh          |  31 ++----
 help.c                             |   6 ++
 meson.build                        |  24 ++++-
 meson_options.txt                  |   2 +
 shared.mak                         |   1 +
 src/lib.rs                         |   1 +
 src/meson.build                    |  64 +++++++++++
 src/varint.rs                      |  95 ++++++++++++++++
 16 files changed, 411 insertions(+), 116 deletions(-)

Range-diff versus v2:

1:  3792d2518c < -:  ---------- meson: add infrastructure to build internal Rust library
-:  ---------- > 1:  d995aef28c meson: add infrastructure to build internal Rust library
-:  ---------- > 2:  610e97e435 Makefile: reorder sources after includes
2:  9c3a78cb1e ! 3:  8b6251d4d2 Makefile: introduce infrastructure to build internal Rust library
    @@ .gitignore
     @@
      /fuzz_corpora
     +/target/
    -+/Cargo.lock
      /GIT-BUILD-DIR
      /GIT-BUILD-OPTIONS
      /GIT-CFLAGS
     
    - ## Cargo.toml (new) ##
    -@@
    -+[package]
    -+name = "git"
    -+version = "0.1.0"
    -+edition = "2021"
    -+
    -+[lib]
    -+crate-type = ["staticlib"]
    -+
    -+[dependencies]
    -
      ## Makefile ##
     @@ Makefile: include shared.mak
      # Define LIBPCREDIR=/foo/bar if your PCRE header and library files are
    @@ Makefile: include shared.mak
      # == SHA-1 and SHA-256 defines ==
      #
      # === SHA-1 backend ===
    +@@ Makefile: OBJECTS =
    + OTHER_PROGRAMS =
    + PROGRAM_OBJS =
    + PROGRAMS =
    ++RUST_SOURCES =
    + EXCLUDED_PROGRAMS =
    + SCRIPT_PERL =
    + SCRIPT_PYTHON =
     @@ Makefile: TEST_SHELL_PATH = $(SHELL_PATH)
      LIB_FILE = libgit.a
      XDIFF_LIB = xdiff/lib.a
    @@ Makefile: TEST_SHELL_PATH = $(SHELL_PATH)
     +RUST_LIB = target/release/libgit.a
     +endif
      
    - GENERATED_H += command-list.h
    - GENERATED_H += config-list.h
    -@@ Makefile: CLAR_TEST_OBJS += $(UNIT_TEST_DIR)/unit-test.o
    - 
    - UNIT_TEST_OBJS += $(UNIT_TEST_DIR)/test-lib.o
    - 
    --# xdiff and reftable libs may in turn depend on what is in libgit.a
    --GITLIBS = common-main.o $(LIB_FILE) $(XDIFF_LIB) $(REFTABLE_LIB) $(LIB_FILE)
    -+GITLIBS = common-main.o $(LIB_FILE) $(XDIFF_LIB) $(REFTABLE_LIB)
    -+ifdef WITH_RUST
    -+GITLIBS += $(RUST_LIB)
    -+endif
    -+# Other libs may in turn depend on what is in libgit.a.
    -+GITLIBS += $(LIB_FILE)
    - EXTLIBS =
    - 
    - GIT_USER_AGENT = git/$(GIT_VERSION)
    + # xdiff and reftable libs may in turn depend on what is in libgit.a
    + GITLIBS = common-main.o $(LIB_FILE) $(XDIFF_LIB) $(REFTABLE_LIB) $(LIB_FILE)
     @@ Makefile: BASIC_LDFLAGS =
      ARFLAGS = rcs
      PTHREAD_CFLAGS =
    @@ Makefile: BASIC_LDFLAGS =
     +CARGO_ARGS += --release
     +endif
     +
    + # For the 'sparse' target
    + SPARSE_FLAGS ?= -std=gnu99 -D__STDC_NO_VLA__
    + SP_EXTRA_FLAGS =
    +@@ Makefile: CLAR_TEST_OBJS += $(UNIT_TEST_DIR)/unit-test.o
    + 
    + UNIT_TEST_OBJS += $(UNIT_TEST_DIR)/test-lib.o
    + 
    ++RUST_SOURCES += src/lib.rs
    ++
    + GIT-VERSION-FILE: FORCE
    + 	@OLD=$$(cat $@ 2>/dev/null || :) && \
    + 	$(call version_gen,"$(shell pwd)",GIT-VERSION-FILE.in,$@) && \
    +@@ Makefile: endif
    + ALL_CFLAGS = $(DEVELOPER_CFLAGS) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_APPEND)
    + ALL_LDFLAGS = $(LDFLAGS) $(LDFLAGS_APPEND)
    + 
     +ifdef WITH_RUST
     +BASIC_CFLAGS += -DWITH_RUST
    ++GITLIBS += $(RUST_LIB)
     +endif
     +
    - # For the 'sparse' target
    - SPARSE_FLAGS ?= -std=gnu99 -D__STDC_NO_VLA__
    - SP_EXTRA_FLAGS =
    + ifdef SANITIZE
    + SANITIZERS := $(foreach flag,$(subst $(comma),$(space),$(SANITIZE)),$(flag))
    + BASIC_CFLAGS += -fsanitize=$(SANITIZE) -fno-sanitize-recover=$(SANITIZE)
     @@ Makefile: scalar$X: scalar.o GIT-LDFLAGS $(GITLIBS)
      $(LIB_FILE): $(LIB_OBJS)
      	$(QUIET_AR)$(RM) $@ && $(AR) $(ARFLAGS) $@ $^
      
    -+$(RUST_LIB): FORCE
    -+	@OLD_STAT="$$(stat $@ 2>/dev/null)"; \
    -+	    cargo build $(CARGO_ARGS); \
    -+	    if test $$? != 0 || test x"$$OLD_STAT" != x"$$(stat $@ 2>/dev/null)"; then \
    -+		echo '   ' CARGO $@; \
    -+	    fi
    ++$(RUST_LIB): Cargo.toml $(RUST_SOURCES)
    ++	$(QUIET_CARGO)cargo build $(CARGO_ARGS)
     +
     +.PHONY: rust
     +rust: $(RUST_LIB)
    @@ Makefile: clean: profile-clean coverage-clean cocciclean
      	$(RM) $(FUZZ_PROGRAMS)
      	$(RM) $(SP_OBJ)
      	$(RM) $(HCC)
    -+	$(RM) -r target/ Cargo.lock
    ++	$(RM) -r target/
      	$(RM) version-def.h
      	$(RM) -r $(dep_dirs) $(compdb_dir) compile_commands.json
      	$(RM) $(test_bindir_programs)
    +
    + ## shared.mak ##
    +@@ shared.mak: ifndef V
    + 	QUIET_MKDIR_P_PARENT  = @echo '   ' MKDIR -p $(@D);
    + 
    + ## Used in "Makefile"
    ++	QUIET_CARGO    = @echo '   ' CARGO $@;
    + 	QUIET_CC       = @echo '   ' CC $@;
    + 	QUIET_AR       = @echo '   ' AR $@;
    + 	QUIET_LINK     = @echo '   ' LINK $@;
3:  d83c8c2b14 = 4:  0335ff2303 help: report on whether or not Rust is enabled
4:  f9dd2ecb73 ! 5:  318212c5c9 rust: implement a test balloon via the "varint" subsystem
    @@ Makefile: LIB_OBJS += urlmatch.o
      LIB_OBJS += version.o
      LIB_OBJS += versioncmp.o
      LIB_OBJS += walker.o
    +@@ Makefile: CLAR_TEST_OBJS += $(UNIT_TEST_DIR)/unit-test.o
    + UNIT_TEST_OBJS += $(UNIT_TEST_DIR)/test-lib.o
    + 
    + RUST_SOURCES += src/lib.rs
    ++RUST_SOURCES += src/varint.rs
    + 
    + GIT-VERSION-FILE: FORCE
    + 	@OLD=$$(cat $@ 2>/dev/null || :) && \
     
      ## meson.build ##
     @@ meson.build: libgit_sources = [
    @@ src/lib.rs
     
      ## src/meson.build ##
     @@
    - libgit_rs = static_library('git_rs',
    -   sources: [
    -     'lib.rs',
    -+    'varint.rs',
    -   ],
    -   rust_crate_type: 'staticlib',
    - )
    + libgit_rs_sources = [
    +   'lib.rs',
    ++  'varint.rs',
    + ]
    + 
    + if meson.version().version_compare('>=1.5.0')
     
      ## src/varint.rs (new) ##
     @@
    @@ src/varint.rs (new)
     +    buf = buf.add(1);
     +
     +    while (c & 128) != 0 {
    -+        val += 1;
    ++        val = val.wrapping_add(1);
     +        if val == 0 || val.leading_zeros() < 7 {
     +            return 0; // overflow
     +        }
    @@ src/varint.rs (new)
     +            assert_eq!(decode_varint(&mut [0x80, 0x00].as_slice().as_ptr()), 128);
     +            assert_eq!(decode_varint(&mut [0x80, 0x01].as_slice().as_ptr()), 129);
     +            assert_eq!(decode_varint(&mut [0x80, 0x7f].as_slice().as_ptr()), 255);
    ++
    ++            // Overflows are expected to return 0.
    ++            assert_eq!(decode_varint(&mut [0x88; 16].as_slice().as_ptr()), 0);
     +        }
     +    }
     +
5:  5d411a195f ! 6:  a540626932 BreakingChanges: announce Rust becoming mandatory
    @@ Commit message
         Rust is a major change though and has ramifications for the whole
         ecosystem:
     
    -      - Some platforms haven't yet been able to implement a Rust toolchain,
    -        even though it is possible in theory.
    +      - Some platforms have a Rust toolchain available, but have not yet
    +        integrated it into their build infrastructure.
     
           - Some platforms don't have any support for Rust at all.
     
    @@ Documentation/BreakingChanges.adoc: A prerequisite for this change is that the e
      JGit, libgit2 and Gitoxide need to support it.
      
     +* Git will require Rust as a mandatory part of the build process. While Git
    -+  already started to adopt Rust in the Git 2.52, all parts written in Rust are
    ++  already started to adopt Rust in Git 2.52, all parts written in Rust are
     +  optional for the time being. This includes:
     ++
     +  ** Subsystems that have an alternative implementation in Rust to test
    @@ Documentation/BreakingChanges.adoc: A prerequisite for this change is that the e
     +for Rust becoming a mandatory part of the build process. There will be multiple
     +milestones for the introduction of Rust:
     ++
    -+1. Initially, with Git 2.52, support for Rust will be auto-detected by Rust and
    ++1. Initially, with Git 2.52, support for Rust will be auto-detected by Meson and
     +   disabled in our Makefile so that the project can sort out the initial
     +   infrastructure.
    -+2. In Git 2.53, support for Rust will be made mandatory in case Git is compiled
    -+   with breaking changes. Breaking changes can be enabled for Meson by saying
    -+   `meson configure -Dbreaking_changes=true` and for Makefiles via `make
    -+   WITH_BREAKING_CHANGES=YesPlease`. It will still be possible to compile with
    -+   breaking changes, but explicitly disable Rust.
    -+3. In Git 2.54, both build systems will default-enable support for Rust so that
    -+   builds will break if Rust is not available on the build host. The use of Rust
    -+   can still be explicitly disabled via build flags.
    ++2. In Git 2.53, support for Rust will be enabled by default in case Git is
    ++   compiled with breaking changes. Breaking changes can be enabled for Meson by
    ++   saying `meson configure -Dbreaking_changes=true` and for Makefile-based
    ++   builds via `make WITH_BREAKING_CHANGES=YesPlease`. It will still be possible
    ++   to compile with breaking changes, but explicitly disable Rust.
    ++3. In Git 2.54, both build systems will default-enable support for Rust even
    ++   when breaking changes aren't enabled. Consequently, builds will break by
    ++   default if Rust is not available on the build host. The use of Rust can still
    ++   be explicitly disabled via build flags.
     +4. In Git 3.0, the build options will be removed and support for Rust is
     +   mandatory.
     ++
    @@ Documentation/BreakingChanges.adoc: A prerequisite for this change is that the e
     +respectively.
     ++
     +The Git project will declare the last version before Git 3.0 to be a long-term
    -+support release that is maintained until alternate Rust backends like gcc-rs are
    -+able to build Git. The Git project may need to rely on distributions to help
    -+with identifying and backporting important bugfixes.
    ++support release. This long-term release will receive important bug fixes for at
    ++least four release cycles and security fixes for six release cycles. The Git
    ++project will hand over maintainership of the long-term release to distributors
    ++in case they need to extend the life of that long-term release even further. In
    ++that case, the backporting process will be handled by these distributors, but
    ++the backported patches will be reviewed on the mailing list and pulled in by the
    ++Git maintainer.
     +
      === Removals
      
6:  210225628a ! 7:  d4459e0294 ci: convert "pedantic" job into full build with breaking changes
    @@ .gitlab-ci.yml: test:linux:
     
      ## ci/install-dependencies.sh ##
     @@ ci/install-dependencies.sh: alpine-*)
    + 		bash cvs gnupg perl-cgi perl-dbd-sqlite perl-io-tty >/dev/null
      	;;
      fedora-*|almalinux-*)
    ++	case "$jobname" in
    ++	*-meson)
    ++		MESON_DEPS="meson ninja";;
    ++	esac
      	dnf -yq update >/dev/null &&
     -	dnf -yq install shadow-utils sudo make gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null
    -+	dnf -yq install shadow-utils sudo meson ninja pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null
    ++	dnf -yq install shadow-utils sudo make pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel $MESON_DEPS >/dev/null
      	;;
      ubuntu-*|i386/ubuntu-*|debian-*)
      	# Required so that apt doesn't wait for user input on certain packages.
7:  e6cc22407f ! 8:  5893f85cee ci: enable Rust for breaking-changes jobs
    @@ Commit message
         Signed-off-by: Patrick Steinhardt <ps@pks.im>
     
      ## ci/install-dependencies.sh ##
    -@@ ci/install-dependencies.sh: alpine-*)
    - 	;;
    - fedora-*|almalinux-*)
    +@@ ci/install-dependencies.sh: fedora-*|almalinux-*)
    + 		MESON_DEPS="meson ninja";;
    + 	esac
      	dnf -yq update >/dev/null &&
    --	dnf -yq install shadow-utils sudo meson ninja pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null
    -+	dnf -yq install shadow-utils sudo meson ninja pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel rustc >/dev/null
    +-	dnf -yq install shadow-utils sudo make pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel $MESON_DEPS >/dev/null
    ++	dnf -yq install shadow-utils sudo make pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel $MESON_DEPS rustc >/dev/null
      	;;
      ubuntu-*|i386/ubuntu-*|debian-*)
      	# Required so that apt doesn't wait for user input on certain packages.

---
base-commit: 2462961280690837670d997bde64bd4ebf8ae66d
change-id: 20250904-b4-pks-rust-breaking-change-7167d9d3e37d

[PATCH RFC v3 1/8] meson: add infrastructure to build internal Rust library

[Patrick Steinhardt]

Add the infrastructure into Meson to build an internal Rust library.
Building the Rust parts of Git are for now entirely optional, as they
are mostly intended as a test balloon for both Git developers, but also
for distributors of Git. So for now, they may contain:

  - New features that are not mission critical to Git and that users can
    easily live without.

  - Alternative implementations of small subsystems.

If these test balloons are successful, we will eventually make Rust a
mandatory dependency for our build process in Git 3.0.

The availability of a Rust toolchain will be auto-detected by Meson at
setup time. This behaviour can be tweaked via the `-Drust=` feature
toggle.

Next to the linkable Rust library, also wire up tests that can be
executed via `meson test`. This allows us to use the native unit testing
capabilities of Rust.

Note that the Rust edition is currently set to 2018. This edition is
supported by Rust 1.49, which is the target for the upcoming gcc-rs
backend. For now we don't use any features of Rust that would require a
newer version, so settling on this old version makes sense so that
gcc-rs may become an alternative backend for compiling Git. If we _do_
want to introduce features that were added in more recent editions of
Rust though we should reevaluate that choice.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 Cargo.lock        | 22 +++++++++++++++++++
 Cargo.toml        |  9 ++++++++
 meson.build       | 19 ++++++++++++++++-
 meson_options.txt |  2 ++
 src/lib.rs        |  0
 src/meson.build   | 63 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 6 files changed, 114 insertions(+), 1 deletion(-)

diff --git a/Cargo.lock b/Cargo.lock
new file mode 100644
index 00000000000..2b80a01e22a
--- /dev/null
+++ b/Cargo.lock
@@ -0,0 +1,22 @@
+# This file is automatically @generated by Cargo.
+# It is not intended for manual editing.
+# Fix this to version 3. This is required so that older toolchains can still
+# read the lock file. Furthermore, while an argument could be made that we
+# should not even commit the "Cargo.lock" file in the first place, there's two
+# reasons to still do so:
+#
+#   - It thwarts supply-chain attacks by committing checksums into the
+#     repository.
+#
+#   - It is required by Meson so that it can extract Cargo dependencies.
+#
+# Cargo dependencies can be accessed in Meson via:
+#
+#   dependency('${package_name}-${package_api_version}-rs')
+#
+# E.g. with a dependency "time-0.3.43", you would pass "time-0.3-rs".
+version = 3
+
+[[package]]
+name = "git"
+version = "0.1.0"
diff --git a/Cargo.toml b/Cargo.toml
new file mode 100644
index 00000000000..b9a41dbc792
--- /dev/null
+++ b/Cargo.toml
@@ -0,0 +1,9 @@
+[package]
+name = "git"
+version = "0.1.0"
+edition = "2018"
+
+[lib]
+crate-type = ["staticlib"]
+
+[dependencies]
diff --git a/meson.build b/meson.build
index e8ec0eca165..3d6601225ba 100644
--- a/meson.build
+++ b/meson.build
@@ -220,7 +220,7 @@ project('git', 'c',
   # learned to define __STDC_VERSION__ with C11 and later. We thus require
   # GNU C99 and fall back to C11. Meson only learned to handle the fallback
   # with version 1.3.0, so on older versions we use GNU C99 unconditionally.
-  default_options: meson.version().version_compare('>=1.3.0') ? ['c_std=gnu99,c11'] : ['c_std=gnu99'],
+  default_options: meson.version().version_compare('>=1.3.0') ? ['rust_std=2018', 'c_std=gnu99,c11'] : ['rust_std=2018', 'c_std=gnu99'],
 )
 
 fs = import('fs')
@@ -1702,6 +1702,22 @@ version_def_h = custom_target(
 )
 libgit_sources += version_def_h
 
+# Starting with Meson 1.5, it knows to parse the "Cargo.lock" file and extract
+# dependencies from it. So from hereon we don't need Cargo anymore to build
+# Git.
+if meson.version().version_compare('>=1.5.0')
+  rust_available = add_languages('rust', native: false, required: get_option('rust'))
+else
+  cargo = find_program('cargo', dirs: program_path, native: true, required: get_option('rust'))
+  rust_available = cargo.found()
+endif
+rust_option = get_option('rust').disable_auto_if(not rust_available)
+
+if rust_option.allowed()
+  subdir('src')
+  libgit_c_args += '-DWITH_RUST'
+endif
+
 libgit = declare_dependency(
   link_with: static_library('git',
     sources: libgit_sources,
@@ -2239,6 +2255,7 @@ summary({
   'pcre2': pcre2,
   'perl': perl_features_enabled,
   'python': target_python.found(),
+  'rust': rust_option.allowed(),
 }, section: 'Auto-detected features', bool_yn: true)
 
 summary({
diff --git a/meson_options.txt b/meson_options.txt
index 1668f260a18..143dee9237c 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -71,6 +71,8 @@ option('zlib_backend', type: 'combo', choices: ['auto', 'zlib', 'zlib-ng'], valu
 # Build tweaks.
 option('breaking_changes', type: 'boolean', value: false,
   description: 'Enable upcoming breaking changes.')
+option('rust', type: 'feature', value: 'auto',
+  description: 'Enable building with Rust.')
 option('macos_use_homebrew_gettext', type: 'boolean', value: true,
   description: 'Use gettext from Homebrew instead of the slightly-broken system-provided one.')
 
diff --git a/src/lib.rs b/src/lib.rs
new file mode 100644
index 00000000000..e69de29bb2d
diff --git a/src/meson.build b/src/meson.build
new file mode 100644
index 00000000000..59e810b4d41
--- /dev/null
+++ b/src/meson.build
@@ -0,0 +1,63 @@
+libgit_rs_sources = [
+  'lib.rs',
+]
+
+if meson.version().version_compare('>=1.5.0')
+  libgit_rs = static_library('git_rs',
+    sources: libgit_rs_sources,
+    rust_abi: 'c',
+  )
+
+  # The Rust module does not seem to work on macOS as expected right now. As
+  # such, we only conditionally enable tests.
+  if get_option('tests') and host_machine.system() != 'darwin'
+    rustmod = import('rust')
+    rustmod.test('rust', libgit_rs)
+  endif
+else
+  cargo_command = [
+    cargo,
+    'build',
+    '--lib',
+    '--quiet',
+    '--manifest-path',
+    meson.project_source_root() / 'Cargo.toml',
+    '--target-dir',
+    meson.current_build_dir() / 'target',
+    # `--out-dir` is unstable, but supported since 2018. It's been recently
+    # renamed to `--artifact-dir`, but for now both options are supported.
+    '-Z',
+    'unstable-options',
+    '--out-dir',
+    meson.current_build_dir(),
+  ]
+
+  if get_option('buildtype') == 'release'
+    cargo_command += '--release'
+  endif
+
+  libgit_rs = custom_target('git_rs',
+    input: libgit_rs_sources + [
+      meson.project_source_root() / 'Cargo.lock',
+      meson.project_source_root() / 'Cargo.toml',
+    ],
+    output: 'libgit.a',
+    command: cargo_command,
+  )
+
+  if get_option('tests')
+    test('rust', cargo,
+      args: [
+        'test',
+        '--manifest-path',
+        meson.project_source_root() / 'Cargo.toml',
+        '--target-dir',
+        meson.current_build_dir() / 'target',
+      ],
+      timeout: 0,
+      protocol: 'rust',
+    )
+  endif
+endif
+
+libgit_dependencies += declare_dependency(link_with: libgit_rs)

-- 
2.51.0.417.g1ba7204a04.dirty

Re: [PATCH RFC v3 1/8] meson: add infrastructure to build internal Rust library

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 3373 bytes --]

On 2025-09-08 at 14:13:08, Patrick Steinhardt wrote:
> diff --git a/Cargo.lock b/Cargo.lock
> new file mode 100644
> index 00000000000..2b80a01e22a
> --- /dev/null
> +++ b/Cargo.lock
> @@ -0,0 +1,22 @@
> +# This file is automatically @generated by Cargo.
> +# It is not intended for manual editing.
> +# Fix this to version 3. This is required so that older toolchains can still
> +# read the lock file. Furthermore, while an argument could be made that we
> +# should not even commit the "Cargo.lock" file in the first place, there's two
> +# reasons to still do so:
> +#
> +#   - It thwarts supply-chain attacks by committing checksums into the
> +#     repository.
> +#
> +#   - It is required by Meson so that it can extract Cargo dependencies.

If we check this in, then we basically cannot use any dependencies.  As
I mentioned elsewhere, the problem is that invariably, if we're going to
pin to an older version of Rust, we're going to be faced with the
problem that some crate is going to require a security update that is
also going to break older versions of Rust, and we will then have users
aggressively demanding on the list that we update it immediately and
ship a new release, breaking those older compilers.  (And yes, I've seen
this happen with Go dependencies on Git LFS, even when the vulnerable
code is not used.)

This is made worse by the fact that you want to support Rust 1.49
instead of Rust 1.63, as I proposed.  Absent some compelling proposal on
how we're going to deal with this situation, I think we need to omit
`Cargo.lock`.

I think the better approach is to leave it out and use Cargo to build
the Rust code instead of having Meson do it directly.

> +# Starting with Meson 1.5, it knows to parse the "Cargo.lock" file and extract
> +# dependencies from it. So from hereon we don't need Cargo anymore to build
> +# Git.

Ah, yes, I've already broken this in my branch (early this morning, in
fact).  I've added a `build.rs` file (used by Cargo) which is necessary
to properly link the tests against `libgit.a`.  (I'm using the hashing
code in some of my tests.) Meson fails to honour that and so the
compilation breaks.

I don't think it's going to be viable to try to maintain two separate
build systems that build the Rust code.  Everyone who uses rust-analyzer
(the Rust LSP) will use Cargo because that's the build system it uses,
and everyone uses Cargo anyway, so as a practical matter we need to
support it.  Trying to have Meson do its own thing is unlikely to work
here, and it demands that we use the `Cargo.lock` file, which we'd like
to avoid.

> +  cargo_command = [
> +    cargo,
> +    'build',
> +    '--lib',
> +    '--quiet',
> +    '--manifest-path',
> +    meson.project_source_root() / 'Cargo.toml',
> +    '--target-dir',
> +    meson.current_build_dir() / 'target',
> +    # `--out-dir` is unstable, but supported since 2018. It's been recently
> +    # renamed to `--artifact-dir`, but for now both options are supported.
> +    '-Z',
> +    'unstable-options',

`-Z` is only accepted in nightly versions of the compiler.  This won't
work with stable Rust and it definitely won't work with either 1.63 or
1.49.  It didn't work for me using Rust 1.89.0 when I removed the other
branch.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [PATCH RFC v3 1/8] meson: add infrastructure to build internal Rust library

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 677 bytes --]

On 2025-09-08 at 22:09:37, brian m. carlson wrote:
> Ah, yes, I've already broken this in my branch (early this morning, in
> fact).  I've added a `build.rs` file (used by Cargo) which is necessary
> to properly link the tests against `libgit.a`.  (I'm using the hashing
> code in some of my tests.) Meson fails to honour that and so the
> compilation breaks.

If you're interested in seeing what I mean, you can clone my
`sha256-interop-part-2` from https://github.com/bk2204/git.git, which
has your v2 merged into it.  You can do `make -j12 all` and then `cargo
test`, which should work and pass the tests.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [PATCH RFC v3 1/8] meson: add infrastructure to build internal Rust library

[Patrick Steinhardt]

On Mon, Sep 08, 2025 at 10:09:37PM +0000, brian m. carlson wrote:
> On 2025-09-08 at 14:13:08, Patrick Steinhardt wrote:
> > diff --git a/Cargo.lock b/Cargo.lock
> > new file mode 100644
> > index 00000000000..2b80a01e22a
> > --- /dev/null
> > +++ b/Cargo.lock
> > @@ -0,0 +1,22 @@
> > +# This file is automatically @generated by Cargo.
> > +# It is not intended for manual editing.
> > +# Fix this to version 3. This is required so that older toolchains can still
> > +# read the lock file. Furthermore, while an argument could be made that we
> > +# should not even commit the "Cargo.lock" file in the first place, there's two
> > +# reasons to still do so:
> > +#
> > +#   - It thwarts supply-chain attacks by committing checksums into the
> > +#     repository.
> > +#
> > +#   - It is required by Meson so that it can extract Cargo dependencies.
> 
> If we check this in, then we basically cannot use any dependencies.  As
> I mentioned elsewhere, the problem is that invariably, if we're going to
> pin to an older version of Rust, we're going to be faced with the
> problem that some crate is going to require a security update that is
> also going to break older versions of Rust, and we will then have users
> aggressively demanding on the list that we update it immediately and
> ship a new release, breaking those older compilers.  (And yes, I've seen
> this happen with Go dependencies on Git LFS, even when the vulnerable
> code is not used.)

Hm. This one just feels weird to me. Doesn't it break reproducible
builds and create new attack vectors for supply-chain attacks?

> This is made worse by the fact that you want to support Rust 1.49
> instead of Rust 1.63, as I proposed.  Absent some compelling proposal on
> how we're going to deal with this situation, I think we need to omit
> `Cargo.lock`.

Just to clarify: this is only initially, until we have a good reason to
pick a later version of Rust. Right now, to the best of my knowledge
(and please correct me if I'm wrong), we don't have any reason to use
Rust 1.63 yet.

I'd like to pick the minimum version with a certain intent, where the
current intent is that 1.49 may ease the pressure on downstream users of
Git via gcc-rs at one point in time. Once there are reasons for why we
want a newer version of Rust though we should definitely discuss whether
it makes sense for us to bump the requirements.

Does that make sense?

> I think the better approach is to leave it out and use Cargo to build
> the Rust code instead of having Meson do it directly.
> 
> > +# Starting with Meson 1.5, it knows to parse the "Cargo.lock" file and extract
> > +# dependencies from it. So from hereon we don't need Cargo anymore to build
> > +# Git.
> 
> Ah, yes, I've already broken this in my branch (early this morning, in
> fact).  I've added a `build.rs` file (used by Cargo) which is necessary
> to properly link the tests against `libgit.a`.  (I'm using the hashing
> code in some of my tests.) Meson fails to honour that and so the
> compilation breaks.

Too bad.

> I don't think it's going to be viable to try to maintain two separate
> build systems that build the Rust code.  Everyone who uses rust-analyzer
> (the Rust LSP) will use Cargo because that's the build system it uses,
> and everyone uses Cargo anyway, so as a practical matter we need to
> support it.  Trying to have Meson do its own thing is unlikely to work
> here, and it demands that we use the `Cargo.lock` file, which we'd like
> to avoid.

Unfortunate, but probably fair. Let's take the simple route for now and
potentially iterate down the road.

> > +  cargo_command = [
> > +    cargo,
> > +    'build',
> > +    '--lib',
> > +    '--quiet',
> > +    '--manifest-path',
> > +    meson.project_source_root() / 'Cargo.toml',
> > +    '--target-dir',
> > +    meson.current_build_dir() / 'target',
> > +    # `--out-dir` is unstable, but supported since 2018. It's been recently
> > +    # renamed to `--artifact-dir`, but for now both options are supported.
> > +    '-Z',
> > +    'unstable-options',
> 
> `-Z` is only accepted in nightly versions of the compiler.  This won't
> work with stable Rust and it definitely won't work with either 1.63 or
> 1.49.  It didn't work for me using Rust 1.89.0 when I removed the other
> branch.

Huh, weird. No idea why it works on my system with Rust 1.89.0 then.

It's kind of puzzling that something as simple as specifying where Cargo
puts the build artifacts is a nightly feature. All I really want is to
say `cargo build -o $PATH`. Oh, well...

Patrick

[PATCH RFC v3 2/8] Makefile: reorder sources after includes

[Patrick Steinhardt]

In an upcoming change we'll make some of the sources compile
conditionally based on whether or not `WITH_RUST` is defined. To let
developers specify that flag in their "config.mak" we'll thus have to
reorder our sources so that they come after the include of that file.

Do so.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 Makefile | 176 +++++++++++++++++++++++++++++++--------------------------------
 1 file changed, 88 insertions(+), 88 deletions(-)

diff --git a/Makefile b/Makefile
index 555b7f4dc3..7e52625d75 100644
--- a/Makefile
+++ b/Makefile
@@ -919,6 +919,94 @@ LIB_FILE = libgit.a
 XDIFF_LIB = xdiff/lib.a
 REFTABLE_LIB = reftable/libreftable.a
 
+# xdiff and reftable libs may in turn depend on what is in libgit.a
+GITLIBS = common-main.o $(LIB_FILE) $(XDIFF_LIB) $(REFTABLE_LIB) $(LIB_FILE)
+EXTLIBS =
+
+GIT_USER_AGENT = git/$(GIT_VERSION)
+
+ifeq ($(wildcard sha1collisiondetection/lib/sha1.h),sha1collisiondetection/lib/sha1.h)
+DC_SHA1_SUBMODULE = auto
+endif
+
+# Set CFLAGS, LDFLAGS and other *FLAGS variables. These might be
+# tweaked by config.* below as well as the command-line, both of
+# which'll override these defaults.
+# Older versions of GCC may require adding "-std=gnu99" at the end.
+CFLAGS = -g -O2 -Wall
+LDFLAGS =
+CC_LD_DYNPATH = -Wl,-rpath,
+BASIC_CFLAGS = -I.
+BASIC_LDFLAGS =
+
+# library flags
+ARFLAGS = rcs
+PTHREAD_CFLAGS =
+
+# For the 'sparse' target
+SPARSE_FLAGS ?= -std=gnu99 -D__STDC_NO_VLA__
+SP_EXTRA_FLAGS =
+
+# For informing GIT-BUILD-OPTIONS of the SANITIZE=leak,address targets
+SANITIZE_LEAK =
+SANITIZE_ADDRESS =
+
+# For the 'coccicheck' target
+SPATCH_INCLUDE_FLAGS = --all-includes
+SPATCH_FLAGS =
+SPATCH_TEST_FLAGS =
+
+# If *.o files are present, have "coccicheck" depend on them, with
+# COMPUTE_HEADER_DEPENDENCIES this will speed up the common-case of
+# only needing to re-generate coccicheck results for the users of a
+# given API if it's changed, and not all files in the project. If
+# COMPUTE_HEADER_DEPENDENCIES=no this will be unset too.
+SPATCH_USE_O_DEPENDENCIES = YesPlease
+
+# Set SPATCH_CONCAT_COCCI to concatenate the contrib/cocci/*.cocci
+# files into a single contrib/cocci/ALL.cocci before running
+# "coccicheck".
+#
+# Pros:
+#
+# - Speeds up a one-shot run of "make coccicheck", as we won't have to
+#   parse *.[ch] files N times for the N *.cocci rules
+#
+# Cons:
+#
+# - Will make incremental development of *.cocci slower, as
+#   e.g. changing strbuf.cocci will re-run all *.cocci.
+#
+# - Makes error and performance analysis harder, as rules will be
+#   applied from a monolithic ALL.cocci, rather than
+#   e.g. strbuf.cocci. To work around this either undefine this, or
+#   generate a specific patch, e.g. this will always use strbuf.cocci,
+#   not ALL.cocci:
+#
+#	make contrib/coccinelle/strbuf.cocci.patch
+SPATCH_CONCAT_COCCI = YesPlease
+
+# Rebuild 'coccicheck' if $(SPATCH), its flags etc. change
+TRACK_SPATCH_DEFINES =
+TRACK_SPATCH_DEFINES += $(SPATCH)
+TRACK_SPATCH_DEFINES += $(SPATCH_INCLUDE_FLAGS)
+TRACK_SPATCH_DEFINES += $(SPATCH_FLAGS)
+TRACK_SPATCH_DEFINES += $(SPATCH_TEST_FLAGS)
+GIT-SPATCH-DEFINES: FORCE
+	@FLAGS='$(TRACK_SPATCH_DEFINES)'; \
+	    if test x"$$FLAGS" != x"`cat GIT-SPATCH-DEFINES 2>/dev/null`" ; then \
+		echo >&2 "    * new spatch flags"; \
+		echo "$$FLAGS" >GIT-SPATCH-DEFINES; \
+            fi
+
+include config.mak.uname
+-include config.mak.autogen
+-include config.mak
+
+ifdef DEVELOPER
+include config.mak.dev
+endif
+
 GENERATED_H += command-list.h
 GENERATED_H += config-list.h
 GENERATED_H += hook-list.h
@@ -1387,94 +1475,6 @@ CLAR_TEST_OBJS += $(UNIT_TEST_DIR)/unit-test.o
 
 UNIT_TEST_OBJS += $(UNIT_TEST_DIR)/test-lib.o
 
-# xdiff and reftable libs may in turn depend on what is in libgit.a
-GITLIBS = common-main.o $(LIB_FILE) $(XDIFF_LIB) $(REFTABLE_LIB) $(LIB_FILE)
-EXTLIBS =
-
-GIT_USER_AGENT = git/$(GIT_VERSION)
-
-ifeq ($(wildcard sha1collisiondetection/lib/sha1.h),sha1collisiondetection/lib/sha1.h)
-DC_SHA1_SUBMODULE = auto
-endif
-
-# Set CFLAGS, LDFLAGS and other *FLAGS variables. These might be
-# tweaked by config.* below as well as the command-line, both of
-# which'll override these defaults.
-# Older versions of GCC may require adding "-std=gnu99" at the end.
-CFLAGS = -g -O2 -Wall
-LDFLAGS =
-CC_LD_DYNPATH = -Wl,-rpath,
-BASIC_CFLAGS = -I.
-BASIC_LDFLAGS =
-
-# library flags
-ARFLAGS = rcs
-PTHREAD_CFLAGS =
-
-# For the 'sparse' target
-SPARSE_FLAGS ?= -std=gnu99 -D__STDC_NO_VLA__
-SP_EXTRA_FLAGS =
-
-# For informing GIT-BUILD-OPTIONS of the SANITIZE=leak,address targets
-SANITIZE_LEAK =
-SANITIZE_ADDRESS =
-
-# For the 'coccicheck' target
-SPATCH_INCLUDE_FLAGS = --all-includes
-SPATCH_FLAGS =
-SPATCH_TEST_FLAGS =
-
-# If *.o files are present, have "coccicheck" depend on them, with
-# COMPUTE_HEADER_DEPENDENCIES this will speed up the common-case of
-# only needing to re-generate coccicheck results for the users of a
-# given API if it's changed, and not all files in the project. If
-# COMPUTE_HEADER_DEPENDENCIES=no this will be unset too.
-SPATCH_USE_O_DEPENDENCIES = YesPlease
-
-# Set SPATCH_CONCAT_COCCI to concatenate the contrib/cocci/*.cocci
-# files into a single contrib/cocci/ALL.cocci before running
-# "coccicheck".
-#
-# Pros:
-#
-# - Speeds up a one-shot run of "make coccicheck", as we won't have to
-#   parse *.[ch] files N times for the N *.cocci rules
-#
-# Cons:
-#
-# - Will make incremental development of *.cocci slower, as
-#   e.g. changing strbuf.cocci will re-run all *.cocci.
-#
-# - Makes error and performance analysis harder, as rules will be
-#   applied from a monolithic ALL.cocci, rather than
-#   e.g. strbuf.cocci. To work around this either undefine this, or
-#   generate a specific patch, e.g. this will always use strbuf.cocci,
-#   not ALL.cocci:
-#
-#	make contrib/coccinelle/strbuf.cocci.patch
-SPATCH_CONCAT_COCCI = YesPlease
-
-# Rebuild 'coccicheck' if $(SPATCH), its flags etc. change
-TRACK_SPATCH_DEFINES =
-TRACK_SPATCH_DEFINES += $(SPATCH)
-TRACK_SPATCH_DEFINES += $(SPATCH_INCLUDE_FLAGS)
-TRACK_SPATCH_DEFINES += $(SPATCH_FLAGS)
-TRACK_SPATCH_DEFINES += $(SPATCH_TEST_FLAGS)
-GIT-SPATCH-DEFINES: FORCE
-	@FLAGS='$(TRACK_SPATCH_DEFINES)'; \
-	    if test x"$$FLAGS" != x"`cat GIT-SPATCH-DEFINES 2>/dev/null`" ; then \
-		echo >&2 "    * new spatch flags"; \
-		echo "$$FLAGS" >GIT-SPATCH-DEFINES; \
-            fi
-
-include config.mak.uname
--include config.mak.autogen
--include config.mak
-
-ifdef DEVELOPER
-include config.mak.dev
-endif
-
 GIT-VERSION-FILE: FORCE
 	@OLD=$$(cat $@ 2>/dev/null || :) && \
 	$(call version_gen,"$(shell pwd)",GIT-VERSION-FILE.in,$@) && \

-- 
2.51.0.417.g1ba7204a04.dirty

[PATCH RFC v3 3/8] Makefile: introduce infrastructure to build internal Rust library

[Patrick Steinhardt]

Introduce infrastructure to build the internal Rust library. This
mirrors the infrastructure we have added to Meson in the preceding
commit. Developers can enable the infrastructure by passing the new
`WITH_RUST` build toggle.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 .gitignore |  1 +
 Makefile   | 37 +++++++++++++++++++++++++++++++++++++
 shared.mak |  1 +
 3 files changed, 39 insertions(+)

diff --git a/.gitignore b/.gitignore
index 1803023427..60c3ba2d97 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,4 +1,5 @@
 /fuzz_corpora
+/target/
 /GIT-BUILD-DIR
 /GIT-BUILD-OPTIONS
 /GIT-CFLAGS
diff --git a/Makefile b/Makefile
index 7e52625d75..94950a0ffe 100644
--- a/Makefile
+++ b/Makefile
@@ -483,6 +483,14 @@ include shared.mak
 # Define LIBPCREDIR=/foo/bar if your PCRE header and library files are
 # in /foo/bar/include and /foo/bar/lib directories.
 #
+# == Optional Rust support ==
+#
+# Define WITH_RUST if you want to include features and subsystems written in
+# Rust into Git. For now, Rust is still an optional feature of the build
+# process. With Git 3.0 though, Rust will always be enabled.
+#
+# Building Rust code requires Cargo.
+#
 # == SHA-1 and SHA-256 defines ==
 #
 # === SHA-1 backend ===
@@ -683,6 +691,7 @@ OBJECTS =
 OTHER_PROGRAMS =
 PROGRAM_OBJS =
 PROGRAMS =
+RUST_SOURCES =
 EXCLUDED_PROGRAMS =
 SCRIPT_PERL =
 SCRIPT_PYTHON =
@@ -918,6 +927,11 @@ TEST_SHELL_PATH = $(SHELL_PATH)
 LIB_FILE = libgit.a
 XDIFF_LIB = xdiff/lib.a
 REFTABLE_LIB = reftable/libreftable.a
+ifdef DEBUG
+RUST_LIB = target/debug/libgit.a
+else
+RUST_LIB = target/release/libgit.a
+endif
 
 # xdiff and reftable libs may in turn depend on what is in libgit.a
 GITLIBS = common-main.o $(LIB_FILE) $(XDIFF_LIB) $(REFTABLE_LIB) $(LIB_FILE)
@@ -943,6 +957,15 @@ BASIC_LDFLAGS =
 ARFLAGS = rcs
 PTHREAD_CFLAGS =
 
+# Rust flags
+CARGO_ARGS =
+ifndef V
+CARGO_ARGS += --quiet
+endif
+ifndef DEBUG
+CARGO_ARGS += --release
+endif
+
 # For the 'sparse' target
 SPARSE_FLAGS ?= -std=gnu99 -D__STDC_NO_VLA__
 SP_EXTRA_FLAGS =
@@ -1475,6 +1498,8 @@ CLAR_TEST_OBJS += $(UNIT_TEST_DIR)/unit-test.o
 
 UNIT_TEST_OBJS += $(UNIT_TEST_DIR)/test-lib.o
 
+RUST_SOURCES += src/lib.rs
+
 GIT-VERSION-FILE: FORCE
 	@OLD=$$(cat $@ 2>/dev/null || :) && \
 	$(call version_gen,"$(shell pwd)",GIT-VERSION-FILE.in,$@) && \
@@ -1504,6 +1529,11 @@ endif
 ALL_CFLAGS = $(DEVELOPER_CFLAGS) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_APPEND)
 ALL_LDFLAGS = $(LDFLAGS) $(LDFLAGS_APPEND)
 
+ifdef WITH_RUST
+BASIC_CFLAGS += -DWITH_RUST
+GITLIBS += $(RUST_LIB)
+endif
+
 ifdef SANITIZE
 SANITIZERS := $(foreach flag,$(subst $(comma),$(space),$(SANITIZE)),$(flag))
 BASIC_CFLAGS += -fsanitize=$(SANITIZE) -fno-sanitize-recover=$(SANITIZE)
@@ -2918,6 +2948,12 @@ scalar$X: scalar.o GIT-LDFLAGS $(GITLIBS)
 $(LIB_FILE): $(LIB_OBJS)
 	$(QUIET_AR)$(RM) $@ && $(AR) $(ARFLAGS) $@ $^
 
+$(RUST_LIB): Cargo.toml $(RUST_SOURCES)
+	$(QUIET_CARGO)cargo build $(CARGO_ARGS)
+
+.PHONY: rust
+rust: $(RUST_LIB)
+
 $(XDIFF_LIB): $(XDIFF_OBJS)
 	$(QUIET_AR)$(RM) $@ && $(AR) $(ARFLAGS) $@ $^
 
@@ -3768,6 +3804,7 @@ clean: profile-clean coverage-clean cocciclean
 	$(RM) $(FUZZ_PROGRAMS)
 	$(RM) $(SP_OBJ)
 	$(RM) $(HCC)
+	$(RM) -r target/
 	$(RM) version-def.h
 	$(RM) -r $(dep_dirs) $(compdb_dir) compile_commands.json
 	$(RM) $(test_bindir_programs)
diff --git a/shared.mak b/shared.mak
index 5c7bc94785..0e7492076e 100644
--- a/shared.mak
+++ b/shared.mak
@@ -56,6 +56,7 @@ ifndef V
 	QUIET_MKDIR_P_PARENT  = @echo '   ' MKDIR -p $(@D);
 
 ## Used in "Makefile"
+	QUIET_CARGO    = @echo '   ' CARGO $@;
 	QUIET_CC       = @echo '   ' CC $@;
 	QUIET_AR       = @echo '   ' AR $@;
 	QUIET_LINK     = @echo '   ' LINK $@;

-- 
2.51.0.417.g1ba7204a04.dirty

[PATCH RFC v3 4/8] help: report on whether or not Rust is enabled

[Patrick Steinhardt]

We're about to introduce support for Rust into the core of Git, where
some (trivial) subsystems are converted to Rust. These subsystems will
also retain a C implementation though as Rust is not yet mandatory.
Consequently, it now becomes possible for a Git version to have bugs
that are specific to whether or not it is built with Rust support
overall.

Expose information about whether or not Git was built with Rust via our
build info. This means that both `git version --build-options`, but also
`git bugreport` will now expose that bit of information. Hopefully, this
should make it easier for us to discover any Rust-specific issues.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 help.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/help.c b/help.c
index bb20498cfd..5854dd4a7e 100644
--- a/help.c
+++ b/help.c
@@ -791,6 +791,12 @@ void get_version_info(struct strbuf *buf, int show_build_options)
 		strbuf_addf(buf, "shell-path: %s\n", SHELL_PATH);
 		/* NEEDSWORK: also save and output GIT-BUILD_OPTIONS? */
 
+#if defined WITH_RUST
+		strbuf_addstr(buf, "rust: enabled\n");
+#else
+		strbuf_addstr(buf, "rust: disabled\n");
+#endif
+
 		if (fsmonitor_ipc__is_supported())
 			strbuf_addstr(buf, "feature: fsmonitor--daemon\n");
 #if defined LIBCURL_VERSION

-- 
2.51.0.417.g1ba7204a04.dirty

[PATCH RFC v3 5/8] rust: implement a test balloon via the "varint" subsystem

[Patrick Steinhardt]

Implement a trivial test balloon for our Rust build infrastructure by
reimplementing the "varint.c" subsystem in Rust. This subsystem is
chosen because it is trivial to convert and because it doesn't have any
dependencies to other components of Git.

If support for Rust is enabled, we stop compiling "varint.c" and instead
compile and use "src/varint.rs".

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 Makefile        |  3 ++
 meson.build     |  5 ++-
 src/lib.rs      |  1 +
 src/meson.build |  1 +
 src/varint.rs   | 95 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 104 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 94950a0ffe2..7640d0d76ac 100644
--- a/Makefile
+++ b/Makefile
@@ -1307,7 +1307,9 @@ LIB_OBJS += urlmatch.o
 LIB_OBJS += usage.o
 LIB_OBJS += userdiff.o
 LIB_OBJS += utf8.o
+ifndef WITH_RUST
 LIB_OBJS += varint.o
+endif
 LIB_OBJS += version.o
 LIB_OBJS += versioncmp.o
 LIB_OBJS += walker.o
@@ -1499,6 +1501,7 @@ CLAR_TEST_OBJS += $(UNIT_TEST_DIR)/unit-test.o
 UNIT_TEST_OBJS += $(UNIT_TEST_DIR)/test-lib.o
 
 RUST_SOURCES += src/lib.rs
+RUST_SOURCES += src/varint.rs
 
 GIT-VERSION-FILE: FORCE
 	@OLD=$$(cat $@ 2>/dev/null || :) && \
diff --git a/meson.build b/meson.build
index 3d6601225ba..48b80cb832c 100644
--- a/meson.build
+++ b/meson.build
@@ -522,7 +522,6 @@ libgit_sources = [
   'usage.c',
   'userdiff.c',
   'utf8.c',
-  'varint.c',
   'version.c',
   'versioncmp.c',
   'walker.c',
@@ -1716,6 +1715,10 @@ rust_option = get_option('rust').disable_auto_if(not rust_available)
 if rust_option.allowed()
   subdir('src')
   libgit_c_args += '-DWITH_RUST'
+else
+  libgit_sources += [
+    'varint.c',
+  ]
 endif
 
 libgit = declare_dependency(
diff --git a/src/lib.rs b/src/lib.rs
index e69de29bb2d..9da70d8b57d 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -0,0 +1 @@
+pub mod varint;
diff --git a/src/meson.build b/src/meson.build
index 59e810b4d41..03b71a5c7bd 100644
--- a/src/meson.build
+++ b/src/meson.build
@@ -1,5 +1,6 @@
 libgit_rs_sources = [
   'lib.rs',
+  'varint.rs',
 ]
 
 if meson.version().version_compare('>=1.5.0')
diff --git a/src/varint.rs b/src/varint.rs
new file mode 100644
index 00000000000..7e50cfa09fe
--- /dev/null
+++ b/src/varint.rs
@@ -0,0 +1,95 @@
+use std::os::raw::c_int;
+use std::os::raw::c_uchar;
+
+#[no_mangle]
+pub unsafe extern "C" fn decode_varint(bufp: *mut *const c_uchar) -> usize {
+    let mut buf = *bufp;
+    let mut c = *buf;
+    let mut val = usize::from(c & 127);
+
+    buf = buf.add(1);
+
+    while (c & 128) != 0 {
+        val = val.wrapping_add(1);
+        if val == 0 || val.leading_zeros() < 7 {
+            return 0; // overflow
+        }
+
+        c = *buf;
+        buf = buf.add(1);
+
+        val = (val << 7) + usize::from(c & 127);
+    }
+
+    *bufp = buf;
+    val
+}
+
+#[no_mangle]
+pub unsafe extern "C" fn encode_varint(value: usize, buf: *mut c_uchar) -> c_int {
+    let mut varint: [u8; 16] = [0; 16];
+    let mut pos = varint.len() - 1;
+
+    varint[pos] = (value & 127) as u8;
+
+    let mut value = value >> 7;
+    while value != 0 {
+        pos -= 1;
+        value -= 1;
+        varint[pos] = 128 | (value & 127) as u8;
+        value >>= 7;
+    }
+
+    if !buf.is_null() {
+        std::ptr::copy_nonoverlapping(varint.as_ptr().add(pos), buf, varint.len() - pos);
+    }
+
+    (varint.len() - pos) as c_int
+}
+
+#[cfg(test)]
+mod tests {
+    use super::*;
+
+    #[test]
+    fn test_decode_varint() {
+        unsafe {
+            assert_eq!(decode_varint(&mut [0x00].as_slice().as_ptr()), 0);
+            assert_eq!(decode_varint(&mut [0x01].as_slice().as_ptr()), 1);
+            assert_eq!(decode_varint(&mut [0x7f].as_slice().as_ptr()), 127);
+            assert_eq!(decode_varint(&mut [0x80, 0x00].as_slice().as_ptr()), 128);
+            assert_eq!(decode_varint(&mut [0x80, 0x01].as_slice().as_ptr()), 129);
+            assert_eq!(decode_varint(&mut [0x80, 0x7f].as_slice().as_ptr()), 255);
+
+            // Overflows are expected to return 0.
+            assert_eq!(decode_varint(&mut [0x88; 16].as_slice().as_ptr()), 0);
+        }
+    }
+
+    #[test]
+    fn test_encode_varint() {
+        unsafe {
+            let mut varint: [u8; 16] = [0; 16];
+
+            assert_eq!(encode_varint(0, std::ptr::null_mut()), 1);
+
+            assert_eq!(encode_varint(0, varint.as_mut_slice().as_mut_ptr()), 1);
+            assert_eq!(varint, [0; 16]);
+
+            assert_eq!(encode_varint(10, varint.as_mut_slice().as_mut_ptr()), 1);
+            assert_eq!(varint, [10, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+
+            assert_eq!(encode_varint(127, varint.as_mut_slice().as_mut_ptr()), 1);
+            assert_eq!(varint, [127, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+
+            assert_eq!(encode_varint(128, varint.as_mut_slice().as_mut_ptr()), 2);
+            assert_eq!(varint, [128, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+
+            assert_eq!(encode_varint(129, varint.as_mut_slice().as_mut_ptr()), 2);
+            assert_eq!(varint, [128, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+
+            assert_eq!(encode_varint(255, varint.as_mut_slice().as_mut_ptr()), 2);
+            assert_eq!(varint, [128, 127, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+        }
+    }
+}

-- 
2.51.0.417.g1ba7204a04.dirty

Re: [PATCH RFC v3 5/8] rust: implement a test balloon via the "varint" subsystem

[Ezekiel Newren]

On Mon, Sep 8, 2025 at 8:13 AM Patrick Steinhardt <ps@pks.im> wrote:
> +use std::os::raw::c_int;
> +use std::os::raw::c_uchar;

I'd really rather avoid using C types in Rust, in favor of using Rust
types in C. I have written a commit that talks about why C should use
Rust primitive types and why Rust should avoid using C types, here:
https://lore.kernel.org/git/2a7d5b05c18d4a96f1905b7043d47c62d367cd2a.1757274320.git.gitgitgadget@gmail.com/.
In my opinion, the type c_void is the only appropriate C type that
should be used on the Rust side, and should be used sparingly.

The std::os::raw::c_* directly inherits the problems of core::ffi,
which changes over time and seems to make a best guess at the correct
definition for a given platform/target. This probably isn't a problem
for all platforms that Rust supports currently, but can anyone say
that Rust got it right for all C compilers of all platforms/targets?

To give an example: c_long is defined in [1,2]

// Rust version 1.63.0
mod c_long_definition {
    cfg_if! {
        if #[cfg(all(target_pointer_width = "64", not(windows)))] {
            pub type c_long = i64;
            pub type NonZero_c_long = crate::num::NonZeroI64;
            pub type c_ulong = u64;
            pub type NonZero_c_ulong = crate::num::NonZeroU64;
        } else {
            // The minimal size of `long` in the C standard is 32 bits
            pub type c_long = i32;
            pub type NonZero_c_long = crate::num::NonZeroI32;
            pub type c_ulong = u32;
            pub type NonZero_c_ulong = crate::num::NonZeroU32;
        }
    }
}

// Rust version 1.89.0
mod c_long_definition {
    crate::cfg_select! {
        any(
            all(target_pointer_width = "64", not(windows)),
            // wasm32 Linux ABI uses 64-bit long
            all(target_arch = "wasm32", target_os = "linux")
        ) => {
            pub(super) type c_long = i64;
            pub(super) type c_ulong = u64;
        }
        _ => {
            // The minimal size of `long` in the C standard is 32 bits
            pub(super) type c_long = i32;
            pub(super) type c_ulong = u32;
        }
    }
}

[1] c_long in 1.63.0
https://doc.rust-lang.org/1.63.0/src/core/ffi/mod.rs.html#175-189:
[2] c_long in 1.89.0
https://doc.rust-lang.org/1.89.0/src/core/ffi/primitives.rs.html#135-151:

Re: [PATCH RFC v3 5/8] rust: implement a test balloon via the "varint" subsystem

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2206 bytes --]

On 2025-09-08 at 17:19:20, Ezekiel Newren wrote:
> On Mon, Sep 8, 2025 at 8:13 AM Patrick Steinhardt <ps@pks.im> wrote:
> > +use std::os::raw::c_int;
> > +use std::os::raw::c_uchar;
> 
> I'd really rather avoid using C types in Rust, in favor of using Rust
> types in C. I have written a commit that talks about why C should use
> Rust primitive types and why Rust should avoid using C types, here:
> https://lore.kernel.org/git/2a7d5b05c18d4a96f1905b7043d47c62d367cd2a.1757274320.git.gitgitgadget@gmail.com/.
> In my opinion, the type c_void is the only appropriate C type that
> should be used on the Rust side, and should be used sparingly.
> 
> The std::os::raw::c_* directly inherits the problems of core::ffi,
> which changes over time and seems to make a best guess at the correct
> definition for a given platform/target. This probably isn't a problem
> for all platforms that Rust supports currently, but can anyone say
> that Rust got it right for all C compilers of all platforms/targets?

It also poses problems because if we use `c_ulong` and it's 64 bit, then
trying to do a `.into()` to convert it to a `u64` will cause the
compiler and linters to complain, even if it does compile successfully.
But on 32-bit systems or Windows, `c_ulong` will be `u32` and it will be
required to convert, since Rust doesn't allow automatic conversion
between types.  I have some personal Rust code which works with
`mode_t`, which on some Unix systems is 16 bits and on some systems is
32 bits and it has made me want to scream quite a bit.  It gets even
worse if the types differ in signedness.

It would be better to do `usize` and `u8` on the Rust side here and
`size_t` and `uint8_t` on the C side.  I think `unsigned char` and `u8`
is also fine, since we are not targeting systems where `unsigned char`
is not 8 bits in size.

I don't know how you plan to deal with the fact that Rust doesn't expose
`uintmax_t`, but I think that's 64-bit on all known systems (because
making it 128-bit would break ABI and nobody wants to bump libc's
SONAME), so you could try `u64` and `uint64_t` for the value instead.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [PATCH RFC v3 5/8] rust: implement a test balloon via the "varint" subsystem

[Patrick Steinhardt]

On Mon, Sep 08, 2025 at 10:22:50PM +0000, brian m. carlson wrote:
> On 2025-09-08 at 17:19:20, Ezekiel Newren wrote:
> > On Mon, Sep 8, 2025 at 8:13 AM Patrick Steinhardt <ps@pks.im> wrote:
> > > +use std::os::raw::c_int;
> > > +use std::os::raw::c_uchar;
> > 
> > I'd really rather avoid using C types in Rust, in favor of using Rust
> > types in C. I have written a commit that talks about why C should use
> > Rust primitive types and why Rust should avoid using C types, here:
> > https://lore.kernel.org/git/2a7d5b05c18d4a96f1905b7043d47c62d367cd2a.1757274320.git.gitgitgadget@gmail.com/.
> > In my opinion, the type c_void is the only appropriate C type that
> > should be used on the Rust side, and should be used sparingly.
> > 
> > The std::os::raw::c_* directly inherits the problems of core::ffi,
> > which changes over time and seems to make a best guess at the correct
> > definition for a given platform/target. This probably isn't a problem
> > for all platforms that Rust supports currently, but can anyone say
> > that Rust got it right for all C compilers of all platforms/targets?
> 
> It also poses problems because if we use `c_ulong` and it's 64 bit, then
> trying to do a `.into()` to convert it to a `u64` will cause the
> compiler and linters to complain, even if it does compile successfully.
> But on 32-bit systems or Windows, `c_ulong` will be `u32` and it will be
> required to convert, since Rust doesn't allow automatic conversion
> between types.  I have some personal Rust code which works with
> `mode_t`, which on some Unix systems is 16 bits and on some systems is
> 32 bits and it has made me want to scream quite a bit.  It gets even
> worse if the types differ in signedness.
> 
> It would be better to do `usize` and `u8` on the Rust side here and
> `size_t` and `uint8_t` on the C side.  I think `unsigned char` and `u8`
> is also fine, since we are not targeting systems where `unsigned char`
> is not 8 bits in size.
> 
> I don't know how you plan to deal with the fact that Rust doesn't expose
> `uintmax_t`, but I think that's 64-bit on all known systems (because
> making it 128-bit would break ABI and nobody wants to bump libc's
> SONAME), so you could try `u64` and `uint64_t` for the value instead.

Fair. I think for now I'll add a preparatory patch to make the width of
integers explicit in the C part. But if we agree on the approach picked
by Ezekiel I think it does make sense to unify this towards Rust types
eventually.

Patrick

[PATCH RFC v3 6/8] BreakingChanges: announce Rust becoming mandatory

[Patrick Steinhardt]

Over the last couple of years the appetite for bringin Rust into the
codebase has grown significantly across the developer base. Introducing
Rust is a major change though and has ramifications for the whole
ecosystem:

  - Some platforms have a Rust toolchain available, but have not yet
    integrated it into their build infrastructure.

  - Some platforms don't have any support for Rust at all.

  - Some platforms may have to figure out how to fit Rust into their
    bootstrapping sequence.

Due to this, and given that Git is a critical piece of infrastructure
for the whole industry, we cannot just introduce such a heavyweight
dependency without doing our due diligence.

Instead, preceding commits have introduced a test balloon into our build
infrastructure that convert one tiny subsystem to use Rust. For now,
using Rust to build that subsystem is entirely optional -- if no Rust
support is available, we continue to use the C implementation. This test
balloon has the intention to give distributions time and let them ease
into our adoption of Rust.

Having multiple implementations of the same subsystem is not sustainable
though, and the plan is to eventually be able to use Rust freely all
across our codebase. As such, there is the intent to make Rust become a
mandatory part of our build process.

Add an announcement to our breaking changes that Rust will become
mandatory in Git 3.0. A (very careful and non-binding) estimate might be
that this major release might be released in the second half of next
year, which should give distributors enough time to prepare for the
change.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 Documentation/BreakingChanges.adoc | 41 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)

diff --git a/Documentation/BreakingChanges.adoc b/Documentation/BreakingChanges.adoc
index f8d2eba061..b6ae2241f8 100644
--- a/Documentation/BreakingChanges.adoc
+++ b/Documentation/BreakingChanges.adoc
@@ -165,6 +165,47 @@ A prerequisite for this change is that the ecosystem is ready to support the
 "reftable" format. Most importantly, alternative implementations of Git like
 JGit, libgit2 and Gitoxide need to support it.
 
+* Git will require Rust as a mandatory part of the build process. While Git
+  already started to adopt Rust in Git 2.52, all parts written in Rust are
+  optional for the time being. This includes:
++
+  ** Subsystems that have an alternative implementation in Rust to test
+     interoperability between our C and Rust codebase.
+  ** Newly written features that are not mission critical for a fully functional
+     Git client.
++
+These changes are meant as test balloons to allow distributors of Git to prepare
+for Rust becoming a mandatory part of the build process. There will be multiple
+milestones for the introduction of Rust:
++
+1. Initially, with Git 2.52, support for Rust will be auto-detected by Meson and
+   disabled in our Makefile so that the project can sort out the initial
+   infrastructure.
+2. In Git 2.53, support for Rust will be enabled by default in case Git is
+   compiled with breaking changes. Breaking changes can be enabled for Meson by
+   saying `meson configure -Dbreaking_changes=true` and for Makefile-based
+   builds via `make WITH_BREAKING_CHANGES=YesPlease`. It will still be possible
+   to compile with breaking changes, but explicitly disable Rust.
+3. In Git 2.54, both build systems will default-enable support for Rust even
+   when breaking changes aren't enabled. Consequently, builds will break by
+   default if Rust is not available on the build host. The use of Rust can still
+   be explicitly disabled via build flags.
+4. In Git 3.0, the build options will be removed and support for Rust is
+   mandatory.
++
+You can explicitly ask both Meson and our Makefile-based system to enable Rust
+by saying `meson configure -Drust=enabled` and `make WITH_RUST=YesPlease`,
+respectively.
++
+The Git project will declare the last version before Git 3.0 to be a long-term
+support release. This long-term release will receive important bug fixes for at
+least four release cycles and security fixes for six release cycles. The Git
+project will hand over maintainership of the long-term release to distributors
+in case they need to extend the life of that long-term release even further. In
+that case, the backporting process will be handled by these distributors, but
+the backported patches will be reviewed on the mailing list and pulled in by the
+Git maintainer.
+
 === Removals
 
 * Support for grafting commits has long been superseded by git-replace(1).

-- 
2.51.0.417.g1ba7204a04.dirty

[PATCH RFC v3 7/8] ci: convert "pedantic" job into full build with breaking changes

[Patrick Steinhardt]

The "pedantic" CI job is building on Fedora with `DEVOPTS=pedantic`.
This build flag doesn't do anything anymore starting with 6a8cbc41ba
(developer: enable pedantic by default, 2021-09-03), where we have
flipped the default so that developers have to opt-out of pedantic
builds via the "no-pedantic" option. As such, all this job really does
is to do a normal build on Fedora, which isn't all that interesting.

Convert that job into a full build-and-test job that uses Meson with
breaking changes enabled. This plugs two gaps:

  - We now test on another distro that we didn't run tests on
    beforehand.

  - We verify that breaking changes work as expected with Meson.

Furthermore, in a subsequent commit we'll modify both jobs that use
breaking changes to also enable Rust. By converting the Fedora job to
use Meson, we ensure that we test our Rust build infrastructure for both
build systems.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 .github/workflows/main.yml |  4 ++--
 .gitlab-ci.yml             |  4 ++--
 ci/install-dependencies.sh |  6 +++++-
 ci/run-build-and-tests.sh  | 29 ++++++++---------------------
 4 files changed, 17 insertions(+), 26 deletions(-)

diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index d122e79415..393ea4d1cc 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -379,6 +379,8 @@ jobs:
         - jobname: linux-breaking-changes
           cc: gcc
           image: ubuntu:rolling
+        - jobname: fedora-breaking-changes-meson
+          image: fedora:latest
         - jobname: linux-leaks
           image: ubuntu:rolling
           cc: gcc
@@ -396,8 +398,6 @@ jobs:
         # Supported until 2025-04-02.
         - jobname: linux32
           image: i386/ubuntu:focal
-        - jobname: pedantic
-          image: fedora:latest
         # A RHEL 8 compatible distro.  Supported until 2029-05-31.
         - jobname: almalinux-8
           image: almalinux:8
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index af10ebb59a..4248506909 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -45,6 +45,8 @@ test:linux:
       - jobname: linux-breaking-changes
         image: ubuntu:20.04
         CC: gcc
+      - jobname: fedora-breaking-changes-meson
+        image: fedora:latest
       - jobname: linux-TEST-vars
         image: ubuntu:20.04
         CC: gcc
@@ -58,8 +60,6 @@ test:linux:
       - jobname: linux-asan-ubsan
         image: ubuntu:rolling
         CC: clang
-      - jobname: pedantic
-        image: fedora:latest
       - jobname: linux-musl-meson
         image: alpine:latest
       - jobname: linux32
diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh
index d061a47293..35bd05b85b 100755
--- a/ci/install-dependencies.sh
+++ b/ci/install-dependencies.sh
@@ -30,8 +30,12 @@ alpine-*)
 		bash cvs gnupg perl-cgi perl-dbd-sqlite perl-io-tty >/dev/null
 	;;
 fedora-*|almalinux-*)
+	case "$jobname" in
+	*-meson)
+		MESON_DEPS="meson ninja";;
+	esac
 	dnf -yq update >/dev/null &&
-	dnf -yq install shadow-utils sudo make gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null
+	dnf -yq install shadow-utils sudo make pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel $MESON_DEPS >/dev/null
 	;;
 ubuntu-*|i386/ubuntu-*|debian-*)
 	# Required so that apt doesn't wait for user input on certain packages.
diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index 01823fd0f1..3680446649 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -5,12 +5,11 @@
 
 . ${0%/*}/lib.sh
 
-run_tests=t
-
 case "$jobname" in
-linux-breaking-changes)
+fedora-breaking-changes-musl|linux-breaking-changes)
 	export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
 	export WITH_BREAKING_CHANGES=YesPlease
+	MESONFLAGS="$MESONFLAGS -Dbreaking_changes=true"
 	;;
 linux-TEST-vars)
 	export OPENSSL_SHA1_UNSAFE=YesPlease
@@ -36,12 +35,6 @@ linux-sha256)
 linux-reftable|linux-reftable-leaks|osx-reftable)
 	export GIT_TEST_DEFAULT_REF_FORMAT=reftable
 	;;
-pedantic)
-	# Don't run the tests; we only care about whether Git can be
-	# built.
-	export DEVOPTS=pedantic
-	run_tests=
-	;;
 esac
 
 case "$jobname" in
@@ -54,21 +47,15 @@ case "$jobname" in
 		-Dtest_output_directory="${TEST_OUTPUT_DIRECTORY:-$(pwd)/t}" \
 		$MESONFLAGS
 	group "Build" meson compile -C build --
-	if test -n "$run_tests"
-	then
-		group "Run tests" meson test -C build --print-errorlogs --test-args="$GIT_TEST_OPTS" || (
-			./t/aggregate-results.sh "${TEST_OUTPUT_DIRECTORY:-t}/test-results"
-			handle_failed_tests
-		)
-	fi
+	group "Run tests" meson test -C build --print-errorlogs --test-args="$GIT_TEST_OPTS" || (
+		./t/aggregate-results.sh "${TEST_OUTPUT_DIRECTORY:-t}/test-results"
+		handle_failed_tests
+	)
 	;;
 *)
 	group Build make
-	if test -n "$run_tests"
-	then
-		group "Run tests" make test ||
-		handle_failed_tests
-	fi
+	group "Run tests" make test ||
+	handle_failed_tests
 	;;
 esac
 

-- 
2.51.0.417.g1ba7204a04.dirty

[PATCH RFC v3 8/8] ci: enable Rust for breaking-changes jobs

[Patrick Steinhardt]

Enable Rust for our breaking-changes jobs so that we can verify that the
build infrastructure and the converted Rust subsystems work as expected.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 ci/install-dependencies.sh | 4 ++--
 ci/run-build-and-tests.sh  | 2 ++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh
index 35bd05b85b..d377ea2b94 100755
--- a/ci/install-dependencies.sh
+++ b/ci/install-dependencies.sh
@@ -35,7 +35,7 @@ fedora-*|almalinux-*)
 		MESON_DEPS="meson ninja";;
 	esac
 	dnf -yq update >/dev/null &&
-	dnf -yq install shadow-utils sudo make pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel $MESON_DEPS >/dev/null
+	dnf -yq install shadow-utils sudo make pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel $MESON_DEPS rustc >/dev/null
 	;;
 ubuntu-*|i386/ubuntu-*|debian-*)
 	# Required so that apt doesn't wait for user input on certain packages.
@@ -62,7 +62,7 @@ ubuntu-*|i386/ubuntu-*|debian-*)
 		make libssl-dev libcurl4-openssl-dev libexpat-dev wget sudo default-jre \
 		tcl tk gettext zlib1g-dev perl-modules liberror-perl libauthen-sasl-perl \
 		libemail-valid-perl libio-pty-perl libio-socket-ssl-perl libnet-smtp-ssl-perl libdbd-sqlite3-perl libcgi-pm-perl \
-		libsecret-1-dev libpcre2-dev meson ninja-build pkg-config \
+		libsecret-1-dev libpcre2-dev meson ninja-build pkg-config cargo \
 		${CC_PACKAGE:-${CC:-gcc}} $PYTHON_PACKAGE
 
 	case "$distro" in
diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index 3680446649..c718bd101a 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -9,7 +9,9 @@ case "$jobname" in
 fedora-breaking-changes-musl|linux-breaking-changes)
 	export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
 	export WITH_BREAKING_CHANGES=YesPlease
+	export WITH_RUST=YesPlease
 	MESONFLAGS="$MESONFLAGS -Dbreaking_changes=true"
+	MESONFLAGS="$MESONFLAGS -Drust=enabled"
 	;;
 linux-TEST-vars)
 	export OPENSSL_SHA1_UNSAFE=YesPlease

-- 
2.51.0.417.g1ba7204a04.dirty

Re: [PATCH RFC v3 0/8] Introduce Rust and announce that it will become mandatorty

[Kristoffer Haugsbakk]

On Mon, Sep 8, 2025, at 16:13, Patrick Steinhardt wrote:
> [PATCH RFC v3 0/8] Introduce Rust and announce that it will become mandatorty

s/mandatorty/mandatory/

> Hi,
>
> this small patch series introduces Rust into the core of Git. This patch
> series is designed as a test balloon, similar to how we introduced test
> balloons for C99 features in the past. The goal is threefold:
>[snip]

-- 
Kristoffer Haugsbakk

[PATCH RFC v4 0/9] Introduce Rust and announce that it will become mandatory

[Patrick Steinhardt]

Hi,

this small patch series introduces Rust into the core of Git. This patch
series is designed as a test balloon, similar to how we introduced test
balloons for C99 features in the past. The goal is threefold:

  - Give us some time to experiment with Rust and introduce proper build
    infrastructure.

  - Give distributors time to ease into the new toolchain requirements.
    Introducing Rust is impossible for some platforms and hard for
    others.

  - Announce that Git 3.0 will make Rust a mandatory part of our build
    infrastructure.

The test balloon itself is quite uninteresting: I've chosen to convert
the "varint.c" subsystem, mostly because it is trivial and does not have
any dependencies. But it does allow us to verify that C to Rust interop
works as expected, and to play around with tooling. All tests pass with
the "varint.rs" implementation.

For now, the series only contains support for Meson. If we agree to go
down this route I'll also introduce support for Rust into our Makefiles
at a later point in time.

Furthermore missing is additional tooling:

  - At least one CI job to verify that Rust builds and works as
    expected.

  - Tooling and CI jobs to ensure that we have consistent formatting via
    `cargo format`.

And probably lots more. As said, the entire goal is for us to have an
easy playground that we can experiment on and develop the infrastructure
incrementally without yet having to commit to anything.

I'm mostly splitting out the topic of introducing Rust from the larger
series that introduce it into xdiff so that we can focus more on the
actual process of introducing Rust into Git and less on the potential
features that we want to build on top of it.

Changes in v2:
  - Introduce support for building the Rust library via our Makefile.
  - Introduce a '-DWITH_RUST' define. This define is used to print
    whether or not Git is built with Rust via `git version
    --build-options`.
  - Adjust Meson to not depend on v1.9.0 and newer anymore.
  - Introduce a roadmap into our BreakingChanges document to explain how
    we'll iterate towards mandatory Rust support.
  - Rework the Fedora job to do a full compile-and-test run with Meson
    and breaking changes enabled.
  - Adapt our breaking-changes jobs to enable Rust support.
  - Link to v1: https://lore.kernel.org/r/20250904-b4-pks-rust-breaking-change-v1-0-3af1d25e0be9@pks.im

Changes in v3:
  - Reorder all uses of `WITH_RUST` after the include of "config.mak".
  - Add a test to verify overflow behaviour in Rust and explicitly use
    `add_wrapping()`.
  - Use explicit dependencies for the Rust library in our Makefile.
  - Fix Alma Linux CI job.
  - Stop tying maintenance of our LTS release to the availability of
    gcc-rs.
  - Add a fallback to Meson to use cargo directly.
  - I've fixed the Rust edition to 2018 for now. This is intentionally
    conservative so that we might be able to use Rust 1.49. For now, we
    don't have any reason to use a newer edition, either. So let's take
    the oldest version we can live with for now and then bump it as
    required.
  - Link to v2: https://lore.kernel.org/r/20250905-b4-pks-rust-breaking-change-v2-0-6939cbf4a0b8@pks.im

Changes in v4:
  - Convert "varint.c" to use explicit integer width so that we don't
    need to use C types in Rust.
  - Adapt Meson to unconditionally use Cargo.
  - Don't use the unstable `--out-dir` option in Cargo. Instead, we
    resort to a wrapper script in Meson.
  - Shorten the timeline a bit to drop the extra step that ties Rust
    support to `-Dbreaking_changes=true`. This accelerates the timeline
    until distros are made forcibly aware of the upcoming changes in
    Rust.
  - Link to v3: https://lore.kernel.org/r/20250908-b4-pks-rust-breaking-change-v3-0-1cd7189fed3b@pks.im

Thanks!

Patrick

---
Patrick Steinhardt (9):
      meson: add infrastructure to build internal Rust library
      Makefile: reorder sources after includes
      Makefile: introduce infrastructure to build internal Rust library
      help: report on whether or not Rust is enabled
      varint: use explicit width for integers
      varint: reimplement as test balloon for Rust
      BreakingChanges: announce Rust becoming mandatory
      ci: convert "pedantic" job into full build with breaking changes
      ci: enable Rust for breaking-changes jobs

 .github/workflows/main.yml         |   4 +-
 .gitignore                         |   2 +
 .gitlab-ci.yml                     |   4 +-
 Cargo.toml                         |   9 ++
 Documentation/BreakingChanges.adoc |  36 +++++++
 Makefile                           | 214 ++++++++++++++++++++++---------------
 ci/install-dependencies.sh         |   8 +-
 ci/run-build-and-tests.sh          |  31 ++----
 dir.c                              |  18 ++--
 help.c                             |   6 ++
 meson.build                        |  15 ++-
 meson_options.txt                  |   2 +
 read-cache.c                       |   6 +-
 shared.mak                         |   1 +
 src/cargo-meson.sh                 |  32 ++++++
 src/lib.rs                         |   1 +
 src/meson.build                    |  41 +++++++
 src/varint.rs                      |  92 ++++++++++++++++
 varint.c                           |   6 +-
 varint.h                           |   4 +-
 20 files changed, 401 insertions(+), 131 deletions(-)

Range-diff versus v3:

 1:  a25408af71 <  -:  ---------- meson: add infrastructure to build internal Rust library
 -:  ---------- >  1:  ccdb7e264d meson: add infrastructure to build internal Rust library
 2:  a9c639b0f3 =  2:  b88c80f7e9 Makefile: reorder sources after includes
 3:  ccac54a247 !  3:  873f9d82f5 Makefile: introduce infrastructure to build internal Rust library
    @@ .gitignore
     @@
      /fuzz_corpora
     +/target/
    ++/Cargo.lock
      /GIT-BUILD-DIR
      /GIT-BUILD-OPTIONS
      /GIT-CFLAGS
 4:  b357ff9463 =  4:  4e70509175 help: report on whether or not Rust is enabled
 -:  ---------- >  5:  bb4cf7cc82 varint: use explicit width for integers
 5:  03a5e2ff68 !  6:  ef7b522b32 rust: implement a test balloon via the "varint" subsystem
    @@ Metadata
     Author: Patrick Steinhardt <ps@pks.im>
     
      ## Commit message ##
    -    rust: implement a test balloon via the "varint" subsystem
    +    varint: reimplement as test balloon for Rust
     
         Implement a trivial test balloon for our Rust build infrastructure by
         reimplementing the "varint.c" subsystem in Rust. This subsystem is
    @@ meson.build: libgit_sources = [
        'version.c',
        'versioncmp.c',
        'walker.c',
    -@@ meson.build: rust_option = get_option('rust').disable_auto_if(not rust_available)
    +@@ meson.build: rust_option = get_option('rust').disable_auto_if(not cargo.found())
      if rust_option.allowed()
        subdir('src')
        libgit_c_args += '-DWITH_RUST'
    @@ src/meson.build
     +  'varint.rs',
      ]
      
    - if meson.version().version_compare('>=1.5.0')
    + # Unfortunately we must use a wrapper command to move the output file into the
     
      ## src/varint.rs (new) ##
     @@
    -+use std::os::raw::c_int;
    -+use std::os::raw::c_uchar;
    -+
     +#[no_mangle]
    -+pub unsafe extern "C" fn decode_varint(bufp: *mut *const c_uchar) -> usize {
    ++pub unsafe extern "C" fn decode_varint(bufp: *mut *const u8) -> usize {
     +    let mut buf = *bufp;
     +    let mut c = *buf;
     +    let mut val = usize::from(c & 127);
    @@ src/varint.rs (new)
     +}
     +
     +#[no_mangle]
    -+pub unsafe extern "C" fn encode_varint(value: usize, buf: *mut c_uchar) -> c_int {
    ++pub unsafe extern "C" fn encode_varint(value: usize, buf: *mut u8) -> u8 {
     +    let mut varint: [u8; 16] = [0; 16];
     +    let mut pos = varint.len() - 1;
     +
    @@ src/varint.rs (new)
     +        std::ptr::copy_nonoverlapping(varint.as_ptr().add(pos), buf, varint.len() - pos);
     +    }
     +
    -+    (varint.len() - pos) as c_int
    ++    (varint.len() - pos) as u8
     +}
     +
     +#[cfg(test)]
 6:  c88c614031 !  7:  55ce2bd5b2 BreakingChanges: announce Rust becoming mandatory
    @@ Documentation/BreakingChanges.adoc: A prerequisite for this change is that the e
     +1. Initially, with Git 2.52, support for Rust will be auto-detected by Meson and
     +   disabled in our Makefile so that the project can sort out the initial
     +   infrastructure.
    -+2. In Git 2.53, support for Rust will be enabled by default in case Git is
    -+   compiled with breaking changes. Breaking changes can be enabled for Meson by
    -+   saying `meson configure -Dbreaking_changes=true` and for Makefile-based
    -+   builds via `make WITH_BREAKING_CHANGES=YesPlease`. It will still be possible
    -+   to compile with breaking changes, but explicitly disable Rust.
    -+3. In Git 2.54, both build systems will default-enable support for Rust even
    -+   when breaking changes aren't enabled. Consequently, builds will break by
    -+   default if Rust is not available on the build host. The use of Rust can still
    -+   be explicitly disabled via build flags.
    -+4. In Git 3.0, the build options will be removed and support for Rust is
    ++2. In Git 2.53, both build systems will default-enable support for Rust.
    ++   Consequently, builds will break by default if Rust is not available on the
    ++   build host. The use of Rust can still be explicitly disabled via build
    ++   flags.
    ++3. In Git 3.0, the build options will be removed and support for Rust is
     +   mandatory.
     ++
     +You can explicitly ask both Meson and our Makefile-based system to enable Rust
 7:  d4ef0c752e =  8:  16c5158046 ci: convert "pedantic" job into full build with breaking changes
 8:  d6df25d0c1 !  9:  1831fce645 ci: enable Rust for breaking-changes jobs
    @@ ci/install-dependencies.sh: fedora-*|almalinux-*)
      	esac
      	dnf -yq update >/dev/null &&
     -	dnf -yq install shadow-utils sudo make pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel $MESON_DEPS >/dev/null
    -+	dnf -yq install shadow-utils sudo make pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel $MESON_DEPS rustc >/dev/null
    ++	dnf -yq install shadow-utils sudo make pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel $MESON_DEPS cargo >/dev/null
      	;;
      ubuntu-*|i386/ubuntu-*|debian-*)
      	# Required so that apt doesn't wait for user input on certain packages.

---
base-commit: 2462961280690837670d997bde64bd4ebf8ae66d
change-id: 20250904-b4-pks-rust-breaking-change-7167d9d3e37d

[PATCH RFC v4 1/9] meson: add infrastructure to build internal Rust library

[Patrick Steinhardt]

Add the infrastructure into Meson to build an internal Rust library.
Building the Rust parts of Git are for now entirely optional, as they
are mostly intended as a test balloon for both Git developers, but also
for distributors of Git. So for now, they may contain:

  - New features that are not mission critical to Git and that users can
    easily live without.

  - Alternative implementations of small subsystems.

If these test balloons are successful, we will eventually make Rust a
mandatory dependency for our build process in Git 3.0.

The availability of a Rust toolchain will be auto-detected by Meson at
setup time. This behaviour can be tweaked via the `-Drust=` feature
toggle.

Next to the linkable Rust library, also wire up tests that can be
executed via `meson test`. This allows us to use the native unit testing
capabilities of Rust.

Note that the Rust edition is currently set to 2018. This edition is
supported by Rust 1.49, which is the target for the upcoming gcc-rs
backend. For now we don't use any features of Rust that would require a
newer version, so settling on this old version makes sense so that
gcc-rs may become an alternative backend for compiling Git. If we _do_
want to introduce features that were added in more recent editions of
Rust though we should reevaluate that choice.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 Cargo.toml         |  9 +++++++++
 meson.build        | 10 +++++++++-
 meson_options.txt  |  2 ++
 src/cargo-meson.sh | 32 ++++++++++++++++++++++++++++++++
 src/lib.rs         |  0
 src/meson.build    | 40 ++++++++++++++++++++++++++++++++++++++++
 6 files changed, 92 insertions(+), 1 deletion(-)

diff --git a/Cargo.toml b/Cargo.toml
new file mode 100644
index 00000000000..b9a41dbc792
--- /dev/null
+++ b/Cargo.toml
@@ -0,0 +1,9 @@
+[package]
+name = "git"
+version = "0.1.0"
+edition = "2018"
+
+[lib]
+crate-type = ["staticlib"]
+
+[dependencies]
diff --git a/meson.build b/meson.build
index e8ec0eca165..234a9e9d6fd 100644
--- a/meson.build
+++ b/meson.build
@@ -220,7 +220,7 @@ project('git', 'c',
   # learned to define __STDC_VERSION__ with C11 and later. We thus require
   # GNU C99 and fall back to C11. Meson only learned to handle the fallback
   # with version 1.3.0, so on older versions we use GNU C99 unconditionally.
-  default_options: meson.version().version_compare('>=1.3.0') ? ['c_std=gnu99,c11'] : ['c_std=gnu99'],
+  default_options: meson.version().version_compare('>=1.3.0') ? ['rust_std=2018', 'c_std=gnu99,c11'] : ['rust_std=2018', 'c_std=gnu99'],
 )
 
 fs = import('fs')
@@ -1702,6 +1702,13 @@ version_def_h = custom_target(
 )
 libgit_sources += version_def_h
 
+cargo = find_program('cargo', dirs: program_path, native: true, required: get_option('rust'))
+rust_option = get_option('rust').disable_auto_if(not cargo.found())
+if rust_option.allowed()
+  subdir('src')
+  libgit_c_args += '-DWITH_RUST'
+endif
+
 libgit = declare_dependency(
   link_with: static_library('git',
     sources: libgit_sources,
@@ -2239,6 +2246,7 @@ summary({
   'pcre2': pcre2,
   'perl': perl_features_enabled,
   'python': target_python.found(),
+  'rust': rust_option.allowed(),
 }, section: 'Auto-detected features', bool_yn: true)
 
 summary({
diff --git a/meson_options.txt b/meson_options.txt
index 1668f260a18..143dee9237c 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -71,6 +71,8 @@ option('zlib_backend', type: 'combo', choices: ['auto', 'zlib', 'zlib-ng'], valu
 # Build tweaks.
 option('breaking_changes', type: 'boolean', value: false,
   description: 'Enable upcoming breaking changes.')
+option('rust', type: 'feature', value: 'auto',
+  description: 'Enable building with Rust.')
 option('macos_use_homebrew_gettext', type: 'boolean', value: true,
   description: 'Use gettext from Homebrew instead of the slightly-broken system-provided one.')
 
diff --git a/src/cargo-meson.sh b/src/cargo-meson.sh
new file mode 100755
index 00000000000..f29745beb36
--- /dev/null
+++ b/src/cargo-meson.sh
@@ -0,0 +1,32 @@
+#!/bin/sh
+
+if test "$#" -lt 2
+then
+	exit 1
+fi
+
+SOURCE_DIR="$1"
+BUILD_DIR="$2"
+BUILD_TYPE=debug
+
+shift 2
+
+for arg
+do
+	case "$arg" in
+	--release)
+		BUILD_TYPE=release;;
+	esac
+done
+
+cargo build --lib --quiet --manifest-path="$SOURCE_DIR/Cargo.toml" --target-dir="$BUILD_DIR" "$@"
+RET=$?
+if test $RET -ne 0
+then
+	exit $RET
+fi
+
+if ! cmp "$BUILD_DIR/$BUILD_TYPE/libgit.a" "$BUILD_DIR/libgit.a" >/dev/null 2>&1
+then
+	cp "$BUILD_DIR/$BUILD_TYPE/libgit.a" "$BUILD_DIR/libgit.a"
+fi
diff --git a/src/lib.rs b/src/lib.rs
new file mode 100644
index 00000000000..e69de29bb2d
diff --git a/src/meson.build b/src/meson.build
new file mode 100644
index 00000000000..734de0b4fa9
--- /dev/null
+++ b/src/meson.build
@@ -0,0 +1,40 @@
+libgit_rs_sources = [
+  'lib.rs',
+]
+
+# Unfortunately we must use a wrapper command to move the output file into the
+# current build directory. This can fixed once `cargo build --artifact-dir`
+# stabilizes. See https://github.com/rust-lang/cargo/issues/6790 for that
+# effort.
+cargo_command = [
+  shell,
+  meson.current_source_dir() / 'cargo-meson.sh',
+  meson.project_source_root(),
+  meson.current_build_dir(),
+]
+if get_option('buildtype') == 'release'
+  cargo_command += '--release'
+endif
+
+libgit_rs = custom_target('git_rs',
+  input: libgit_rs_sources + [
+    meson.project_source_root() / 'Cargo.toml',
+  ],
+  output: 'libgit.a',
+  command: cargo_command,
+)
+libgit_dependencies += declare_dependency(link_with: libgit_rs)
+
+if get_option('tests')
+  test('rust', cargo,
+    args: [
+      'test',
+      '--manifest-path',
+      meson.project_source_root() / 'Cargo.toml',
+      '--target-dir',
+      meson.current_build_dir() / 'target',
+    ],
+    timeout: 0,
+    protocol: 'rust',
+  )
+endif

-- 
2.51.0.450.g87641ccf93.dirty

Re: [PATCH RFC v4 1/9] meson: add infrastructure to build internal Rust library

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1274 bytes --]

On 2025-09-10 at 15:35:47, Patrick Steinhardt wrote:
> diff --git a/src/cargo-meson.sh b/src/cargo-meson.sh
> new file mode 100755
> index 00000000000..f29745beb36
> --- /dev/null
> +++ b/src/cargo-meson.sh
> @@ -0,0 +1,32 @@
> +#!/bin/sh
> +
> +if test "$#" -lt 2
> +then
> +	exit 1
> +fi
> +
> +SOURCE_DIR="$1"
> +BUILD_DIR="$2"
> +BUILD_TYPE=debug
> +
> +shift 2
> +
> +for arg
> +do
> +	case "$arg" in
> +	--release)
> +		BUILD_TYPE=release;;
> +	esac
> +done
> +
> +cargo build --lib --quiet --manifest-path="$SOURCE_DIR/Cargo.toml" --target-dir="$BUILD_DIR" "$@"
> +RET=$?
> +if test $RET -ne 0
> +then
> +	exit $RET
> +fi
> +
> +if ! cmp "$BUILD_DIR/$BUILD_TYPE/libgit.a" "$BUILD_DIR/libgit.a" >/dev/null 2>&1
> +then
> +	cp "$BUILD_DIR/$BUILD_TYPE/libgit.a" "$BUILD_DIR/libgit.a"
> +fi

Okay, this seems like a reasonable approach.  It would be nicer to not
have to do this, but we've got to work with what we've got.

If I get mrustc working, this could also be a nice way to abstract that
functionality in a useful way.

> diff --git a/src/lib.rs b/src/lib.rs
> new file mode 100644
> index 00000000000..e69de29bb2d

An empty file seems like a good start.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

[PATCH RFC v4 2/9] Makefile: reorder sources after includes

[Patrick Steinhardt]

In an upcoming change we'll make some of the sources compile
conditionally based on whether or not `WITH_RUST` is defined. To let
developers specify that flag in their "config.mak" we'll thus have to
reorder our sources so that they come after the include of that file.

Do so.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 Makefile | 176 +++++++++++++++++++++++++++++++--------------------------------
 1 file changed, 88 insertions(+), 88 deletions(-)

diff --git a/Makefile b/Makefile
index 555b7f4dc3..7e52625d75 100644
--- a/Makefile
+++ b/Makefile
@@ -919,6 +919,94 @@ LIB_FILE = libgit.a
 XDIFF_LIB = xdiff/lib.a
 REFTABLE_LIB = reftable/libreftable.a
 
+# xdiff and reftable libs may in turn depend on what is in libgit.a
+GITLIBS = common-main.o $(LIB_FILE) $(XDIFF_LIB) $(REFTABLE_LIB) $(LIB_FILE)
+EXTLIBS =
+
+GIT_USER_AGENT = git/$(GIT_VERSION)
+
+ifeq ($(wildcard sha1collisiondetection/lib/sha1.h),sha1collisiondetection/lib/sha1.h)
+DC_SHA1_SUBMODULE = auto
+endif
+
+# Set CFLAGS, LDFLAGS and other *FLAGS variables. These might be
+# tweaked by config.* below as well as the command-line, both of
+# which'll override these defaults.
+# Older versions of GCC may require adding "-std=gnu99" at the end.
+CFLAGS = -g -O2 -Wall
+LDFLAGS =
+CC_LD_DYNPATH = -Wl,-rpath,
+BASIC_CFLAGS = -I.
+BASIC_LDFLAGS =
+
+# library flags
+ARFLAGS = rcs
+PTHREAD_CFLAGS =
+
+# For the 'sparse' target
+SPARSE_FLAGS ?= -std=gnu99 -D__STDC_NO_VLA__
+SP_EXTRA_FLAGS =
+
+# For informing GIT-BUILD-OPTIONS of the SANITIZE=leak,address targets
+SANITIZE_LEAK =
+SANITIZE_ADDRESS =
+
+# For the 'coccicheck' target
+SPATCH_INCLUDE_FLAGS = --all-includes
+SPATCH_FLAGS =
+SPATCH_TEST_FLAGS =
+
+# If *.o files are present, have "coccicheck" depend on them, with
+# COMPUTE_HEADER_DEPENDENCIES this will speed up the common-case of
+# only needing to re-generate coccicheck results for the users of a
+# given API if it's changed, and not all files in the project. If
+# COMPUTE_HEADER_DEPENDENCIES=no this will be unset too.
+SPATCH_USE_O_DEPENDENCIES = YesPlease
+
+# Set SPATCH_CONCAT_COCCI to concatenate the contrib/cocci/*.cocci
+# files into a single contrib/cocci/ALL.cocci before running
+# "coccicheck".
+#
+# Pros:
+#
+# - Speeds up a one-shot run of "make coccicheck", as we won't have to
+#   parse *.[ch] files N times for the N *.cocci rules
+#
+# Cons:
+#
+# - Will make incremental development of *.cocci slower, as
+#   e.g. changing strbuf.cocci will re-run all *.cocci.
+#
+# - Makes error and performance analysis harder, as rules will be
+#   applied from a monolithic ALL.cocci, rather than
+#   e.g. strbuf.cocci. To work around this either undefine this, or
+#   generate a specific patch, e.g. this will always use strbuf.cocci,
+#   not ALL.cocci:
+#
+#	make contrib/coccinelle/strbuf.cocci.patch
+SPATCH_CONCAT_COCCI = YesPlease
+
+# Rebuild 'coccicheck' if $(SPATCH), its flags etc. change
+TRACK_SPATCH_DEFINES =
+TRACK_SPATCH_DEFINES += $(SPATCH)
+TRACK_SPATCH_DEFINES += $(SPATCH_INCLUDE_FLAGS)
+TRACK_SPATCH_DEFINES += $(SPATCH_FLAGS)
+TRACK_SPATCH_DEFINES += $(SPATCH_TEST_FLAGS)
+GIT-SPATCH-DEFINES: FORCE
+	@FLAGS='$(TRACK_SPATCH_DEFINES)'; \
+	    if test x"$$FLAGS" != x"`cat GIT-SPATCH-DEFINES 2>/dev/null`" ; then \
+		echo >&2 "    * new spatch flags"; \
+		echo "$$FLAGS" >GIT-SPATCH-DEFINES; \
+            fi
+
+include config.mak.uname
+-include config.mak.autogen
+-include config.mak
+
+ifdef DEVELOPER
+include config.mak.dev
+endif
+
 GENERATED_H += command-list.h
 GENERATED_H += config-list.h
 GENERATED_H += hook-list.h
@@ -1387,94 +1475,6 @@ CLAR_TEST_OBJS += $(UNIT_TEST_DIR)/unit-test.o
 
 UNIT_TEST_OBJS += $(UNIT_TEST_DIR)/test-lib.o
 
-# xdiff and reftable libs may in turn depend on what is in libgit.a
-GITLIBS = common-main.o $(LIB_FILE) $(XDIFF_LIB) $(REFTABLE_LIB) $(LIB_FILE)
-EXTLIBS =
-
-GIT_USER_AGENT = git/$(GIT_VERSION)
-
-ifeq ($(wildcard sha1collisiondetection/lib/sha1.h),sha1collisiondetection/lib/sha1.h)
-DC_SHA1_SUBMODULE = auto
-endif
-
-# Set CFLAGS, LDFLAGS and other *FLAGS variables. These might be
-# tweaked by config.* below as well as the command-line, both of
-# which'll override these defaults.
-# Older versions of GCC may require adding "-std=gnu99" at the end.
-CFLAGS = -g -O2 -Wall
-LDFLAGS =
-CC_LD_DYNPATH = -Wl,-rpath,
-BASIC_CFLAGS = -I.
-BASIC_LDFLAGS =
-
-# library flags
-ARFLAGS = rcs
-PTHREAD_CFLAGS =
-
-# For the 'sparse' target
-SPARSE_FLAGS ?= -std=gnu99 -D__STDC_NO_VLA__
-SP_EXTRA_FLAGS =
-
-# For informing GIT-BUILD-OPTIONS of the SANITIZE=leak,address targets
-SANITIZE_LEAK =
-SANITIZE_ADDRESS =
-
-# For the 'coccicheck' target
-SPATCH_INCLUDE_FLAGS = --all-includes
-SPATCH_FLAGS =
-SPATCH_TEST_FLAGS =
-
-# If *.o files are present, have "coccicheck" depend on them, with
-# COMPUTE_HEADER_DEPENDENCIES this will speed up the common-case of
-# only needing to re-generate coccicheck results for the users of a
-# given API if it's changed, and not all files in the project. If
-# COMPUTE_HEADER_DEPENDENCIES=no this will be unset too.
-SPATCH_USE_O_DEPENDENCIES = YesPlease
-
-# Set SPATCH_CONCAT_COCCI to concatenate the contrib/cocci/*.cocci
-# files into a single contrib/cocci/ALL.cocci before running
-# "coccicheck".
-#
-# Pros:
-#
-# - Speeds up a one-shot run of "make coccicheck", as we won't have to
-#   parse *.[ch] files N times for the N *.cocci rules
-#
-# Cons:
-#
-# - Will make incremental development of *.cocci slower, as
-#   e.g. changing strbuf.cocci will re-run all *.cocci.
-#
-# - Makes error and performance analysis harder, as rules will be
-#   applied from a monolithic ALL.cocci, rather than
-#   e.g. strbuf.cocci. To work around this either undefine this, or
-#   generate a specific patch, e.g. this will always use strbuf.cocci,
-#   not ALL.cocci:
-#
-#	make contrib/coccinelle/strbuf.cocci.patch
-SPATCH_CONCAT_COCCI = YesPlease
-
-# Rebuild 'coccicheck' if $(SPATCH), its flags etc. change
-TRACK_SPATCH_DEFINES =
-TRACK_SPATCH_DEFINES += $(SPATCH)
-TRACK_SPATCH_DEFINES += $(SPATCH_INCLUDE_FLAGS)
-TRACK_SPATCH_DEFINES += $(SPATCH_FLAGS)
-TRACK_SPATCH_DEFINES += $(SPATCH_TEST_FLAGS)
-GIT-SPATCH-DEFINES: FORCE
-	@FLAGS='$(TRACK_SPATCH_DEFINES)'; \
-	    if test x"$$FLAGS" != x"`cat GIT-SPATCH-DEFINES 2>/dev/null`" ; then \
-		echo >&2 "    * new spatch flags"; \
-		echo "$$FLAGS" >GIT-SPATCH-DEFINES; \
-            fi
-
-include config.mak.uname
--include config.mak.autogen
--include config.mak
-
-ifdef DEVELOPER
-include config.mak.dev
-endif
-
 GIT-VERSION-FILE: FORCE
 	@OLD=$$(cat $@ 2>/dev/null || :) && \
 	$(call version_gen,"$(shell pwd)",GIT-VERSION-FILE.in,$@) && \

-- 
2.51.0.450.g87641ccf93.dirty

[PATCH RFC v4 3/9] Makefile: introduce infrastructure to build internal Rust library

[Patrick Steinhardt]

Introduce infrastructure to build the internal Rust library. This
mirrors the infrastructure we have added to Meson in the preceding
commit. Developers can enable the infrastructure by passing the new
`WITH_RUST` build toggle.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 .gitignore |  2 ++
 Makefile   | 37 +++++++++++++++++++++++++++++++++++++
 shared.mak |  1 +
 3 files changed, 40 insertions(+)

diff --git a/.gitignore b/.gitignore
index 1803023427..0833453cf6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,4 +1,6 @@
 /fuzz_corpora
+/target/
+/Cargo.lock
 /GIT-BUILD-DIR
 /GIT-BUILD-OPTIONS
 /GIT-CFLAGS
diff --git a/Makefile b/Makefile
index 7e52625d75..94950a0ffe 100644
--- a/Makefile
+++ b/Makefile
@@ -483,6 +483,14 @@ include shared.mak
 # Define LIBPCREDIR=/foo/bar if your PCRE header and library files are
 # in /foo/bar/include and /foo/bar/lib directories.
 #
+# == Optional Rust support ==
+#
+# Define WITH_RUST if you want to include features and subsystems written in
+# Rust into Git. For now, Rust is still an optional feature of the build
+# process. With Git 3.0 though, Rust will always be enabled.
+#
+# Building Rust code requires Cargo.
+#
 # == SHA-1 and SHA-256 defines ==
 #
 # === SHA-1 backend ===
@@ -683,6 +691,7 @@ OBJECTS =
 OTHER_PROGRAMS =
 PROGRAM_OBJS =
 PROGRAMS =
+RUST_SOURCES =
 EXCLUDED_PROGRAMS =
 SCRIPT_PERL =
 SCRIPT_PYTHON =
@@ -918,6 +927,11 @@ TEST_SHELL_PATH = $(SHELL_PATH)
 LIB_FILE = libgit.a
 XDIFF_LIB = xdiff/lib.a
 REFTABLE_LIB = reftable/libreftable.a
+ifdef DEBUG
+RUST_LIB = target/debug/libgit.a
+else
+RUST_LIB = target/release/libgit.a
+endif
 
 # xdiff and reftable libs may in turn depend on what is in libgit.a
 GITLIBS = common-main.o $(LIB_FILE) $(XDIFF_LIB) $(REFTABLE_LIB) $(LIB_FILE)
@@ -943,6 +957,15 @@ BASIC_LDFLAGS =
 ARFLAGS = rcs
 PTHREAD_CFLAGS =
 
+# Rust flags
+CARGO_ARGS =
+ifndef V
+CARGO_ARGS += --quiet
+endif
+ifndef DEBUG
+CARGO_ARGS += --release
+endif
+
 # For the 'sparse' target
 SPARSE_FLAGS ?= -std=gnu99 -D__STDC_NO_VLA__
 SP_EXTRA_FLAGS =
@@ -1475,6 +1498,8 @@ CLAR_TEST_OBJS += $(UNIT_TEST_DIR)/unit-test.o
 
 UNIT_TEST_OBJS += $(UNIT_TEST_DIR)/test-lib.o
 
+RUST_SOURCES += src/lib.rs
+
 GIT-VERSION-FILE: FORCE
 	@OLD=$$(cat $@ 2>/dev/null || :) && \
 	$(call version_gen,"$(shell pwd)",GIT-VERSION-FILE.in,$@) && \
@@ -1504,6 +1529,11 @@ endif
 ALL_CFLAGS = $(DEVELOPER_CFLAGS) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_APPEND)
 ALL_LDFLAGS = $(LDFLAGS) $(LDFLAGS_APPEND)
 
+ifdef WITH_RUST
+BASIC_CFLAGS += -DWITH_RUST
+GITLIBS += $(RUST_LIB)
+endif
+
 ifdef SANITIZE
 SANITIZERS := $(foreach flag,$(subst $(comma),$(space),$(SANITIZE)),$(flag))
 BASIC_CFLAGS += -fsanitize=$(SANITIZE) -fno-sanitize-recover=$(SANITIZE)
@@ -2918,6 +2948,12 @@ scalar$X: scalar.o GIT-LDFLAGS $(GITLIBS)
 $(LIB_FILE): $(LIB_OBJS)
 	$(QUIET_AR)$(RM) $@ && $(AR) $(ARFLAGS) $@ $^
 
+$(RUST_LIB): Cargo.toml $(RUST_SOURCES)
+	$(QUIET_CARGO)cargo build $(CARGO_ARGS)
+
+.PHONY: rust
+rust: $(RUST_LIB)
+
 $(XDIFF_LIB): $(XDIFF_OBJS)
 	$(QUIET_AR)$(RM) $@ && $(AR) $(ARFLAGS) $@ $^
 
@@ -3768,6 +3804,7 @@ clean: profile-clean coverage-clean cocciclean
 	$(RM) $(FUZZ_PROGRAMS)
 	$(RM) $(SP_OBJ)
 	$(RM) $(HCC)
+	$(RM) -r target/
 	$(RM) version-def.h
 	$(RM) -r $(dep_dirs) $(compdb_dir) compile_commands.json
 	$(RM) $(test_bindir_programs)
diff --git a/shared.mak b/shared.mak
index 5c7bc94785..0e7492076e 100644
--- a/shared.mak
+++ b/shared.mak
@@ -56,6 +56,7 @@ ifndef V
 	QUIET_MKDIR_P_PARENT  = @echo '   ' MKDIR -p $(@D);
 
 ## Used in "Makefile"
+	QUIET_CARGO    = @echo '   ' CARGO $@;
 	QUIET_CC       = @echo '   ' CC $@;
 	QUIET_AR       = @echo '   ' AR $@;
 	QUIET_LINK     = @echo '   ' LINK $@;

-- 
2.51.0.450.g87641ccf93.dirty

[PATCH RFC v4 4/9] help: report on whether or not Rust is enabled

[Patrick Steinhardt]

We're about to introduce support for Rust into the core of Git, where
some (trivial) subsystems are converted to Rust. These subsystems will
also retain a C implementation though as Rust is not yet mandatory.
Consequently, it now becomes possible for a Git version to have bugs
that are specific to whether or not it is built with Rust support
overall.

Expose information about whether or not Git was built with Rust via our
build info. This means that both `git version --build-options`, but also
`git bugreport` will now expose that bit of information. Hopefully, this
should make it easier for us to discover any Rust-specific issues.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 help.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/help.c b/help.c
index bb20498cfd..5854dd4a7e 100644
--- a/help.c
+++ b/help.c
@@ -791,6 +791,12 @@ void get_version_info(struct strbuf *buf, int show_build_options)
 		strbuf_addf(buf, "shell-path: %s\n", SHELL_PATH);
 		/* NEEDSWORK: also save and output GIT-BUILD_OPTIONS? */
 
+#if defined WITH_RUST
+		strbuf_addstr(buf, "rust: enabled\n");
+#else
+		strbuf_addstr(buf, "rust: disabled\n");
+#endif
+
 		if (fsmonitor_ipc__is_supported())
 			strbuf_addstr(buf, "feature: fsmonitor--daemon\n");
 #if defined LIBCURL_VERSION

-- 
2.51.0.450.g87641ccf93.dirty

[PATCH RFC v4 5/9] varint: use explicit width for integers

[Patrick Steinhardt]

The varint subsystem currently uses implcit widths for integers. On the
one hand we use `uintmax_t` for the actual value. On the other hand, we
use `int` for the length of the encoded varint.

Both of these have known maximum vaules, as we only support at most 16
bytes when encoding varints. Thus, we know that we won't ever exceed
`uint64_t` for the actual value and `uint8_t` for the prefix length.

Refactor the code to use explicit widths. Besides making the logic
platform-independent, it also makes our life a bit easier in the next
commit, where we reimplement "varint.c" in Rust.

Suggested-by: Ezekiel Newren <ezekielnewren@gmail.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 dir.c        | 18 ++++++++++--------
 read-cache.c |  6 ++++--
 varint.c     |  6 +++---
 varint.h     |  4 ++--
 4 files changed, 19 insertions(+), 15 deletions(-)

diff --git a/dir.c b/dir.c
index 71108ac79b7..0a67a99cb3d 100644
--- a/dir.c
+++ b/dir.c
@@ -3579,7 +3579,8 @@ static void write_one_dir(struct untracked_cache_dir *untracked,
 	struct stat_data stat_data;
 	struct strbuf *out = &wd->out;
 	unsigned char intbuf[16];
-	unsigned int intlen, value;
+	unsigned int value;
+	uint8_t intlen;
 	int i = wd->index++;
 
 	/*
@@ -3632,7 +3633,7 @@ void write_untracked_extension(struct strbuf *out, struct untracked_cache *untra
 	struct ondisk_untracked_cache *ouc;
 	struct write_data wd;
 	unsigned char varbuf[16];
-	int varint_len;
+	uint8_t varint_len;
 	const unsigned hashsz = the_hash_algo->rawsz;
 
 	CALLOC_ARRAY(ouc, 1);
@@ -3738,7 +3739,7 @@ static int read_one_dir(struct untracked_cache_dir **untracked_,
 	struct untracked_cache_dir ud, *untracked;
 	const unsigned char *data = rd->data, *end = rd->end;
 	const unsigned char *eos;
-	unsigned int value;
+	uint64_t value;
 	int i;
 
 	memset(&ud, 0, sizeof(ud));
@@ -3830,7 +3831,8 @@ struct untracked_cache *read_untracked_extension(const void *data, unsigned long
 	struct read_data rd;
 	const unsigned char *next = data, *end = (const unsigned char *)data + sz;
 	const char *ident;
-	int ident_len;
+	uint64_t ident_len;
+	uint64_t varint_len;
 	ssize_t len;
 	const char *exclude_per_dir;
 	const unsigned hashsz = the_hash_algo->rawsz;
@@ -3867,8 +3869,8 @@ struct untracked_cache *read_untracked_extension(const void *data, unsigned long
 	if (next >= end)
 		goto done2;
 
-	len = decode_varint(&next);
-	if (next > end || len == 0)
+	varint_len = decode_varint(&next);
+	if (next > end || varint_len == 0)
 		goto done2;
 
 	rd.valid      = ewah_new();
@@ -3877,9 +3879,9 @@ struct untracked_cache *read_untracked_extension(const void *data, unsigned long
 	rd.data	      = next;
 	rd.end	      = end;
 	rd.index      = 0;
-	ALLOC_ARRAY(rd.ucd, len);
+	ALLOC_ARRAY(rd.ucd, varint_len);
 
-	if (read_one_dir(&uc->root, &rd) || rd.index != len)
+	if (read_one_dir(&uc->root, &rd) || rd.index != varint_len)
 		goto done;
 
 	next = rd.data;
diff --git a/read-cache.c b/read-cache.c
index 06ad74db228..41b44148b1e 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1807,7 +1807,7 @@ static struct cache_entry *create_from_disk(struct mem_pool *ce_mem_pool,
 
 	if (expand_name_field) {
 		const unsigned char *cp = (const unsigned char *)name;
-		size_t strip_len, previous_len;
+		uint64_t strip_len, previous_len;
 
 		/* If we're at the beginning of a block, ignore the previous name */
 		strip_len = decode_varint(&cp);
@@ -2655,8 +2655,10 @@ static int ce_write_entry(struct hashfile *f, struct cache_entry *ce,
 		hashwrite(f, ce->name, len);
 		hashwrite(f, padding, align_padding_size(size, len));
 	} else {
-		int common, to_remove, prefix_size;
+		int common, to_remove;
+		uint8_t prefix_size;
 		unsigned char to_remove_vi[16];
+
 		for (common = 0;
 		     (common < previous_name->len &&
 		      ce->name[common] &&
diff --git a/varint.c b/varint.c
index 409c4977a1e..03cd54416b6 100644
--- a/varint.c
+++ b/varint.c
@@ -1,11 +1,11 @@
 #include "git-compat-util.h"
 #include "varint.h"
 
-uintmax_t decode_varint(const unsigned char **bufp)
+uint64_t decode_varint(const unsigned char **bufp)
 {
 	const unsigned char *buf = *bufp;
 	unsigned char c = *buf++;
-	uintmax_t val = c & 127;
+	uint64_t val = c & 127;
 	while (c & 128) {
 		val += 1;
 		if (!val || MSB(val, 7))
@@ -17,7 +17,7 @@ uintmax_t decode_varint(const unsigned char **bufp)
 	return val;
 }
 
-int encode_varint(uintmax_t value, unsigned char *buf)
+uint8_t encode_varint(uint64_t value, unsigned char *buf)
 {
 	unsigned char varint[16];
 	unsigned pos = sizeof(varint) - 1;
diff --git a/varint.h b/varint.h
index f78bb0ca528..eb401935bd2 100644
--- a/varint.h
+++ b/varint.h
@@ -1,7 +1,7 @@
 #ifndef VARINT_H
 #define VARINT_H
 
-int encode_varint(uintmax_t, unsigned char *);
-uintmax_t decode_varint(const unsigned char **);
+uint8_t encode_varint(uint64_t, unsigned char *);
+uint64_t decode_varint(const unsigned char **);
 
 #endif /* VARINT_H */

-- 
2.51.0.450.g87641ccf93.dirty

Re: [PATCH RFC v4 5/9] varint: use explicit width for integers

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

> The varint subsystem currently uses implcit widths for integers. On the
> one hand we use `uintmax_t` for the actual value. On the other hand, we
> use `int` for the length of the encoded varint.
>
> Both of these have known maximum vaules, as we only support at most 16
> bytes when encoding varints. Thus, we know that we won't ever exceed
> `uint64_t` for the actual value and `uint8_t` for the prefix length.
>
> Refactor the code to use explicit widths. Besides making the logic
> platform-independent, it also makes our life a bit easier in the next
> commit, where we reimplement "varint.c" in Rust.
>
> Suggested-by: Ezekiel Newren <ezekielnewren@gmail.com>
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
>  dir.c        | 18 ++++++++++--------
>  read-cache.c |  6 ++++--
>  varint.c     |  6 +++---
>  varint.h     |  4 ++--
>  4 files changed, 19 insertions(+), 15 deletions(-)
...
> -int encode_varint(uintmax_t, unsigned char *);
> -uintmax_t decode_varint(const unsigned char **);
> +uint8_t encode_varint(uint64_t, unsigned char *);
> +uint64_t decode_varint(const unsigned char **);

OK.  I do not think there is a reason why we MUST use u8, even
though in practice 255 bytes is plenty for any "integer" that varint
would want to express, so I'll let it go.

I have no objection to uint64_t side of the equation.  We would not
be using 128-bit integer to express sizes of object representation
in the packfiles anyway.

When this series meets Ezekiel's series, I would imagine that there
will be "which one between uint64_t and u64 should we use"
discussion.  I'd prefer uint64_t as that is what is used in the part
of the code that are not yet told about the other parts moving to
Rust.  Consistency throughout the codebase is good.

[PATCH RFC v4 6/9] varint: reimplement as test balloon for Rust

[Patrick Steinhardt]

Implement a trivial test balloon for our Rust build infrastructure by
reimplementing the "varint.c" subsystem in Rust. This subsystem is
chosen because it is trivial to convert and because it doesn't have any
dependencies to other components of Git.

If support for Rust is enabled, we stop compiling "varint.c" and instead
compile and use "src/varint.rs".

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 Makefile        |  3 ++
 meson.build     |  5 +++-
 src/lib.rs      |  1 +
 src/meson.build |  1 +
 src/varint.rs   | 92 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 101 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 94950a0ffe2..7640d0d76ac 100644
--- a/Makefile
+++ b/Makefile
@@ -1307,7 +1307,9 @@ LIB_OBJS += urlmatch.o
 LIB_OBJS += usage.o
 LIB_OBJS += userdiff.o
 LIB_OBJS += utf8.o
+ifndef WITH_RUST
 LIB_OBJS += varint.o
+endif
 LIB_OBJS += version.o
 LIB_OBJS += versioncmp.o
 LIB_OBJS += walker.o
@@ -1499,6 +1501,7 @@ CLAR_TEST_OBJS += $(UNIT_TEST_DIR)/unit-test.o
 UNIT_TEST_OBJS += $(UNIT_TEST_DIR)/test-lib.o
 
 RUST_SOURCES += src/lib.rs
+RUST_SOURCES += src/varint.rs
 
 GIT-VERSION-FILE: FORCE
 	@OLD=$$(cat $@ 2>/dev/null || :) && \
diff --git a/meson.build b/meson.build
index 234a9e9d6fd..37dfa286017 100644
--- a/meson.build
+++ b/meson.build
@@ -522,7 +522,6 @@ libgit_sources = [
   'usage.c',
   'userdiff.c',
   'utf8.c',
-  'varint.c',
   'version.c',
   'versioncmp.c',
   'walker.c',
@@ -1707,6 +1706,10 @@ rust_option = get_option('rust').disable_auto_if(not cargo.found())
 if rust_option.allowed()
   subdir('src')
   libgit_c_args += '-DWITH_RUST'
+else
+  libgit_sources += [
+    'varint.c',
+  ]
 endif
 
 libgit = declare_dependency(
diff --git a/src/lib.rs b/src/lib.rs
index e69de29bb2d..9da70d8b57d 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -0,0 +1 @@
+pub mod varint;
diff --git a/src/meson.build b/src/meson.build
index 734de0b4fa9..b19ef4c0b51 100644
--- a/src/meson.build
+++ b/src/meson.build
@@ -1,5 +1,6 @@
 libgit_rs_sources = [
   'lib.rs',
+  'varint.rs',
 ]
 
 # Unfortunately we must use a wrapper command to move the output file into the
diff --git a/src/varint.rs b/src/varint.rs
new file mode 100644
index 00000000000..10c83e1f439
--- /dev/null
+++ b/src/varint.rs
@@ -0,0 +1,92 @@
+#[no_mangle]
+pub unsafe extern "C" fn decode_varint(bufp: *mut *const u8) -> usize {
+    let mut buf = *bufp;
+    let mut c = *buf;
+    let mut val = usize::from(c & 127);
+
+    buf = buf.add(1);
+
+    while (c & 128) != 0 {
+        val = val.wrapping_add(1);
+        if val == 0 || val.leading_zeros() < 7 {
+            return 0; // overflow
+        }
+
+        c = *buf;
+        buf = buf.add(1);
+
+        val = (val << 7) + usize::from(c & 127);
+    }
+
+    *bufp = buf;
+    val
+}
+
+#[no_mangle]
+pub unsafe extern "C" fn encode_varint(value: usize, buf: *mut u8) -> u8 {
+    let mut varint: [u8; 16] = [0; 16];
+    let mut pos = varint.len() - 1;
+
+    varint[pos] = (value & 127) as u8;
+
+    let mut value = value >> 7;
+    while value != 0 {
+        pos -= 1;
+        value -= 1;
+        varint[pos] = 128 | (value & 127) as u8;
+        value >>= 7;
+    }
+
+    if !buf.is_null() {
+        std::ptr::copy_nonoverlapping(varint.as_ptr().add(pos), buf, varint.len() - pos);
+    }
+
+    (varint.len() - pos) as u8
+}
+
+#[cfg(test)]
+mod tests {
+    use super::*;
+
+    #[test]
+    fn test_decode_varint() {
+        unsafe {
+            assert_eq!(decode_varint(&mut [0x00].as_slice().as_ptr()), 0);
+            assert_eq!(decode_varint(&mut [0x01].as_slice().as_ptr()), 1);
+            assert_eq!(decode_varint(&mut [0x7f].as_slice().as_ptr()), 127);
+            assert_eq!(decode_varint(&mut [0x80, 0x00].as_slice().as_ptr()), 128);
+            assert_eq!(decode_varint(&mut [0x80, 0x01].as_slice().as_ptr()), 129);
+            assert_eq!(decode_varint(&mut [0x80, 0x7f].as_slice().as_ptr()), 255);
+
+            // Overflows are expected to return 0.
+            assert_eq!(decode_varint(&mut [0x88; 16].as_slice().as_ptr()), 0);
+        }
+    }
+
+    #[test]
+    fn test_encode_varint() {
+        unsafe {
+            let mut varint: [u8; 16] = [0; 16];
+
+            assert_eq!(encode_varint(0, std::ptr::null_mut()), 1);
+
+            assert_eq!(encode_varint(0, varint.as_mut_slice().as_mut_ptr()), 1);
+            assert_eq!(varint, [0; 16]);
+
+            assert_eq!(encode_varint(10, varint.as_mut_slice().as_mut_ptr()), 1);
+            assert_eq!(varint, [10, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+
+            assert_eq!(encode_varint(127, varint.as_mut_slice().as_mut_ptr()), 1);
+            assert_eq!(varint, [127, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+
+            assert_eq!(encode_varint(128, varint.as_mut_slice().as_mut_ptr()), 2);
+            assert_eq!(varint, [128, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+
+            assert_eq!(encode_varint(129, varint.as_mut_slice().as_mut_ptr()), 2);
+            assert_eq!(varint, [128, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+
+            assert_eq!(encode_varint(255, varint.as_mut_slice().as_mut_ptr()), 2);
+            assert_eq!(varint, [128, 127, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+        }
+    }
+}

-- 
2.51.0.450.g87641ccf93.dirty

[PATCH RFC v4 7/9] BreakingChanges: announce Rust becoming mandatory

[Patrick Steinhardt]

Over the last couple of years the appetite for bringin Rust into the
codebase has grown significantly across the developer base. Introducing
Rust is a major change though and has ramifications for the whole
ecosystem:

  - Some platforms have a Rust toolchain available, but have not yet
    integrated it into their build infrastructure.

  - Some platforms don't have any support for Rust at all.

  - Some platforms may have to figure out how to fit Rust into their
    bootstrapping sequence.

Due to this, and given that Git is a critical piece of infrastructure
for the whole industry, we cannot just introduce such a heavyweight
dependency without doing our due diligence.

Instead, preceding commits have introduced a test balloon into our build
infrastructure that convert one tiny subsystem to use Rust. For now,
using Rust to build that subsystem is entirely optional -- if no Rust
support is available, we continue to use the C implementation. This test
balloon has the intention to give distributions time and let them ease
into our adoption of Rust.

Having multiple implementations of the same subsystem is not sustainable
though, and the plan is to eventually be able to use Rust freely all
across our codebase. As such, there is the intent to make Rust become a
mandatory part of our build process.

Add an announcement to our breaking changes that Rust will become
mandatory in Git 3.0. A (very careful and non-binding) estimate might be
that this major release might be released in the second half of next
year, which should give distributors enough time to prepare for the
change.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 Documentation/BreakingChanges.adoc | 36 ++++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/Documentation/BreakingChanges.adoc b/Documentation/BreakingChanges.adoc
index f8d2eba061..3550e9fc27 100644
--- a/Documentation/BreakingChanges.adoc
+++ b/Documentation/BreakingChanges.adoc
@@ -165,6 +165,42 @@ A prerequisite for this change is that the ecosystem is ready to support the
 "reftable" format. Most importantly, alternative implementations of Git like
 JGit, libgit2 and Gitoxide need to support it.
 
+* Git will require Rust as a mandatory part of the build process. While Git
+  already started to adopt Rust in Git 2.52, all parts written in Rust are
+  optional for the time being. This includes:
++
+  ** Subsystems that have an alternative implementation in Rust to test
+     interoperability between our C and Rust codebase.
+  ** Newly written features that are not mission critical for a fully functional
+     Git client.
++
+These changes are meant as test balloons to allow distributors of Git to prepare
+for Rust becoming a mandatory part of the build process. There will be multiple
+milestones for the introduction of Rust:
++
+1. Initially, with Git 2.52, support for Rust will be auto-detected by Meson and
+   disabled in our Makefile so that the project can sort out the initial
+   infrastructure.
+2. In Git 2.53, both build systems will default-enable support for Rust.
+   Consequently, builds will break by default if Rust is not available on the
+   build host. The use of Rust can still be explicitly disabled via build
+   flags.
+3. In Git 3.0, the build options will be removed and support for Rust is
+   mandatory.
++
+You can explicitly ask both Meson and our Makefile-based system to enable Rust
+by saying `meson configure -Drust=enabled` and `make WITH_RUST=YesPlease`,
+respectively.
++
+The Git project will declare the last version before Git 3.0 to be a long-term
+support release. This long-term release will receive important bug fixes for at
+least four release cycles and security fixes for six release cycles. The Git
+project will hand over maintainership of the long-term release to distributors
+in case they need to extend the life of that long-term release even further. In
+that case, the backporting process will be handled by these distributors, but
+the backported patches will be reviewed on the mailing list and pulled in by the
+Git maintainer.
+
 === Removals
 
 * Support for grafting commits has long been superseded by git-replace(1).

-- 
2.51.0.450.g87641ccf93.dirty

Re: [PATCH RFC v4 7/9] BreakingChanges: announce Rust becoming mandatory

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

> +* Git will require Rust as a mandatory part of the build process. While Git
> +  already started to adopt Rust in Git 2.52, all parts written in Rust are
> +  optional for the time being. This includes:
> ++
> +  ** Subsystems that have an alternative implementation in Rust to test
> +     interoperability between our C and Rust codebase.
> +  ** Newly written features that are not mission critical for a fully functional
> +     Git client.

This is a bit funny way to phrase the intent, even though I do fully
support the intent expressed here.

When this topic becomes part of the code base, we are likely to have
varint in the first category, but if we have nothing that falls in
the second category, that would feel somewhat odd.

> +These changes are meant as test balloons to allow distributors of Git to prepare
> +for Rust becoming a mandatory part of the build process. There will be multiple

Are they still "test balloons"?  I thought that we established that
the point of these breaking changes is quite different from what we
have called "test balloons" for.  It is not like allowing them
anything (like interfering to delay or stop, which would not likely
to happen at this point if this patch gets part of the code base),
but is used as a bit more forceful way for us to tell them and make
sure they are aware of the upcoming change.

> +milestones for the introduction of Rust:
> ++
> +1. Initially, with Git 2.52, support for Rust will be auto-detected by Meson and
> +   disabled in our Makefile so that the project can sort out the initial
> +   infrastructure.
> +2. In Git 2.53, both build systems will default-enable support for Rust.
> +   Consequently, builds will break by default if Rust is not available on the
> +   build host. The use of Rust can still be explicitly disabled via build
> +   flags.
> +3. In Git 3.0, the build options will be removed and support for Rust is
> +   mandatory.

I like the vagueness of the gap between step 2 and 3 here ;-)

> +The Git project will declare the last version before Git 3.0 to be a long-term
> +support release. This long-term release will receive important bug fixes for at
> +least four release cycles and security fixes for six release cycles. The Git
> +project will hand over maintainership of the long-term release to distributors
> +in case they need to extend the life of that long-term release even further. In
> +that case, the backporting process will be handled by these distributors, but
> +the backported patches will be reviewed on the mailing list and pulled in by the
> +Git maintainer.

I am having a hard time imagining the practicality of this "hand
over but we still review" arrangement.  Some of the security fixes
are embargoed, and the reason why we are jetissoning the stale
codebase is presumably because nobody is willing to work on it other
than the "community support" folks.  I can imagine that we would
qualify them into the git-security cabal and let them use the forum
to coordinate among themselves, but then to what degree in the
"community support themselves" process is our involvement expected?
As long as we can make sure that they do not leak before the
official embargoed release, they do not need an official stamp of
approval from the project or by the Git maintainer---that is what it
means to "hand over maintainer ship", at least to me.

In other words, I like what I see in this paragraph, but I do not
think we can practically live with the part of the sentence after
the last ", but".

Thanks.

Re: [PATCH RFC v4 7/9] BreakingChanges: announce Rust becoming mandatory

[Patrick Steinhardt]

On Wed, Sep 10, 2025 at 02:20:24PM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > +* Git will require Rust as a mandatory part of the build process. While Git
> > +  already started to adopt Rust in Git 2.52, all parts written in Rust are
> > +  optional for the time being. This includes:
> > ++
> > +  ** Subsystems that have an alternative implementation in Rust to test
> > +     interoperability between our C and Rust codebase.
> > +  ** Newly written features that are not mission critical for a fully functional
> > +     Git client.
> 
> This is a bit funny way to phrase the intent, even though I do fully
> support the intent expressed here.
> 
> When this topic becomes part of the code base, we are likely to have
> varint in the first category, but if we have nothing that falls in
> the second category, that would feel somewhat odd.

The intent here is to open the door for those. So yes, right now we
don't have anything in the second category yet. But the intent here is
to explicitly say that people are free to do it even if there is no such
user in our tree yet. And with the SHA256 interop code we already have
this feature in the working anyway :)

> > +These changes are meant as test balloons to allow distributors of Git to prepare
> > +for Rust becoming a mandatory part of the build process. There will be multiple
> 
> Are they still "test balloons"?  I thought that we established that
> the point of these breaking changes is quite different from what we
> have called "test balloons" for.  It is not like allowing them
> anything (like interfering to delay or stop, which would not likely
> to happen at this point if this patch gets part of the code base),
> but is used as a bit more forceful way for us to tell them and make
> sure they are aware of the upcoming change.

I'm mostly just lacking a better term here and haven't seen a different
term proposed anywhere. I think it's close enough to a test balloon to
call it that, but if anybody has a better way to name this thing I'm
happy to adapt.

> > +The Git project will declare the last version before Git 3.0 to be a long-term
> > +support release. This long-term release will receive important bug fixes for at
> > +least four release cycles and security fixes for six release cycles. The Git
> > +project will hand over maintainership of the long-term release to distributors
> > +in case they need to extend the life of that long-term release even further. In
> > +that case, the backporting process will be handled by these distributors, but
> > +the backported patches will be reviewed on the mailing list and pulled in by the
> > +Git maintainer.
> 
> I am having a hard time imagining the practicality of this "hand
> over but we still review" arrangement.  Some of the security fixes
> are embargoed, and the reason why we are jetissoning the stale
> codebase is presumably because nobody is willing to work on it other
> than the "community support" folks.  I can imagine that we would
> qualify them into the git-security cabal and let them use the forum
> to coordinate among themselves, but then to what degree in the
> "community support themselves" process is our involvement expected?
> As long as we can make sure that they do not leak before the
> official embargoed release, they do not need an official stamp of
> approval from the project or by the Git maintainer---that is what it
> means to "hand over maintainer ship", at least to me.
> 
> In other words, I like what I see in this paragraph, but I do not
> think we can practically live with the part of the sentence after
> the last ", but".

I think the most important part here is that this community-supported
LTS release should still live in the canonical repositories. We should
avoid the situation where we hand over maintainership to such a degree
that the end result (the tagged LTS release) lives somewhere else.
Otherwise we risk chaos and a plethora of different LTS releases, which
would be harmful both for us and those that rely on the LTS releases.

So this requires us/you to pull in those changes into the LTS release
branch. And that from my point of view mandates that we also review
whatever is being proposed for the backports. The mode thus essentially
becomes that somebody else does the legwork of selecting patches that
need to be backported and massaging them so that they apply to the old
Git version. But other than that we still follow the normal processes.

And yes, that probably means that a trusted LTS maintainer should be on
git-security@ so that they are aware of upcoming security releases.

Patrick

Re: [PATCH RFC v4 7/9] BreakingChanges: announce Rust becoming mandatory

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

>> I am having a hard time imagining the practicality of this "hand
>> over but we still review" arrangement.  Some of the security fixes
>> are embargoed, and the reason why we are jetissoning the stale
>> codebase is presumably because nobody is willing to work on it other
>> than the "community support" folks.  I can imagine that we would
>> qualify them into the git-security cabal and let them use the forum
>> to coordinate among themselves, but then to what degree in the
>> "community support themselves" process is our involvement expected?
>> As long as we can make sure that they do not leak before the
>> official embargoed release, they do not need an official stamp of
>> approval from the project or by the Git maintainer---that is what it
>> means to "hand over maintainer ship", at least to me.
>> 
>> In other words, I like what I see in this paragraph, but I do not
>> think we can practically live with the part of the sentence after
>> the last ", but".
>
> I think the most important part here is that this community-supported
> LTS release should still live in the canonical repositories. We should
> avoid the situation where we hand over maintainership to such a degree
> that the end result (the tagged LTS release) lives somewhere else.

Why is it a bad thing?  The official repository can have a README.md
with a single entry "maintenance releases for Git 2.98 LTS (most
notably with no Rust requirements) are found at this separate site".

> Otherwise we risk chaos and a plethora of different LTS releases, which
> would be harmful both for us and those that rely on the LTS releases.

No risk for that as long as we have a single "go there" pointer, right?

> And yes, that probably means that a trusted LTS maintainer should be on
> git-security@ so that they are aware of upcoming security releases.

Absolutely.

And there should be a community of those who are working on helping
the backporting effort around that LTS maintainer that ensures there
is no "chaos and a plethora of different LTS releases".

We might occasionally update what is listed in "git ls-remote --tags"
from our repository by syncing with them only for convenience, but
the important point is that the community supported LTS should have
its own official site, which is different from the cutting/bleeding
edge.  Most importantly, a coordinated disclosure would say that the
update to versions of

 - Git 3.0 to Git 3.4 are found $HERE, 
 - Git for Windows 3.0, 3.2, and 3.4 are found $THERE
 - Git 2.98 are found $COMMUNITY_LTS

to make sure that people know where to find their updates.

So, no, I do not think we should unnecessarily mix community LTS and
the main project.

Re: [PATCH RFC v4 7/9] BreakingChanges: announce Rust becoming mandatory

[Patrick Steinhardt]

On Mon, Sep 22, 2025 at 09:24:26AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> >> I am having a hard time imagining the practicality of this "hand
> >> over but we still review" arrangement.  Some of the security fixes
> >> are embargoed, and the reason why we are jetissoning the stale
> >> codebase is presumably because nobody is willing to work on it other
> >> than the "community support" folks.  I can imagine that we would
> >> qualify them into the git-security cabal and let them use the forum
> >> to coordinate among themselves, but then to what degree in the
> >> "community support themselves" process is our involvement expected?
> >> As long as we can make sure that they do not leak before the
> >> official embargoed release, they do not need an official stamp of
> >> approval from the project or by the Git maintainer---that is what it
> >> means to "hand over maintainer ship", at least to me.
> >> 
> >> In other words, I like what I see in this paragraph, but I do not
> >> think we can practically live with the part of the sentence after
> >> the last ", but".
> >
> > I think the most important part here is that this community-supported
> > LTS release should still live in the canonical repositories. We should
> > avoid the situation where we hand over maintainership to such a degree
> > that the end result (the tagged LTS release) lives somewhere else.
> 
> Why is it a bad thing?  The official repository can have a README.md
> with a single entry "maintenance releases for Git 2.98 LTS (most
> notably with no Rust requirements) are found at this separate site".

There's a couple reasons:

  - The LTS maintainer may not be as familiar with the Git codebase as
    we are, so they would benefit from the usual processes on the
    mailing list.

  - The LTS maintainer may not be as trusted as other regulars on the
    mailing list are, so we (from my POV) may want to avoid having a
    basically unobserved fork elsewhere.

  - The end result would still be "git", and users will come to us to
    complain about issues in the LTS release.

  - Initial releases of the LTS release branch that are managed by us
    would sit in our repo, whereas subsequent releases would sit in the
    LTS release. This will likely cause confusion.

  - We reduce chances of a hard fork of Git.

So with these in mind I think it would be sensible to keep the LTS
release as part of the canonical repository.

> > Otherwise we risk chaos and a plethora of different LTS releases, which
> > would be harmful both for us and those that rely on the LTS releases.
> 
> No risk for that as long as we have a single "go there" pointer, right?

It somewhat reduces the risk, true. I still worry a bit about
encouraging a hard fork.

> > And yes, that probably means that a trusted LTS maintainer should be on
> > git-security@ so that they are aware of upcoming security releases.
> 
> Absolutely.
> 
> And there should be a community of those who are working on helping
> the backporting effort around that LTS maintainer that ensures there
> is no "chaos and a plethora of different LTS releases".

Fair.

> We might occasionally update what is listed in "git ls-remote --tags"
> from our repository by syncing with them only for convenience, but
> the important point is that the community supported LTS should have
> its own official site, which is different from the cutting/bleeding
> edge.  Most importantly, a coordinated disclosure would say that the
> update to versions of
> 
>  - Git 3.0 to Git 3.4 are found $HERE, 
>  - Git for Windows 3.0, 3.2, and 3.4 are found $THERE
>  - Git 2.98 are found $COMMUNITY_LTS
> 
> to make sure that people know where to find their updates.
> 
> So, no, I do not think we should unnecessarily mix community LTS and
> the main project.

How about the following tradeoff: the community LTS is developed outside
of the usual Git workflow, for example on a forge, so that the LTS
maintainers can work in their preferred flow. But eventually, once they
want to do a release they send a pull request to the Git mailing list
and then the tag lives in the canonical Git repository.

It gives the LTS maintainers flexibility, but still makes the canonical
repository the single source of truth for Git releases. Furthermore,
we'd have a way to double check the results before creating the tags.

Patrick

LTS "lieutenant", was Re: [PATCH RFC v4 7/9] BreakingChanges: announce Rust becoming mandatory

[Johannes Schindelin]

Hi Patrick,

On Tue, 23 Sep 2025, Patrick Steinhardt wrote:

> On Mon, Sep 22, 2025 at 09:24:26AM -0700, Junio C Hamano wrote:
> > Patrick Steinhardt <ps@pks.im> writes:
> > 
> > >> I am having a hard time imagining the practicality of this "hand
> > >> over but we still review" arrangement.  Some of the security fixes
> > >> are embargoed, and the reason why we are jetissoning the stale
> > >> codebase is presumably because nobody is willing to work on it other
> > >> than the "community support" folks.  I can imagine that we would
> > >> qualify them into the git-security cabal and let them use the forum
> > >> to coordinate among themselves, but then to what degree in the
> > >> "community support themselves" process is our involvement expected?
> > >> As long as we can make sure that they do not leak before the
> > >> official embargoed release, they do not need an official stamp of
> > >> approval from the project or by the Git maintainer---that is what it
> > >> means to "hand over maintainer ship", at least to me.
> > >> 
> > >> In other words, I like what I see in this paragraph, but I do not
> > >> think we can practically live with the part of the sentence after
> > >> the last ", but".
> > >
> > > I think the most important part here is that this community-supported
> > > LTS release should still live in the canonical repositories. We should
> > > avoid the situation where we hand over maintainership to such a degree
> > > that the end result (the tagged LTS release) lives somewhere else.
> > 
> > Why is it a bad thing?  The official repository can have a README.md
> > with a single entry "maintenance releases for Git 2.98 LTS (most
> > notably with no Rust requirements) are found at this separate site".
> 
> There's a couple reasons:
> 
>   - The LTS maintainer may not be as familiar with the Git codebase as
>     we are, so they would benefit from the usual processes on the
>     mailing list.

Basically: It's a matter of trust.

>   - The LTS maintainer may not be as trusted as other regulars on the
>     mailing list are, so we (from my POV) may want to avoid having a
>     basically unobserved fork elsewhere.

Basically: It's a matter of trust.

>   - The end result would still be "git", and users will come to us to
>     complain about issues in the LTS release.

Basically: Users would still only trust the main Git project.

>   - Initial releases of the LTS release branch that are managed by us
>     would sit in our repo, whereas subsequent releases would sit in the
>     LTS release. This will likely cause confusion.

And confusion sows distrust, I agree.

>   - We reduce chances of a hard fork of Git.
> 
> So with these in mind I think it would be sensible to keep the LTS
> release as part of the canonical repository.

I agree, and I have to say that I am puzzled that it was even a question.

> > So, no, I do not think we should unnecessarily mix community LTS and
> > the main project.
> 
> How about the following tradeoff: the community LTS is developed outside
> of the usual Git workflow, for example on a forge, so that the LTS
> maintainers can work in their preferred flow. But eventually, once they
> want to do a release they send a pull request to the Git mailing list
> and then the tag lives in the canonical Git repository.
> 
> It gives the LTS maintainers flexibility, but still makes the canonical
> repository the single source of truth for Git releases. Furthermore,
> we'd have a way to double check the results before creating the tags.

I have to admit that it sounds quite odd an idea to "hand off LTS support"
to a completely different entity. It flies counter to everything I have
learned in this industry. There has been exactly zero instance worth
mentioning where an LTS release maintained outside of the main project has
been accepted as anything remotely official. There is no reason to believe
that Git would be the first.

Let me propose an alternative, one that is much more likely to be accepted
by actual Git users, including professional ones: How about assigning a
trusted, prolific Git contributor as LTS maintainer? One who is deeply
familiar with the Git project and can, if the need arises, help the Git
project steer clear of unnecessary conflict-making e.g. via
intentionally-incompatible bug fixes on the non-LTS branch? Kind of like
the lieutenants in the Linux kernel project.

Naturally, I am thinking of you, Patrick. You have demonstrated diligent
work in the Git project, are highly trusted both inside and outside the
Git project, and you seem to genuinely care about the long-term success of
the Git project.

An additional benefit of this would be to have a dependable release policy
for older release trains, just like other projects have. I have heard the
desire for such a policy many times.

Ciao,
Johannes

P.S.: As you probably know from my past interactions on this mailing list,
I am not typically one to dump work on others; I am more than willing to
assist you in the LTS maintenance tasks in any way I can.

Re: LTS "lieutenant", was Re: [PATCH RFC v4 7/9] BreakingChanges: announce Rust becoming mandatory

[Patrick Steinhardt]

On Tue, Sep 23, 2025 at 10:53:02AM +0200, Johannes Schindelin wrote:
> Let me propose an alternative, one that is much more likely to be accepted
> by actual Git users, including professional ones: How about assigning a
> trusted, prolific Git contributor as LTS maintainer? One who is deeply
> familiar with the Git project and can, if the need arises, help the Git
> project steer clear of unnecessary conflict-making e.g. via
> intentionally-incompatible bug fixes on the non-LTS branch? Kind of like
> the lieutenants in the Linux kernel project.
> 
> Naturally, I am thinking of you, Patrick. You have demonstrated diligent
> work in the Git project, are highly trusted both inside and outside the
> Git project, and you seem to genuinely care about the long-term success of
> the Git project.
> 
> An additional benefit of this would be to have a dependable release policy
> for older release trains, just like other projects have. I have heard the
> desire for such a policy many times.

As I mentioned in another part of this thread I think it's still a bit
premature to talk about how all of this will play out, as the potential
LTS release is still at least a year out, and then it'll be probably a
while before we actually need to care about handing over to an LTS
maintainer.

That being said: I already mentioned somewhere (please don't ask me
where, I don't know anymore and the threads are huge) that I would be
willing to do this. It certainly is not the most glorious or joyful
task, but hopefully this isn't too much work? Maybe I'm being naive
and will regret it.

I certainly don't insist on doing it -- if anyone else would feel like
they would really like to do it in my stead, then I wouldn't complain,
either.

In the end I think we should discuss this more and finalize details once
the LTS release handover becomes more concrete. Right now, it's still
this distant thing in the future, and who knows what projects I'll find
until then to fall into disfavor :)

Patrick

Re: [PATCH RFC v4 7/9] BreakingChanges: announce Rust becoming mandatory

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

> On Mon, Sep 22, 2025 at 09:24:26AM -0700, Junio C Hamano wrote:
>> Patrick Steinhardt <ps@pks.im> writes:
>> >
>> > I think the most important part here is that this community-supported
>> > LTS release should still live in the canonical repositories. We should
>> > avoid the situation where we hand over maintainership to such a degree
>> > that the end result (the tagged LTS release) lives somewhere else.
>> 
>> Why is it a bad thing?  The official repository can have a README.md
>> with a single entry "maintenance releases for Git 2.98 LTS (most
>> notably with no Rust requirements) are found at this separate site".

I've been hoping that the relationship between LTS and the main
project would be similar to the one between Git for Windows and the
main project.  A friendly fork, that is led by competent folks who
are familiar with what is happening in the main project and are
trusted by their users.  They carry many changes on top of what the
main project has produced, many of them may not have been submit to
the main projecte for approval, and the main project does not even
feel the need to approve their changes, simply because it trust the
friendly fork.

I was hoping that anybody who read my message, from a later
reference to the coordinated disclosure example that lists the main
project, GfW, and LTS, as three friendly equals, would understand
that it was my assumption, but it seems that what you depict is
vastly different.

> There's a couple reasons:
>
>   - The LTS maintainer may not be as familiar with the Git codebase as
>   - The LTS maintainer may not be as trusted as other regulars on the

If you assume that you can only get incompetent folks who would not
be trusted by their users by their own ability and dedication, I do
not think an endorsement by the main project would help them gain
trust at all.  All it would do to force the main project to blindly
sign their output is to tarnish the brand of the main project.

In other words, you are assuming that no competent folks would want
to be the "LTS maintainer"(s), and you are arguing that if we really
want a "Rustless Git", which will be used by the general public, to
exist, we should be the ones that are working on it.

>> edge.  Most importantly, a coordinated disclosure would say that the
>> update to versions of
>> 
>>  - Git 3.0 to Git 3.4 are found $HERE, 
>>  - Git for Windows 3.0, 3.2, and 3.4 are found $THERE
>>  - Git 2.98 are found $COMMUNITY_LTS
>> 
>> to make sure that people know where to find their updates.
>> 
>> So, no, I do not think we should unnecessarily mix community LTS and
>> the main project.
>
> How about the following tradeoff: the community LTS is developed outside
> of the usual Git workflow, for example on a forge, so that the LTS
> maintainers can work in their preferred flow. But eventually, once they
> want to do a release they send a pull request to the Git mailing list
> and then the tag lives in the canonical Git repository.

I do not think, with your assumption that LTS maintainer(s) are
incompetent ones that cannot gain users' trust by themselves, such
an arrangement would work.  Its only effect would be to tarnish the
brand of the main project if we rubber stamp endorse their ware.

Re: [PATCH RFC v4 7/9] BreakingChanges: announce Rust becoming mandatory

[Patrick Steinhardt]

On Tue, Sep 23, 2025 at 07:31:32AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> > There's a couple reasons:
> >
> >   - The LTS maintainer may not be as familiar with the Git codebase as
> >   - The LTS maintainer may not be as trusted as other regulars on the
> 
> If you assume that you can only get incompetent folks who would not
> be trusted by their users by their own ability and dedication, I do
> not think an endorsement by the main project would help them gain
> trust at all.  All it would do to force the main project to blindly
> sign their output is to tarnish the brand of the main project.
> 
> In other words, you are assuming that no competent folks would want
> to be the "LTS maintainer"(s), and you are arguing that if we really
> want a "Rustless Git", which will be used by the general public, to
> exist, we should be the ones that are working on it.

I think there's a wide range between "competent" and "incompetent". I
would generally assume for example distro maintainers to be competent,
but they probably don't have as much expertise in the Git codebase
compared to a frequent committer to Git. So there's nuances here, and I
think in such cases everyone would benefit if they had a helping hand
from the Git project.

> >> edge.  Most importantly, a coordinated disclosure would say that the
> >> update to versions of
> >> 
> >>  - Git 3.0 to Git 3.4 are found $HERE, 
> >>  - Git for Windows 3.0, 3.2, and 3.4 are found $THERE
> >>  - Git 2.98 are found $COMMUNITY_LTS
> >> 
> >> to make sure that people know where to find their updates.
> >> 
> >> So, no, I do not think we should unnecessarily mix community LTS and
> >> the main project.
> >
> > How about the following tradeoff: the community LTS is developed outside
> > of the usual Git workflow, for example on a forge, so that the LTS
> > maintainers can work in their preferred flow. But eventually, once they
> > want to do a release they send a pull request to the Git mailing list
> > and then the tag lives in the canonical Git repository.
> 
> I do not think, with your assumption that LTS maintainer(s) are
> incompetent ones that cannot gain users' trust by themselves, such
> an arrangement would work.  Its only effect would be to tarnish the
> brand of the main project if we rubber stamp endorse their ware.

Yeah, rubber-stamping doesn't really help indeed. The idea wasn't to do
that though, but to still do a sanity check of the new version.

I guess ultimately we'll have to figure out the details along the way.
There's many questions we cannot answer at this point in time yet, like:

  - When is the LTS maintainership handed over to the community?

  - Who is the community member that takes over maintainership of the
    LTS release?

  - How long do we expect to require the LTS release?

  - Will we even need it in the first place for Rustless builds?

So maybe it's premature at the current point in time to already spell
out details. Should we maybe just defer that decision into the future?
E.g. something like the below patch.

Patrick

diff --git a/Documentation/BreakingChanges.adoc b/Documentation/BreakingChanges.adoc
index 3b54750621..bf3173013d 100644
--- a/Documentation/BreakingChanges.adoc
+++ b/Documentation/BreakingChanges.adoc
@@ -200,9 +200,9 @@ The Git project will declare the last version before Git 3.0 to be a long-term
 support release. This long-term release will receive important bug fixes for at
 least four release cycles and security fixes for six release cycles. The Git
 project will hand over maintainership of the long-term release to distributors
-in case they need to extend the life of that long-term release even further. In
-that case, the backporting process will be handled by these distributors, but
-the long-term release tags will be created in the canonical Git repository.
+in case they need to extend the life of that long-term release even further.
+Details of how this long-term release will be handed over to the community will
+be decided once the Git project decides to stop officially supporting it.
 +
 We will evaluate the impact on downstream distributions before making Rust
 mandatory in Git 3.0. If we see that the impact on downstream distributions

Re: [PATCH RFC v4 7/9] BreakingChanges: announce Rust becoming mandatory

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

> So maybe it's premature at the current point in time to already spell
> out details. Should we maybe just defer that decision into the future?
> E.g. something like the below patch.
>
> Patrick
>
> diff --git a/Documentation/BreakingChanges.adoc b/Documentation/BreakingChanges.adoc
> index 3b54750621..bf3173013d 100644
> --- a/Documentation/BreakingChanges.adoc
> +++ b/Documentation/BreakingChanges.adoc
> @@ -200,9 +200,9 @@ The Git project will declare the last version before Git 3.0 to be a long-term
>  support release. This long-term release will receive important bug fixes for at
>  least four release cycles and security fixes for six release cycles. The Git
>  project will hand over maintainership of the long-term release to distributors
> -in case they need to extend the life of that long-term release even further. In
> -that case, the backporting process will be handled by these distributors, but
> -the long-term release tags will be created in the canonical Git repository.
> +in case they need to extend the life of that long-term release even further.
> +Details of how this long-term release will be handed over to the community will
> +be decided once the Git project decides to stop officially supporting it.
>  +
>  We will evaluate the impact on downstream distributions before making Rust
>  mandatory in Git 3.0. If we see that the impact on downstream distributions

Yup, punting on this would not hurt our overall timeline, so let's
achieve concensus on other parts of the document and the patches.

Thanks.

Re: [PATCH RFC v4 7/9] BreakingChanges: announce Rust becoming mandatory

[Kristoffer Haugsbakk]

On Wed, Sep 10, 2025, at 17:35, Patrick Steinhardt wrote:
> Over the last couple of years the appetite for bringin Rust into the

s/bringin/bringing/

https://lore.kernel.org/git/CAPig+cThyuo7=A2f7_XkE_TZmSRc5i=EFgZOw_pKgu+Ckgx70w@mail.gmail.com/

>[snip]
> ---
>  Documentation/BreakingChanges.adoc | 36 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 36 insertions(+)
>
> diff --git a/Documentation/BreakingChanges.adoc
> b/Documentation/BreakingChanges.adoc
> index f8d2eba061..3550e9fc27 100644
> --- a/Documentation/BreakingChanges.adoc
> +++ b/Documentation/BreakingChanges.adoc
> @@ -165,6 +165,42 @@ A prerequisite for this change is that the
> ecosystem is ready to support the
>  "reftable" format. Most importantly, alternative implementations of
> Git like
>  JGit, libgit2 and Gitoxide need to support it.
>
> +* Git will require Rust as a mandatory part of the build process.
> While Git
> +  already started to adopt Rust in Git 2.52, all parts written in Rust
> are
> +  optional for the time being. This includes:
> ++
> +  ** Subsystems that have an alternative implementation in Rust to test
> +     interoperability between our C and Rust codebase.
> +  ** Newly written features that are not mission critical for a fully
> functional
> +     Git client.
> ++
> +These changes are meant as test balloons to allow distributors of Git
> to prepare
> +for Rust becoming a mandatory part of the build process. There will be
> multiple
> +milestones for the introduction of Rust:
> ++
> +1. Initially, with Git 2.52, support for Rust will be auto-detected by
> Meson and
> +   disabled in our Makefile so that the project can sort out the
> initial
> +   infrastructure.
> +2. In Git 2.53, both build systems will default-enable support for
> Rust.
> +   Consequently, builds will break by default if Rust is not available
> on the
> +   build host. The use of Rust can still be explicitly disabled via
> build
> +   flags.
> +3. In Git 3.0, the build options will be removed and support for Rust
> is
> +   mandatory.
> ++

Some minutiae: the HTML output is like

    3. In Git 3.0, ...

       You can explicitly ...

But it seems from the text that the paragraph after (3) should go back
to the previous level:

    3. In ...

    You ...

You’ll need to put these three list items in an `--` in order to get the
latter.  Or that’s one option (that I tried).

> +You can explicitly ask both Meson and our Makefile-based system to
> enable Rust
> +by saying `meson configure -Drust=enabled` and `make
> WITH_RUST=YesPlease`,
> +respectively.
>[snip]

Re: [PATCH RFC v4 7/9] BreakingChanges: announce Rust becoming mandatory

[Patrick Steinhardt]

On Wed, Sep 10, 2025 at 11:42:05PM +0200, Kristoffer Haugsbakk wrote:
> On Wed, Sep 10, 2025, at 17:35, Patrick Steinhardt wrote:
> > +These changes are meant as test balloons to allow distributors of Git
> > to prepare
> > +for Rust becoming a mandatory part of the build process. There will be
> > multiple
> > +milestones for the introduction of Rust:
> > ++
> > +1. Initially, with Git 2.52, support for Rust will be auto-detected by
> > Meson and
> > +   disabled in our Makefile so that the project can sort out the
> > initial
> > +   infrastructure.
> > +2. In Git 2.53, both build systems will default-enable support for
> > Rust.
> > +   Consequently, builds will break by default if Rust is not available
> > on the
> > +   build host. The use of Rust can still be explicitly disabled via
> > build
> > +   flags.
> > +3. In Git 3.0, the build options will be removed and support for Rust
> > is
> > +   mandatory.
> > ++
> 
> Some minutiae: the HTML output is like
> 
>     3. In Git 3.0, ...
> 
>        You can explicitly ...
> 
> But it seems from the text that the paragraph after (3) should go back
> to the previous level:
> 
>     3. In ...
> 
>     You ...
> 
> You’ll need to put these three list items in an `--` in order to get the
> latter.  Or that’s one option (that I tried).

Ah, indeed. Thanks for your careful eyes, fixed locally now.

Patrick

[PATCH RFC v4 8/9] ci: convert "pedantic" job into full build with breaking changes

[Patrick Steinhardt]

The "pedantic" CI job is building on Fedora with `DEVOPTS=pedantic`.
This build flag doesn't do anything anymore starting with 6a8cbc41ba
(developer: enable pedantic by default, 2021-09-03), where we have
flipped the default so that developers have to opt-out of pedantic
builds via the "no-pedantic" option. As such, all this job really does
is to do a normal build on Fedora, which isn't all that interesting.

Convert that job into a full build-and-test job that uses Meson with
breaking changes enabled. This plugs two gaps:

  - We now test on another distro that we didn't run tests on
    beforehand.

  - We verify that breaking changes work as expected with Meson.

Furthermore, in a subsequent commit we'll modify both jobs that use
breaking changes to also enable Rust. By converting the Fedora job to
use Meson, we ensure that we test our Rust build infrastructure for both
build systems.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 .github/workflows/main.yml |  4 ++--
 .gitlab-ci.yml             |  4 ++--
 ci/install-dependencies.sh |  6 +++++-
 ci/run-build-and-tests.sh  | 29 ++++++++---------------------
 4 files changed, 17 insertions(+), 26 deletions(-)

diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index d122e79415..393ea4d1cc 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -379,6 +379,8 @@ jobs:
         - jobname: linux-breaking-changes
           cc: gcc
           image: ubuntu:rolling
+        - jobname: fedora-breaking-changes-meson
+          image: fedora:latest
         - jobname: linux-leaks
           image: ubuntu:rolling
           cc: gcc
@@ -396,8 +398,6 @@ jobs:
         # Supported until 2025-04-02.
         - jobname: linux32
           image: i386/ubuntu:focal
-        - jobname: pedantic
-          image: fedora:latest
         # A RHEL 8 compatible distro.  Supported until 2029-05-31.
         - jobname: almalinux-8
           image: almalinux:8
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index af10ebb59a..4248506909 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -45,6 +45,8 @@ test:linux:
       - jobname: linux-breaking-changes
         image: ubuntu:20.04
         CC: gcc
+      - jobname: fedora-breaking-changes-meson
+        image: fedora:latest
       - jobname: linux-TEST-vars
         image: ubuntu:20.04
         CC: gcc
@@ -58,8 +60,6 @@ test:linux:
       - jobname: linux-asan-ubsan
         image: ubuntu:rolling
         CC: clang
-      - jobname: pedantic
-        image: fedora:latest
       - jobname: linux-musl-meson
         image: alpine:latest
       - jobname: linux32
diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh
index d061a47293..35bd05b85b 100755
--- a/ci/install-dependencies.sh
+++ b/ci/install-dependencies.sh
@@ -30,8 +30,12 @@ alpine-*)
 		bash cvs gnupg perl-cgi perl-dbd-sqlite perl-io-tty >/dev/null
 	;;
 fedora-*|almalinux-*)
+	case "$jobname" in
+	*-meson)
+		MESON_DEPS="meson ninja";;
+	esac
 	dnf -yq update >/dev/null &&
-	dnf -yq install shadow-utils sudo make gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null
+	dnf -yq install shadow-utils sudo make pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel $MESON_DEPS >/dev/null
 	;;
 ubuntu-*|i386/ubuntu-*|debian-*)
 	# Required so that apt doesn't wait for user input on certain packages.
diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index 01823fd0f1..3680446649 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -5,12 +5,11 @@
 
 . ${0%/*}/lib.sh
 
-run_tests=t
-
 case "$jobname" in
-linux-breaking-changes)
+fedora-breaking-changes-musl|linux-breaking-changes)
 	export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
 	export WITH_BREAKING_CHANGES=YesPlease
+	MESONFLAGS="$MESONFLAGS -Dbreaking_changes=true"
 	;;
 linux-TEST-vars)
 	export OPENSSL_SHA1_UNSAFE=YesPlease
@@ -36,12 +35,6 @@ linux-sha256)
 linux-reftable|linux-reftable-leaks|osx-reftable)
 	export GIT_TEST_DEFAULT_REF_FORMAT=reftable
 	;;
-pedantic)
-	# Don't run the tests; we only care about whether Git can be
-	# built.
-	export DEVOPTS=pedantic
-	run_tests=
-	;;
 esac
 
 case "$jobname" in
@@ -54,21 +47,15 @@ case "$jobname" in
 		-Dtest_output_directory="${TEST_OUTPUT_DIRECTORY:-$(pwd)/t}" \
 		$MESONFLAGS
 	group "Build" meson compile -C build --
-	if test -n "$run_tests"
-	then
-		group "Run tests" meson test -C build --print-errorlogs --test-args="$GIT_TEST_OPTS" || (
-			./t/aggregate-results.sh "${TEST_OUTPUT_DIRECTORY:-t}/test-results"
-			handle_failed_tests
-		)
-	fi
+	group "Run tests" meson test -C build --print-errorlogs --test-args="$GIT_TEST_OPTS" || (
+		./t/aggregate-results.sh "${TEST_OUTPUT_DIRECTORY:-t}/test-results"
+		handle_failed_tests
+	)
 	;;
 *)
 	group Build make
-	if test -n "$run_tests"
-	then
-		group "Run tests" make test ||
-		handle_failed_tests
-	fi
+	group "Run tests" make test ||
+	handle_failed_tests
 	;;
 esac
 

-- 
2.51.0.450.g87641ccf93.dirty

[PATCH RFC v4 9/9] ci: enable Rust for breaking-changes jobs

[Patrick Steinhardt]

Enable Rust for our breaking-changes jobs so that we can verify that the
build infrastructure and the converted Rust subsystems work as expected.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 ci/install-dependencies.sh | 4 ++--
 ci/run-build-and-tests.sh  | 2 ++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh
index 35bd05b85b..0d3aa496fc 100755
--- a/ci/install-dependencies.sh
+++ b/ci/install-dependencies.sh
@@ -35,7 +35,7 @@ fedora-*|almalinux-*)
 		MESON_DEPS="meson ninja";;
 	esac
 	dnf -yq update >/dev/null &&
-	dnf -yq install shadow-utils sudo make pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel $MESON_DEPS >/dev/null
+	dnf -yq install shadow-utils sudo make pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel $MESON_DEPS cargo >/dev/null
 	;;
 ubuntu-*|i386/ubuntu-*|debian-*)
 	# Required so that apt doesn't wait for user input on certain packages.
@@ -62,7 +62,7 @@ ubuntu-*|i386/ubuntu-*|debian-*)
 		make libssl-dev libcurl4-openssl-dev libexpat-dev wget sudo default-jre \
 		tcl tk gettext zlib1g-dev perl-modules liberror-perl libauthen-sasl-perl \
 		libemail-valid-perl libio-pty-perl libio-socket-ssl-perl libnet-smtp-ssl-perl libdbd-sqlite3-perl libcgi-pm-perl \
-		libsecret-1-dev libpcre2-dev meson ninja-build pkg-config \
+		libsecret-1-dev libpcre2-dev meson ninja-build pkg-config cargo \
 		${CC_PACKAGE:-${CC:-gcc}} $PYTHON_PACKAGE
 
 	case "$distro" in
diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index 3680446649..c718bd101a 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -9,7 +9,9 @@ case "$jobname" in
 fedora-breaking-changes-musl|linux-breaking-changes)
 	export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
 	export WITH_BREAKING_CHANGES=YesPlease
+	export WITH_RUST=YesPlease
 	MESONFLAGS="$MESONFLAGS -Dbreaking_changes=true"
+	MESONFLAGS="$MESONFLAGS -Drust=enabled"
 	;;
 linux-TEST-vars)
 	export OPENSSL_SHA1_UNSAFE=YesPlease

-- 
2.51.0.450.g87641ccf93.dirty

Re: [PATCH RFC v4 0/9] Introduce Rust and announce that it will become mandatory

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2202 bytes --]

On 2025-09-10 at 15:35:46, Patrick Steinhardt wrote:
> Hi,
> 
> this small patch series introduces Rust into the core of Git. This patch
> series is designed as a test balloon, similar to how we introduced test
> balloons for C99 features in the past. The goal is threefold:
> 
>   - Give us some time to experiment with Rust and introduce proper build
>     infrastructure.
> 
>   - Give distributors time to ease into the new toolchain requirements.
>     Introducing Rust is impossible for some platforms and hard for
>     others.
> 
>   - Announce that Git 3.0 will make Rust a mandatory part of our build
>     infrastructure.
> 
> The test balloon itself is quite uninteresting: I've chosen to convert
> the "varint.c" subsystem, mostly because it is trivial and does not have
> any dependencies. But it does allow us to verify that C to Rust interop
> works as expected, and to play around with tooling. All tests pass with
> the "varint.rs" implementation.
> 
> For now, the series only contains support for Meson. If we agree to go
> down this route I'll also introduce support for Rust into our Makefiles
> at a later point in time.
> 
> Furthermore missing is additional tooling:
> 
>   - At least one CI job to verify that Rust builds and works as
>     expected.
> 
>   - Tooling and CI jobs to ensure that we have consistent formatting via
>     `cargo format`.
> 
> And probably lots more. As said, the entire goal is for us to have an
> easy playground that we can experiment on and develop the infrastructure
> incrementally without yet having to commit to anything.

I may end up sending in a patch or two for these if I have some time.

I did note the discussion about what the LTS process looks like, which I
don't have strong opinions about but do want to make sure the project
(including folks on the security list) is willing to support.  Other
than that, this series looked reasonable to me.  I also confirmed that
it works with my existing sha256-interop-part-2 series, which I
appreciate.

I think once we have agreement on the LTS process, this should be good
to go.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [PATCH RFC v4 0/9] Introduce Rust and announce that it will become mandatory

[Patrick Steinhardt]

On Thu, Sep 11, 2025 at 09:55:54PM +0000, brian m. carlson wrote:
> I may end up sending in a patch or two for these if I have some time.

Sure! No pressure here, us being able to iterate is why I wanted to make
things opt-in in the first release.

> I did note the discussion about what the LTS process looks like, which I
> don't have strong opinions about but do want to make sure the project
> (including folks on the security list) is willing to support.  Other
> than that, this series looked reasonable to me.  I also confirmed that
> it works with my existing sha256-interop-part-2 series, which I
> appreciate.

That's awesome, thanks for confirming.

> I think once we have agreement on the LTS process, this should be good
> to go.

Yay! In any case, I would be okay to help out with the LTS process as
long as it's still owned by the Git project.

Patrick

Re: [PATCH RFC v4 0/9] Introduce Rust and announce that it will become mandatory

[SZEDER Gábor]

On Wed, Sep 10, 2025 at 05:35:46PM +0200, Patrick Steinhardt wrote:
> Hi,
> 
> this small patch series introduces Rust into the core of Git. This patch
> series is designed as a test balloon, similar to how we introduced test
> balloons for C99 features in the past. The goal is threefold:
> 
>   - Give us some time to experiment with Rust and introduce proper build
>     infrastructure.
> 
>   - Give distributors time to ease into the new toolchain requirements.
>     Introducing Rust is impossible for some platforms and hard for
>     others.
> 
>   - Announce that Git 3.0 will make Rust a mandatory part of our build
>     infrastructure.
> 
> The test balloon itself is quite uninteresting: I've chosen to convert
> the "varint.c" subsystem, mostly because it is trivial and does not have
> any dependencies. But it does allow us to verify that C to Rust interop
> works as expected, and to play around with tooling. All tests pass with
> the "varint.rs" implementation.
> 
> For now, the series only contains support for Meson. If we agree to go
> down this route I'll also introduce support for Rust into our Makefiles
> at a later point in time.
> 
> Furthermore missing is additional tooling:
> 
>   - At least one CI job to verify that Rust builds and works as
>     expected.
> 
>   - Tooling and CI jobs to ensure that we have consistent formatting via
>     `cargo format`.
> 
> And probably lots more. As said, the entire goal is for us to have an
> easy playground that we can experiment on and develop the infrastructure
> incrementally without yet having to commit to anything.
> 
> I'm mostly splitting out the topic of introducing Rust from the larger
> series that introduce it into xdiff so that we can focus more on the
> actual process of introducing Rust into Git and less on the potential
> features that we want to build on top of it.
> 
> Changes in v2:
>   - Introduce support for building the Rust library via our Makefile.
>   - Introduce a '-DWITH_RUST' define. This define is used to print
>     whether or not Git is built with Rust via `git version
>     --build-options`.
>   - Adjust Meson to not depend on v1.9.0 and newer anymore.
>   - Introduce a roadmap into our BreakingChanges document to explain how
>     we'll iterate towards mandatory Rust support.
>   - Rework the Fedora job to do a full compile-and-test run with Meson
>     and breaking changes enabled.
>   - Adapt our breaking-changes jobs to enable Rust support.
>   - Link to v1: https://lore.kernel.org/r/20250904-b4-pks-rust-breaking-change-v1-0-3af1d25e0be9@pks.im
> 
> Changes in v3:
>   - Reorder all uses of `WITH_RUST` after the include of "config.mak".
>   - Add a test to verify overflow behaviour in Rust and explicitly use
>     `add_wrapping()`.
>   - Use explicit dependencies for the Rust library in our Makefile.
>   - Fix Alma Linux CI job.
>   - Stop tying maintenance of our LTS release to the availability of
>     gcc-rs.
>   - Add a fallback to Meson to use cargo directly.
>   - I've fixed the Rust edition to 2018 for now. This is intentionally
>     conservative so that we might be able to use Rust 1.49. For now, we
>     don't have any reason to use a newer edition, either. So let's take
>     the oldest version we can live with for now and then bump it as
>     required.
>   - Link to v2: https://lore.kernel.org/r/20250905-b4-pks-rust-breaking-change-v2-0-6939cbf4a0b8@pks.im
> 
> Changes in v4:
>   - Convert "varint.c" to use explicit integer width so that we don't
>     need to use C types in Rust.
>   - Adapt Meson to unconditionally use Cargo.
>   - Don't use the unstable `--out-dir` option in Cargo. Instead, we
>     resort to a wrapper script in Meson.
>   - Shorten the timeline a bit to drop the extra step that ties Rust
>     support to `-Dbreaking_changes=true`. This accelerates the timeline
>     until distros are made forcibly aware of the upcoming changes in
>     Rust.
>   - Link to v3: https://lore.kernel.org/r/20250908-b4-pks-rust-breaking-change-v3-0-1cd7189fed3b@pks.im
> 
> Thanks!
> 
> Patrick
> 
> ---
> Patrick Steinhardt (9):
>       meson: add infrastructure to build internal Rust library
>       Makefile: reorder sources after includes
>       Makefile: introduce infrastructure to build internal Rust library
>       help: report on whether or not Rust is enabled
>       varint: use explicit width for integers
>       varint: reimplement as test balloon for Rust
>       BreakingChanges: announce Rust becoming mandatory
>       ci: convert "pedantic" job into full build with breaking changes
>       ci: enable Rust for breaking-changes jobs
> 
>  .github/workflows/main.yml         |   4 +-
>  .gitignore                         |   2 +
>  .gitlab-ci.yml                     |   4 +-
>  Cargo.toml                         |   9 ++
>  Documentation/BreakingChanges.adoc |  36 +++++++
>  Makefile                           | 214 ++++++++++++++++++++++---------------
>  ci/install-dependencies.sh         |   8 +-
>  ci/run-build-and-tests.sh          |  31 ++----
>  dir.c                              |  18 ++--
>  help.c                             |   6 ++
>  meson.build                        |  15 ++-
>  meson_options.txt                  |   2 +
>  read-cache.c                       |   6 +-
>  shared.mak                         |   1 +
>  src/cargo-meson.sh                 |  32 ++++++
>  src/lib.rs                         |   1 +
>  src/meson.build                    |  41 +++++++
>  src/varint.rs                      |  92 ++++++++++++++++
>  varint.c                           |   6 +-
>  varint.h                           |   4 +-
>  20 files changed, 401 insertions(+), 131 deletions(-)
> 
> Range-diff versus v3:
> 
>  1:  a25408af71 <  -:  ---------- meson: add infrastructure to build internal Rust library
>  -:  ---------- >  1:  ccdb7e264d meson: add infrastructure to build internal Rust library
>  2:  a9c639b0f3 =  2:  b88c80f7e9 Makefile: reorder sources after includes
>  3:  ccac54a247 !  3:  873f9d82f5 Makefile: introduce infrastructure to build internal Rust library
>     @@ .gitignore
>      @@
>       /fuzz_corpora
>      +/target/
>     ++/Cargo.lock

The Cargo.lock build artifact is back in .gitignore in this version of
the patch series, but the 'clean' target is not updated accordingly to
remove it.

>       /GIT-BUILD-DIR
>       /GIT-BUILD-OPTIONS
>       /GIT-CFLAGS
>  4:  b357ff9463 =  4:  4e70509175 help: report on whether or not Rust is enabled

Re: [PATCH RFC v4 0/9] Introduce Rust and announce that it will become mandatory

[Junio C Hamano]

SZEDER Gábor <szeder.dev@gmail.com> writes:

>>  3:  ccac54a247 !  3:  873f9d82f5 Makefile: introduce infrastructure to build internal Rust library
>>     @@ .gitignore
>>      @@
>>       /fuzz_corpora
>>      +/target/
>>     ++/Cargo.lock
>
> The Cargo.lock build artifact is back in .gitignore in this version of
> the patch series, but the 'clean' target is not updated accordingly to
> remove it.

I too noticed a leftover Cargo.lock file but was a bit too
distracted to report it (and instead kept going with "git clean -f"
X-<); my bad.

Thanks for being extra careful.

Re: [PATCH RFC v4 0/9] Introduce Rust and announce that it will become mandatory

[Patrick Steinhardt]

On Fri, Sep 12, 2025 at 09:32:58AM -0700, Junio C Hamano wrote:
> SZEDER Gábor <szeder.dev@gmail.com> writes:
> 
> >>  3:  ccac54a247 !  3:  873f9d82f5 Makefile: introduce infrastructure to build internal Rust library
> >>     @@ .gitignore
> >>      @@
> >>       /fuzz_corpora
> >>      +/target/
> >>     ++/Cargo.lock
> >
> > The Cargo.lock build artifact is back in .gitignore in this version of
> > the patch series, but the 'clean' target is not updated accordingly to
> > remove it.
> 
> I too noticed a leftover Cargo.lock file but was a bit too
> distracted to report it (and instead kept going with "git clean -f"
> X-<); my bad.
> 
> Thanks for being extra careful.

Ah, good catch indeed! Will fix, thanks.

Patrick

[PATCH v5 0/9] Introduce Rust and announce that it will become mandatory

[Patrick Steinhardt]

Hi,

this small patch series introduces Rust into the core of Git. This patch
series is designed as a test balloon, similar to how we introduced test
balloons for C99 features in the past. The goal is threefold:

  - Give us some time to experiment with Rust and introduce proper build
    infrastructure.

  - Give distributors time to ease into the new toolchain requirements.
    Introducing Rust is impossible for some platforms and hard for
    others.

  - Announce that Git 3.0 will make Rust a mandatory part of our build
    infrastructure.

The test balloon itself is quite uninteresting: I've chosen to convert
the "varint.c" subsystem, mostly because it is trivial and does not have
any dependencies. But it does allow us to verify that C to Rust interop
works as expected, and to play around with tooling. All tests pass with
the "varint.rs" implementation.

For now, the series only contains support for Meson. If we agree to go
down this route I'll also introduce support for Rust into our Makefiles
at a later point in time.

Furthermore missing is additional tooling:

  - At least one CI job to verify that Rust builds and works as
    expected.

  - Tooling and CI jobs to ensure that we have consistent formatting via
    `cargo format`.

And probably lots more. As said, the entire goal is for us to have an
easy playground that we can experiment on and develop the infrastructure
incrementally without yet having to commit to anything.

I'm mostly splitting out the topic of introducing Rust from the larger
series that introduce it into xdiff so that we can focus more on the
actual process of introducing Rust into Git and less on the potential
features that we want to build on top of it.

Changes in v2:
  - Introduce support for building the Rust library via our Makefile.
  - Introduce a '-DWITH_RUST' define. This define is used to print
    whether or not Git is built with Rust via `git version
    --build-options`.
  - Adjust Meson to not depend on v1.9.0 and newer anymore.
  - Introduce a roadmap into our BreakingChanges document to explain how
    we'll iterate towards mandatory Rust support.
  - Rework the Fedora job to do a full compile-and-test run with Meson
    and breaking changes enabled.
  - Adapt our breaking-changes jobs to enable Rust support.
  - Link to v1: https://lore.kernel.org/r/20250904-b4-pks-rust-breaking-change-v1-0-3af1d25e0be9@pks.im

Changes in v3:
  - Reorder all uses of `WITH_RUST` after the include of "config.mak".
  - Add a test to verify overflow behaviour in Rust and explicitly use
    `add_wrapping()`.
  - Use explicit dependencies for the Rust library in our Makefile.
  - Fix Alma Linux CI job.
  - Stop tying maintenance of our LTS release to the availability of
    gcc-rs.
  - Add a fallback to Meson to use cargo directly.
  - I've fixed the Rust edition to 2018 for now. This is intentionally
    conservative so that we might be able to use Rust 1.49. For now, we
    don't have any reason to use a newer edition, either. So let's take
    the oldest version we can live with for now and then bump it as
    required.
  - Link to v2: https://lore.kernel.org/r/20250905-b4-pks-rust-breaking-change-v2-0-6939cbf4a0b8@pks.im

Changes in v4:
  - Convert "varint.c" to use explicit integer width so that we don't
    need to use C types in Rust.
  - Adapt Meson to unconditionally use Cargo.
  - Don't use the unstable `--out-dir` option in Cargo. Instead, we
    resort to a wrapper script in Meson.
  - Shorten the timeline a bit to drop the extra step that ties Rust
    support to `-Dbreaking_changes=true`. This accelerates the timeline
    until distros are made forcibly aware of the upcoming changes in
    Rust.
  - Link to v3: https://lore.kernel.org/r/20250908-b4-pks-rust-breaking-change-v3-0-1cd7189fed3b@pks.im

Changes in v5:
  - Fix indentation in the BreakingChanges document.
  - Fix a commit message typo.
  - Include "Cargo.lock" in the `make clean` target again.
  - Link to v4: https://lore.kernel.org/r/20250910-b4-pks-rust-breaking-change-v4-0-4a63fc69278d@pks.im

Thanks!

Patrick

---
Patrick Steinhardt (9):
      meson: add infrastructure to build internal Rust library
      Makefile: reorder sources after includes
      Makefile: introduce infrastructure to build internal Rust library
      help: report on whether or not Rust is enabled
      varint: use explicit width for integers
      varint: reimplement as test balloon for Rust
      BreakingChanges: announce Rust becoming mandatory
      ci: convert "pedantic" job into full build with breaking changes
      ci: enable Rust for breaking-changes jobs

 .github/workflows/main.yml         |   4 +-
 .gitignore                         |   2 +
 .gitlab-ci.yml                     |   4 +-
 Cargo.toml                         |   9 ++
 Documentation/BreakingChanges.adoc |  38 +++++++
 Makefile                           | 214 ++++++++++++++++++++++---------------
 ci/install-dependencies.sh         |   8 +-
 ci/run-build-and-tests.sh          |  31 ++----
 dir.c                              |  18 ++--
 help.c                             |   6 ++
 meson.build                        |  15 ++-
 meson_options.txt                  |   2 +
 read-cache.c                       |   6 +-
 shared.mak                         |   1 +
 src/cargo-meson.sh                 |  32 ++++++
 src/lib.rs                         |   1 +
 src/meson.build                    |  41 +++++++
 src/varint.rs                      |  92 ++++++++++++++++
 varint.c                           |   6 +-
 varint.h                           |   4 +-
 20 files changed, 403 insertions(+), 131 deletions(-)

Range-diff versus v4:

 1:  8e009fe5c3 =  1:  fae7d374da meson: add infrastructure to build internal Rust library
 2:  ad75e8afe1 =  2:  6202951039 Makefile: reorder sources after includes
 3:  9f182beba6 !  3:  a8ee5c33b5 Makefile: introduce infrastructure to build internal Rust library
    @@ Makefile: clean: profile-clean coverage-clean cocciclean
      	$(RM) $(FUZZ_PROGRAMS)
      	$(RM) $(SP_OBJ)
      	$(RM) $(HCC)
    -+	$(RM) -r target/
    ++	$(RM) -r Cargo.lock target/
      	$(RM) version-def.h
      	$(RM) -r $(dep_dirs) $(compdb_dir) compile_commands.json
      	$(RM) $(test_bindir_programs)
 4:  06cfc7ae33 =  4:  484c5a984f help: report on whether or not Rust is enabled
 5:  882d1e1f25 =  5:  c366ddd005 varint: use explicit width for integers
 6:  01405d242e =  6:  bb3f7b2606 varint: reimplement as test balloon for Rust
 7:  2e5e1ff9a1 !  7:  a96e89b4c4 BreakingChanges: announce Rust becoming mandatory
    @@ Metadata
      ## Commit message ##
         BreakingChanges: announce Rust becoming mandatory
     
    -    Over the last couple of years the appetite for bringin Rust into the
    +    Over the last couple of years the appetite for bringing Rust into the
         codebase has grown significantly across the developer base. Introducing
         Rust is a major change though and has ramifications for the whole
         ecosystem:
    @@ Documentation/BreakingChanges.adoc: A prerequisite for this change is that the e
     +for Rust becoming a mandatory part of the build process. There will be multiple
     +milestones for the introduction of Rust:
     ++
    ++--
     +1. Initially, with Git 2.52, support for Rust will be auto-detected by Meson and
     +   disabled in our Makefile so that the project can sort out the initial
     +   infrastructure.
    @@ Documentation/BreakingChanges.adoc: A prerequisite for this change is that the e
     +   flags.
     +3. In Git 3.0, the build options will be removed and support for Rust is
     +   mandatory.
    ++--
     ++
     +You can explicitly ask both Meson and our Makefile-based system to enable Rust
     +by saying `meson configure -Drust=enabled` and `make WITH_RUST=YesPlease`,
 8:  bd7170e906 =  8:  403731a732 ci: convert "pedantic" job into full build with breaking changes
 9:  f922a60198 =  9:  606786ce90 ci: enable Rust for breaking-changes jobs

---
base-commit: 2462961280690837670d997bde64bd4ebf8ae66d
change-id: 20250904-b4-pks-rust-breaking-change-7167d9d3e37d

[PATCH v5 1/9] meson: add infrastructure to build internal Rust library

[Patrick Steinhardt]

Add the infrastructure into Meson to build an internal Rust library.
Building the Rust parts of Git are for now entirely optional, as they
are mostly intended as a test balloon for both Git developers, but also
for distributors of Git. So for now, they may contain:

  - New features that are not mission critical to Git and that users can
    easily live without.

  - Alternative implementations of small subsystems.

If these test balloons are successful, we will eventually make Rust a
mandatory dependency for our build process in Git 3.0.

The availability of a Rust toolchain will be auto-detected by Meson at
setup time. This behaviour can be tweaked via the `-Drust=` feature
toggle.

Next to the linkable Rust library, also wire up tests that can be
executed via `meson test`. This allows us to use the native unit testing
capabilities of Rust.

Note that the Rust edition is currently set to 2018. This edition is
supported by Rust 1.49, which is the target for the upcoming gcc-rs
backend. For now we don't use any features of Rust that would require a
newer version, so settling on this old version makes sense so that
gcc-rs may become an alternative backend for compiling Git. If we _do_
want to introduce features that were added in more recent editions of
Rust though we should reevaluate that choice.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 Cargo.toml         |  9 +++++++++
 meson.build        | 10 +++++++++-
 meson_options.txt  |  2 ++
 src/cargo-meson.sh | 32 ++++++++++++++++++++++++++++++++
 src/lib.rs         |  0
 src/meson.build    | 40 ++++++++++++++++++++++++++++++++++++++++
 6 files changed, 92 insertions(+), 1 deletion(-)

diff --git a/Cargo.toml b/Cargo.toml
new file mode 100644
index 00000000000..b9a41dbc792
--- /dev/null
+++ b/Cargo.toml
@@ -0,0 +1,9 @@
+[package]
+name = "git"
+version = "0.1.0"
+edition = "2018"
+
+[lib]
+crate-type = ["staticlib"]
+
+[dependencies]
diff --git a/meson.build b/meson.build
index e8ec0eca165..234a9e9d6fd 100644
--- a/meson.build
+++ b/meson.build
@@ -220,7 +220,7 @@ project('git', 'c',
   # learned to define __STDC_VERSION__ with C11 and later. We thus require
   # GNU C99 and fall back to C11. Meson only learned to handle the fallback
   # with version 1.3.0, so on older versions we use GNU C99 unconditionally.
-  default_options: meson.version().version_compare('>=1.3.0') ? ['c_std=gnu99,c11'] : ['c_std=gnu99'],
+  default_options: meson.version().version_compare('>=1.3.0') ? ['rust_std=2018', 'c_std=gnu99,c11'] : ['rust_std=2018', 'c_std=gnu99'],
 )
 
 fs = import('fs')
@@ -1702,6 +1702,13 @@ version_def_h = custom_target(
 )
 libgit_sources += version_def_h
 
+cargo = find_program('cargo', dirs: program_path, native: true, required: get_option('rust'))
+rust_option = get_option('rust').disable_auto_if(not cargo.found())
+if rust_option.allowed()
+  subdir('src')
+  libgit_c_args += '-DWITH_RUST'
+endif
+
 libgit = declare_dependency(
   link_with: static_library('git',
     sources: libgit_sources,
@@ -2239,6 +2246,7 @@ summary({
   'pcre2': pcre2,
   'perl': perl_features_enabled,
   'python': target_python.found(),
+  'rust': rust_option.allowed(),
 }, section: 'Auto-detected features', bool_yn: true)
 
 summary({
diff --git a/meson_options.txt b/meson_options.txt
index 1668f260a18..143dee9237c 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -71,6 +71,8 @@ option('zlib_backend', type: 'combo', choices: ['auto', 'zlib', 'zlib-ng'], valu
 # Build tweaks.
 option('breaking_changes', type: 'boolean', value: false,
   description: 'Enable upcoming breaking changes.')
+option('rust', type: 'feature', value: 'auto',
+  description: 'Enable building with Rust.')
 option('macos_use_homebrew_gettext', type: 'boolean', value: true,
   description: 'Use gettext from Homebrew instead of the slightly-broken system-provided one.')
 
diff --git a/src/cargo-meson.sh b/src/cargo-meson.sh
new file mode 100755
index 00000000000..f29745beb36
--- /dev/null
+++ b/src/cargo-meson.sh
@@ -0,0 +1,32 @@
+#!/bin/sh
+
+if test "$#" -lt 2
+then
+	exit 1
+fi
+
+SOURCE_DIR="$1"
+BUILD_DIR="$2"
+BUILD_TYPE=debug
+
+shift 2
+
+for arg
+do
+	case "$arg" in
+	--release)
+		BUILD_TYPE=release;;
+	esac
+done
+
+cargo build --lib --quiet --manifest-path="$SOURCE_DIR/Cargo.toml" --target-dir="$BUILD_DIR" "$@"
+RET=$?
+if test $RET -ne 0
+then
+	exit $RET
+fi
+
+if ! cmp "$BUILD_DIR/$BUILD_TYPE/libgit.a" "$BUILD_DIR/libgit.a" >/dev/null 2>&1
+then
+	cp "$BUILD_DIR/$BUILD_TYPE/libgit.a" "$BUILD_DIR/libgit.a"
+fi
diff --git a/src/lib.rs b/src/lib.rs
new file mode 100644
index 00000000000..e69de29bb2d
diff --git a/src/meson.build b/src/meson.build
new file mode 100644
index 00000000000..734de0b4fa9
--- /dev/null
+++ b/src/meson.build
@@ -0,0 +1,40 @@
+libgit_rs_sources = [
+  'lib.rs',
+]
+
+# Unfortunately we must use a wrapper command to move the output file into the
+# current build directory. This can fixed once `cargo build --artifact-dir`
+# stabilizes. See https://github.com/rust-lang/cargo/issues/6790 for that
+# effort.
+cargo_command = [
+  shell,
+  meson.current_source_dir() / 'cargo-meson.sh',
+  meson.project_source_root(),
+  meson.current_build_dir(),
+]
+if get_option('buildtype') == 'release'
+  cargo_command += '--release'
+endif
+
+libgit_rs = custom_target('git_rs',
+  input: libgit_rs_sources + [
+    meson.project_source_root() / 'Cargo.toml',
+  ],
+  output: 'libgit.a',
+  command: cargo_command,
+)
+libgit_dependencies += declare_dependency(link_with: libgit_rs)
+
+if get_option('tests')
+  test('rust', cargo,
+    args: [
+      'test',
+      '--manifest-path',
+      meson.project_source_root() / 'Cargo.toml',
+      '--target-dir',
+      meson.current_build_dir() / 'target',
+    ],
+    timeout: 0,
+    protocol: 'rust',
+  )
+endif

-- 
2.51.0.450.g87641ccf93.dirty

[PATCH v5 2/9] Makefile: reorder sources after includes

[Patrick Steinhardt]

In an upcoming change we'll make some of the sources compile
conditionally based on whether or not `WITH_RUST` is defined. To let
developers specify that flag in their "config.mak" we'll thus have to
reorder our sources so that they come after the include of that file.

Do so.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 Makefile | 176 +++++++++++++++++++++++++++++++--------------------------------
 1 file changed, 88 insertions(+), 88 deletions(-)

diff --git a/Makefile b/Makefile
index 555b7f4dc3..7e52625d75 100644
--- a/Makefile
+++ b/Makefile
@@ -919,6 +919,94 @@ LIB_FILE = libgit.a
 XDIFF_LIB = xdiff/lib.a
 REFTABLE_LIB = reftable/libreftable.a
 
+# xdiff and reftable libs may in turn depend on what is in libgit.a
+GITLIBS = common-main.o $(LIB_FILE) $(XDIFF_LIB) $(REFTABLE_LIB) $(LIB_FILE)
+EXTLIBS =
+
+GIT_USER_AGENT = git/$(GIT_VERSION)
+
+ifeq ($(wildcard sha1collisiondetection/lib/sha1.h),sha1collisiondetection/lib/sha1.h)
+DC_SHA1_SUBMODULE = auto
+endif
+
+# Set CFLAGS, LDFLAGS and other *FLAGS variables. These might be
+# tweaked by config.* below as well as the command-line, both of
+# which'll override these defaults.
+# Older versions of GCC may require adding "-std=gnu99" at the end.
+CFLAGS = -g -O2 -Wall
+LDFLAGS =
+CC_LD_DYNPATH = -Wl,-rpath,
+BASIC_CFLAGS = -I.
+BASIC_LDFLAGS =
+
+# library flags
+ARFLAGS = rcs
+PTHREAD_CFLAGS =
+
+# For the 'sparse' target
+SPARSE_FLAGS ?= -std=gnu99 -D__STDC_NO_VLA__
+SP_EXTRA_FLAGS =
+
+# For informing GIT-BUILD-OPTIONS of the SANITIZE=leak,address targets
+SANITIZE_LEAK =
+SANITIZE_ADDRESS =
+
+# For the 'coccicheck' target
+SPATCH_INCLUDE_FLAGS = --all-includes
+SPATCH_FLAGS =
+SPATCH_TEST_FLAGS =
+
+# If *.o files are present, have "coccicheck" depend on them, with
+# COMPUTE_HEADER_DEPENDENCIES this will speed up the common-case of
+# only needing to re-generate coccicheck results for the users of a
+# given API if it's changed, and not all files in the project. If
+# COMPUTE_HEADER_DEPENDENCIES=no this will be unset too.
+SPATCH_USE_O_DEPENDENCIES = YesPlease
+
+# Set SPATCH_CONCAT_COCCI to concatenate the contrib/cocci/*.cocci
+# files into a single contrib/cocci/ALL.cocci before running
+# "coccicheck".
+#
+# Pros:
+#
+# - Speeds up a one-shot run of "make coccicheck", as we won't have to
+#   parse *.[ch] files N times for the N *.cocci rules
+#
+# Cons:
+#
+# - Will make incremental development of *.cocci slower, as
+#   e.g. changing strbuf.cocci will re-run all *.cocci.
+#
+# - Makes error and performance analysis harder, as rules will be
+#   applied from a monolithic ALL.cocci, rather than
+#   e.g. strbuf.cocci. To work around this either undefine this, or
+#   generate a specific patch, e.g. this will always use strbuf.cocci,
+#   not ALL.cocci:
+#
+#	make contrib/coccinelle/strbuf.cocci.patch
+SPATCH_CONCAT_COCCI = YesPlease
+
+# Rebuild 'coccicheck' if $(SPATCH), its flags etc. change
+TRACK_SPATCH_DEFINES =
+TRACK_SPATCH_DEFINES += $(SPATCH)
+TRACK_SPATCH_DEFINES += $(SPATCH_INCLUDE_FLAGS)
+TRACK_SPATCH_DEFINES += $(SPATCH_FLAGS)
+TRACK_SPATCH_DEFINES += $(SPATCH_TEST_FLAGS)
+GIT-SPATCH-DEFINES: FORCE
+	@FLAGS='$(TRACK_SPATCH_DEFINES)'; \
+	    if test x"$$FLAGS" != x"`cat GIT-SPATCH-DEFINES 2>/dev/null`" ; then \
+		echo >&2 "    * new spatch flags"; \
+		echo "$$FLAGS" >GIT-SPATCH-DEFINES; \
+            fi
+
+include config.mak.uname
+-include config.mak.autogen
+-include config.mak
+
+ifdef DEVELOPER
+include config.mak.dev
+endif
+
 GENERATED_H += command-list.h
 GENERATED_H += config-list.h
 GENERATED_H += hook-list.h
@@ -1387,94 +1475,6 @@ CLAR_TEST_OBJS += $(UNIT_TEST_DIR)/unit-test.o
 
 UNIT_TEST_OBJS += $(UNIT_TEST_DIR)/test-lib.o
 
-# xdiff and reftable libs may in turn depend on what is in libgit.a
-GITLIBS = common-main.o $(LIB_FILE) $(XDIFF_LIB) $(REFTABLE_LIB) $(LIB_FILE)
-EXTLIBS =
-
-GIT_USER_AGENT = git/$(GIT_VERSION)
-
-ifeq ($(wildcard sha1collisiondetection/lib/sha1.h),sha1collisiondetection/lib/sha1.h)
-DC_SHA1_SUBMODULE = auto
-endif
-
-# Set CFLAGS, LDFLAGS and other *FLAGS variables. These might be
-# tweaked by config.* below as well as the command-line, both of
-# which'll override these defaults.
-# Older versions of GCC may require adding "-std=gnu99" at the end.
-CFLAGS = -g -O2 -Wall
-LDFLAGS =
-CC_LD_DYNPATH = -Wl,-rpath,
-BASIC_CFLAGS = -I.
-BASIC_LDFLAGS =
-
-# library flags
-ARFLAGS = rcs
-PTHREAD_CFLAGS =
-
-# For the 'sparse' target
-SPARSE_FLAGS ?= -std=gnu99 -D__STDC_NO_VLA__
-SP_EXTRA_FLAGS =
-
-# For informing GIT-BUILD-OPTIONS of the SANITIZE=leak,address targets
-SANITIZE_LEAK =
-SANITIZE_ADDRESS =
-
-# For the 'coccicheck' target
-SPATCH_INCLUDE_FLAGS = --all-includes
-SPATCH_FLAGS =
-SPATCH_TEST_FLAGS =
-
-# If *.o files are present, have "coccicheck" depend on them, with
-# COMPUTE_HEADER_DEPENDENCIES this will speed up the common-case of
-# only needing to re-generate coccicheck results for the users of a
-# given API if it's changed, and not all files in the project. If
-# COMPUTE_HEADER_DEPENDENCIES=no this will be unset too.
-SPATCH_USE_O_DEPENDENCIES = YesPlease
-
-# Set SPATCH_CONCAT_COCCI to concatenate the contrib/cocci/*.cocci
-# files into a single contrib/cocci/ALL.cocci before running
-# "coccicheck".
-#
-# Pros:
-#
-# - Speeds up a one-shot run of "make coccicheck", as we won't have to
-#   parse *.[ch] files N times for the N *.cocci rules
-#
-# Cons:
-#
-# - Will make incremental development of *.cocci slower, as
-#   e.g. changing strbuf.cocci will re-run all *.cocci.
-#
-# - Makes error and performance analysis harder, as rules will be
-#   applied from a monolithic ALL.cocci, rather than
-#   e.g. strbuf.cocci. To work around this either undefine this, or
-#   generate a specific patch, e.g. this will always use strbuf.cocci,
-#   not ALL.cocci:
-#
-#	make contrib/coccinelle/strbuf.cocci.patch
-SPATCH_CONCAT_COCCI = YesPlease
-
-# Rebuild 'coccicheck' if $(SPATCH), its flags etc. change
-TRACK_SPATCH_DEFINES =
-TRACK_SPATCH_DEFINES += $(SPATCH)
-TRACK_SPATCH_DEFINES += $(SPATCH_INCLUDE_FLAGS)
-TRACK_SPATCH_DEFINES += $(SPATCH_FLAGS)
-TRACK_SPATCH_DEFINES += $(SPATCH_TEST_FLAGS)
-GIT-SPATCH-DEFINES: FORCE
-	@FLAGS='$(TRACK_SPATCH_DEFINES)'; \
-	    if test x"$$FLAGS" != x"`cat GIT-SPATCH-DEFINES 2>/dev/null`" ; then \
-		echo >&2 "    * new spatch flags"; \
-		echo "$$FLAGS" >GIT-SPATCH-DEFINES; \
-            fi
-
-include config.mak.uname
--include config.mak.autogen
--include config.mak
-
-ifdef DEVELOPER
-include config.mak.dev
-endif
-
 GIT-VERSION-FILE: FORCE
 	@OLD=$$(cat $@ 2>/dev/null || :) && \
 	$(call version_gen,"$(shell pwd)",GIT-VERSION-FILE.in,$@) && \

-- 
2.51.0.450.g87641ccf93.dirty

[PATCH v5 3/9] Makefile: introduce infrastructure to build internal Rust library

[Patrick Steinhardt]

Introduce infrastructure to build the internal Rust library. This
mirrors the infrastructure we have added to Meson in the preceding
commit. Developers can enable the infrastructure by passing the new
`WITH_RUST` build toggle.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 .gitignore |  2 ++
 Makefile   | 37 +++++++++++++++++++++++++++++++++++++
 shared.mak |  1 +
 3 files changed, 40 insertions(+)

diff --git a/.gitignore b/.gitignore
index 1803023427..0833453cf6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,4 +1,6 @@
 /fuzz_corpora
+/target/
+/Cargo.lock
 /GIT-BUILD-DIR
 /GIT-BUILD-OPTIONS
 /GIT-CFLAGS
diff --git a/Makefile b/Makefile
index 7e52625d75..e8518198fc 100644
--- a/Makefile
+++ b/Makefile
@@ -483,6 +483,14 @@ include shared.mak
 # Define LIBPCREDIR=/foo/bar if your PCRE header and library files are
 # in /foo/bar/include and /foo/bar/lib directories.
 #
+# == Optional Rust support ==
+#
+# Define WITH_RUST if you want to include features and subsystems written in
+# Rust into Git. For now, Rust is still an optional feature of the build
+# process. With Git 3.0 though, Rust will always be enabled.
+#
+# Building Rust code requires Cargo.
+#
 # == SHA-1 and SHA-256 defines ==
 #
 # === SHA-1 backend ===
@@ -683,6 +691,7 @@ OBJECTS =
 OTHER_PROGRAMS =
 PROGRAM_OBJS =
 PROGRAMS =
+RUST_SOURCES =
 EXCLUDED_PROGRAMS =
 SCRIPT_PERL =
 SCRIPT_PYTHON =
@@ -918,6 +927,11 @@ TEST_SHELL_PATH = $(SHELL_PATH)
 LIB_FILE = libgit.a
 XDIFF_LIB = xdiff/lib.a
 REFTABLE_LIB = reftable/libreftable.a
+ifdef DEBUG
+RUST_LIB = target/debug/libgit.a
+else
+RUST_LIB = target/release/libgit.a
+endif
 
 # xdiff and reftable libs may in turn depend on what is in libgit.a
 GITLIBS = common-main.o $(LIB_FILE) $(XDIFF_LIB) $(REFTABLE_LIB) $(LIB_FILE)
@@ -943,6 +957,15 @@ BASIC_LDFLAGS =
 ARFLAGS = rcs
 PTHREAD_CFLAGS =
 
+# Rust flags
+CARGO_ARGS =
+ifndef V
+CARGO_ARGS += --quiet
+endif
+ifndef DEBUG
+CARGO_ARGS += --release
+endif
+
 # For the 'sparse' target
 SPARSE_FLAGS ?= -std=gnu99 -D__STDC_NO_VLA__
 SP_EXTRA_FLAGS =
@@ -1475,6 +1498,8 @@ CLAR_TEST_OBJS += $(UNIT_TEST_DIR)/unit-test.o
 
 UNIT_TEST_OBJS += $(UNIT_TEST_DIR)/test-lib.o
 
+RUST_SOURCES += src/lib.rs
+
 GIT-VERSION-FILE: FORCE
 	@OLD=$$(cat $@ 2>/dev/null || :) && \
 	$(call version_gen,"$(shell pwd)",GIT-VERSION-FILE.in,$@) && \
@@ -1504,6 +1529,11 @@ endif
 ALL_CFLAGS = $(DEVELOPER_CFLAGS) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_APPEND)
 ALL_LDFLAGS = $(LDFLAGS) $(LDFLAGS_APPEND)
 
+ifdef WITH_RUST
+BASIC_CFLAGS += -DWITH_RUST
+GITLIBS += $(RUST_LIB)
+endif
+
 ifdef SANITIZE
 SANITIZERS := $(foreach flag,$(subst $(comma),$(space),$(SANITIZE)),$(flag))
 BASIC_CFLAGS += -fsanitize=$(SANITIZE) -fno-sanitize-recover=$(SANITIZE)
@@ -2918,6 +2948,12 @@ scalar$X: scalar.o GIT-LDFLAGS $(GITLIBS)
 $(LIB_FILE): $(LIB_OBJS)
 	$(QUIET_AR)$(RM) $@ && $(AR) $(ARFLAGS) $@ $^
 
+$(RUST_LIB): Cargo.toml $(RUST_SOURCES)
+	$(QUIET_CARGO)cargo build $(CARGO_ARGS)
+
+.PHONY: rust
+rust: $(RUST_LIB)
+
 $(XDIFF_LIB): $(XDIFF_OBJS)
 	$(QUIET_AR)$(RM) $@ && $(AR) $(ARFLAGS) $@ $^
 
@@ -3768,6 +3804,7 @@ clean: profile-clean coverage-clean cocciclean
 	$(RM) $(FUZZ_PROGRAMS)
 	$(RM) $(SP_OBJ)
 	$(RM) $(HCC)
+	$(RM) -r Cargo.lock target/
 	$(RM) version-def.h
 	$(RM) -r $(dep_dirs) $(compdb_dir) compile_commands.json
 	$(RM) $(test_bindir_programs)
diff --git a/shared.mak b/shared.mak
index 5c7bc94785..0e7492076e 100644
--- a/shared.mak
+++ b/shared.mak
@@ -56,6 +56,7 @@ ifndef V
 	QUIET_MKDIR_P_PARENT  = @echo '   ' MKDIR -p $(@D);
 
 ## Used in "Makefile"
+	QUIET_CARGO    = @echo '   ' CARGO $@;
 	QUIET_CC       = @echo '   ' CC $@;
 	QUIET_AR       = @echo '   ' AR $@;
 	QUIET_LINK     = @echo '   ' LINK $@;

-- 
2.51.0.450.g87641ccf93.dirty

[PATCH v5 4/9] help: report on whether or not Rust is enabled

[Patrick Steinhardt]

We're about to introduce support for Rust into the core of Git, where
some (trivial) subsystems are converted to Rust. These subsystems will
also retain a C implementation though as Rust is not yet mandatory.
Consequently, it now becomes possible for a Git version to have bugs
that are specific to whether or not it is built with Rust support
overall.

Expose information about whether or not Git was built with Rust via our
build info. This means that both `git version --build-options`, but also
`git bugreport` will now expose that bit of information. Hopefully, this
should make it easier for us to discover any Rust-specific issues.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 help.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/help.c b/help.c
index bb20498cfd..5854dd4a7e 100644
--- a/help.c
+++ b/help.c
@@ -791,6 +791,12 @@ void get_version_info(struct strbuf *buf, int show_build_options)
 		strbuf_addf(buf, "shell-path: %s\n", SHELL_PATH);
 		/* NEEDSWORK: also save and output GIT-BUILD_OPTIONS? */
 
+#if defined WITH_RUST
+		strbuf_addstr(buf, "rust: enabled\n");
+#else
+		strbuf_addstr(buf, "rust: disabled\n");
+#endif
+
 		if (fsmonitor_ipc__is_supported())
 			strbuf_addstr(buf, "feature: fsmonitor--daemon\n");
 #if defined LIBCURL_VERSION

-- 
2.51.0.450.g87641ccf93.dirty

[PATCH v5 5/9] varint: use explicit width for integers

[Patrick Steinhardt]

The varint subsystem currently uses implcit widths for integers. On the
one hand we use `uintmax_t` for the actual value. On the other hand, we
use `int` for the length of the encoded varint.

Both of these have known maximum vaules, as we only support at most 16
bytes when encoding varints. Thus, we know that we won't ever exceed
`uint64_t` for the actual value and `uint8_t` for the prefix length.

Refactor the code to use explicit widths. Besides making the logic
platform-independent, it also makes our life a bit easier in the next
commit, where we reimplement "varint.c" in Rust.

Suggested-by: Ezekiel Newren <ezekielnewren@gmail.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 dir.c        | 18 ++++++++++--------
 read-cache.c |  6 ++++--
 varint.c     |  6 +++---
 varint.h     |  4 ++--
 4 files changed, 19 insertions(+), 15 deletions(-)

diff --git a/dir.c b/dir.c
index 71108ac79b7..0a67a99cb3d 100644
--- a/dir.c
+++ b/dir.c
@@ -3579,7 +3579,8 @@ static void write_one_dir(struct untracked_cache_dir *untracked,
 	struct stat_data stat_data;
 	struct strbuf *out = &wd->out;
 	unsigned char intbuf[16];
-	unsigned int intlen, value;
+	unsigned int value;
+	uint8_t intlen;
 	int i = wd->index++;
 
 	/*
@@ -3632,7 +3633,7 @@ void write_untracked_extension(struct strbuf *out, struct untracked_cache *untra
 	struct ondisk_untracked_cache *ouc;
 	struct write_data wd;
 	unsigned char varbuf[16];
-	int varint_len;
+	uint8_t varint_len;
 	const unsigned hashsz = the_hash_algo->rawsz;
 
 	CALLOC_ARRAY(ouc, 1);
@@ -3738,7 +3739,7 @@ static int read_one_dir(struct untracked_cache_dir **untracked_,
 	struct untracked_cache_dir ud, *untracked;
 	const unsigned char *data = rd->data, *end = rd->end;
 	const unsigned char *eos;
-	unsigned int value;
+	uint64_t value;
 	int i;
 
 	memset(&ud, 0, sizeof(ud));
@@ -3830,7 +3831,8 @@ struct untracked_cache *read_untracked_extension(const void *data, unsigned long
 	struct read_data rd;
 	const unsigned char *next = data, *end = (const unsigned char *)data + sz;
 	const char *ident;
-	int ident_len;
+	uint64_t ident_len;
+	uint64_t varint_len;
 	ssize_t len;
 	const char *exclude_per_dir;
 	const unsigned hashsz = the_hash_algo->rawsz;
@@ -3867,8 +3869,8 @@ struct untracked_cache *read_untracked_extension(const void *data, unsigned long
 	if (next >= end)
 		goto done2;
 
-	len = decode_varint(&next);
-	if (next > end || len == 0)
+	varint_len = decode_varint(&next);
+	if (next > end || varint_len == 0)
 		goto done2;
 
 	rd.valid      = ewah_new();
@@ -3877,9 +3879,9 @@ struct untracked_cache *read_untracked_extension(const void *data, unsigned long
 	rd.data	      = next;
 	rd.end	      = end;
 	rd.index      = 0;
-	ALLOC_ARRAY(rd.ucd, len);
+	ALLOC_ARRAY(rd.ucd, varint_len);
 
-	if (read_one_dir(&uc->root, &rd) || rd.index != len)
+	if (read_one_dir(&uc->root, &rd) || rd.index != varint_len)
 		goto done;
 
 	next = rd.data;
diff --git a/read-cache.c b/read-cache.c
index 06ad74db228..41b44148b1e 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1807,7 +1807,7 @@ static struct cache_entry *create_from_disk(struct mem_pool *ce_mem_pool,
 
 	if (expand_name_field) {
 		const unsigned char *cp = (const unsigned char *)name;
-		size_t strip_len, previous_len;
+		uint64_t strip_len, previous_len;
 
 		/* If we're at the beginning of a block, ignore the previous name */
 		strip_len = decode_varint(&cp);
@@ -2655,8 +2655,10 @@ static int ce_write_entry(struct hashfile *f, struct cache_entry *ce,
 		hashwrite(f, ce->name, len);
 		hashwrite(f, padding, align_padding_size(size, len));
 	} else {
-		int common, to_remove, prefix_size;
+		int common, to_remove;
+		uint8_t prefix_size;
 		unsigned char to_remove_vi[16];
+
 		for (common = 0;
 		     (common < previous_name->len &&
 		      ce->name[common] &&
diff --git a/varint.c b/varint.c
index 409c4977a1e..03cd54416b6 100644
--- a/varint.c
+++ b/varint.c
@@ -1,11 +1,11 @@
 #include "git-compat-util.h"
 #include "varint.h"
 
-uintmax_t decode_varint(const unsigned char **bufp)
+uint64_t decode_varint(const unsigned char **bufp)
 {
 	const unsigned char *buf = *bufp;
 	unsigned char c = *buf++;
-	uintmax_t val = c & 127;
+	uint64_t val = c & 127;
 	while (c & 128) {
 		val += 1;
 		if (!val || MSB(val, 7))
@@ -17,7 +17,7 @@ uintmax_t decode_varint(const unsigned char **bufp)
 	return val;
 }
 
-int encode_varint(uintmax_t value, unsigned char *buf)
+uint8_t encode_varint(uint64_t value, unsigned char *buf)
 {
 	unsigned char varint[16];
 	unsigned pos = sizeof(varint) - 1;
diff --git a/varint.h b/varint.h
index f78bb0ca528..eb401935bd2 100644
--- a/varint.h
+++ b/varint.h
@@ -1,7 +1,7 @@
 #ifndef VARINT_H
 #define VARINT_H
 
-int encode_varint(uintmax_t, unsigned char *);
-uintmax_t decode_varint(const unsigned char **);
+uint8_t encode_varint(uint64_t, unsigned char *);
+uint64_t decode_varint(const unsigned char **);
 
 #endif /* VARINT_H */

-- 
2.51.0.450.g87641ccf93.dirty

[PATCH v5 6/9] varint: reimplement as test balloon for Rust

[Patrick Steinhardt]

Implement a trivial test balloon for our Rust build infrastructure by
reimplementing the "varint.c" subsystem in Rust. This subsystem is
chosen because it is trivial to convert and because it doesn't have any
dependencies to other components of Git.

If support for Rust is enabled, we stop compiling "varint.c" and instead
compile and use "src/varint.rs".

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 Makefile        |  3 ++
 meson.build     |  5 +++-
 src/lib.rs      |  1 +
 src/meson.build |  1 +
 src/varint.rs   | 92 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 101 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index e8518198fcb..d7d6f6eefcb 100644
--- a/Makefile
+++ b/Makefile
@@ -1307,7 +1307,9 @@ LIB_OBJS += urlmatch.o
 LIB_OBJS += usage.o
 LIB_OBJS += userdiff.o
 LIB_OBJS += utf8.o
+ifndef WITH_RUST
 LIB_OBJS += varint.o
+endif
 LIB_OBJS += version.o
 LIB_OBJS += versioncmp.o
 LIB_OBJS += walker.o
@@ -1499,6 +1501,7 @@ CLAR_TEST_OBJS += $(UNIT_TEST_DIR)/unit-test.o
 UNIT_TEST_OBJS += $(UNIT_TEST_DIR)/test-lib.o
 
 RUST_SOURCES += src/lib.rs
+RUST_SOURCES += src/varint.rs
 
 GIT-VERSION-FILE: FORCE
 	@OLD=$$(cat $@ 2>/dev/null || :) && \
diff --git a/meson.build b/meson.build
index 234a9e9d6fd..37dfa286017 100644
--- a/meson.build
+++ b/meson.build
@@ -522,7 +522,6 @@ libgit_sources = [
   'usage.c',
   'userdiff.c',
   'utf8.c',
-  'varint.c',
   'version.c',
   'versioncmp.c',
   'walker.c',
@@ -1707,6 +1706,10 @@ rust_option = get_option('rust').disable_auto_if(not cargo.found())
 if rust_option.allowed()
   subdir('src')
   libgit_c_args += '-DWITH_RUST'
+else
+  libgit_sources += [
+    'varint.c',
+  ]
 endif
 
 libgit = declare_dependency(
diff --git a/src/lib.rs b/src/lib.rs
index e69de29bb2d..9da70d8b57d 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -0,0 +1 @@
+pub mod varint;
diff --git a/src/meson.build b/src/meson.build
index 734de0b4fa9..b19ef4c0b51 100644
--- a/src/meson.build
+++ b/src/meson.build
@@ -1,5 +1,6 @@
 libgit_rs_sources = [
   'lib.rs',
+  'varint.rs',
 ]
 
 # Unfortunately we must use a wrapper command to move the output file into the
diff --git a/src/varint.rs b/src/varint.rs
new file mode 100644
index 00000000000..10c83e1f439
--- /dev/null
+++ b/src/varint.rs
@@ -0,0 +1,92 @@
+#[no_mangle]
+pub unsafe extern "C" fn decode_varint(bufp: *mut *const u8) -> usize {
+    let mut buf = *bufp;
+    let mut c = *buf;
+    let mut val = usize::from(c & 127);
+
+    buf = buf.add(1);
+
+    while (c & 128) != 0 {
+        val = val.wrapping_add(1);
+        if val == 0 || val.leading_zeros() < 7 {
+            return 0; // overflow
+        }
+
+        c = *buf;
+        buf = buf.add(1);
+
+        val = (val << 7) + usize::from(c & 127);
+    }
+
+    *bufp = buf;
+    val
+}
+
+#[no_mangle]
+pub unsafe extern "C" fn encode_varint(value: usize, buf: *mut u8) -> u8 {
+    let mut varint: [u8; 16] = [0; 16];
+    let mut pos = varint.len() - 1;
+
+    varint[pos] = (value & 127) as u8;
+
+    let mut value = value >> 7;
+    while value != 0 {
+        pos -= 1;
+        value -= 1;
+        varint[pos] = 128 | (value & 127) as u8;
+        value >>= 7;
+    }
+
+    if !buf.is_null() {
+        std::ptr::copy_nonoverlapping(varint.as_ptr().add(pos), buf, varint.len() - pos);
+    }
+
+    (varint.len() - pos) as u8
+}
+
+#[cfg(test)]
+mod tests {
+    use super::*;
+
+    #[test]
+    fn test_decode_varint() {
+        unsafe {
+            assert_eq!(decode_varint(&mut [0x00].as_slice().as_ptr()), 0);
+            assert_eq!(decode_varint(&mut [0x01].as_slice().as_ptr()), 1);
+            assert_eq!(decode_varint(&mut [0x7f].as_slice().as_ptr()), 127);
+            assert_eq!(decode_varint(&mut [0x80, 0x00].as_slice().as_ptr()), 128);
+            assert_eq!(decode_varint(&mut [0x80, 0x01].as_slice().as_ptr()), 129);
+            assert_eq!(decode_varint(&mut [0x80, 0x7f].as_slice().as_ptr()), 255);
+
+            // Overflows are expected to return 0.
+            assert_eq!(decode_varint(&mut [0x88; 16].as_slice().as_ptr()), 0);
+        }
+    }
+
+    #[test]
+    fn test_encode_varint() {
+        unsafe {
+            let mut varint: [u8; 16] = [0; 16];
+
+            assert_eq!(encode_varint(0, std::ptr::null_mut()), 1);
+
+            assert_eq!(encode_varint(0, varint.as_mut_slice().as_mut_ptr()), 1);
+            assert_eq!(varint, [0; 16]);
+
+            assert_eq!(encode_varint(10, varint.as_mut_slice().as_mut_ptr()), 1);
+            assert_eq!(varint, [10, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+
+            assert_eq!(encode_varint(127, varint.as_mut_slice().as_mut_ptr()), 1);
+            assert_eq!(varint, [127, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+
+            assert_eq!(encode_varint(128, varint.as_mut_slice().as_mut_ptr()), 2);
+            assert_eq!(varint, [128, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+
+            assert_eq!(encode_varint(129, varint.as_mut_slice().as_mut_ptr()), 2);
+            assert_eq!(varint, [128, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+
+            assert_eq!(encode_varint(255, varint.as_mut_slice().as_mut_ptr()), 2);
+            assert_eq!(varint, [128, 127, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+        }
+    }
+}

-- 
2.51.0.450.g87641ccf93.dirty

[PATCH v5 7/9] BreakingChanges: announce Rust becoming mandatory

[Patrick Steinhardt]

Over the last couple of years the appetite for bringing Rust into the
codebase has grown significantly across the developer base. Introducing
Rust is a major change though and has ramifications for the whole
ecosystem:

  - Some platforms have a Rust toolchain available, but have not yet
    integrated it into their build infrastructure.

  - Some platforms don't have any support for Rust at all.

  - Some platforms may have to figure out how to fit Rust into their
    bootstrapping sequence.

Due to this, and given that Git is a critical piece of infrastructure
for the whole industry, we cannot just introduce such a heavyweight
dependency without doing our due diligence.

Instead, preceding commits have introduced a test balloon into our build
infrastructure that convert one tiny subsystem to use Rust. For now,
using Rust to build that subsystem is entirely optional -- if no Rust
support is available, we continue to use the C implementation. This test
balloon has the intention to give distributions time and let them ease
into our adoption of Rust.

Having multiple implementations of the same subsystem is not sustainable
though, and the plan is to eventually be able to use Rust freely all
across our codebase. As such, there is the intent to make Rust become a
mandatory part of our build process.

Add an announcement to our breaking changes that Rust will become
mandatory in Git 3.0. A (very careful and non-binding) estimate might be
that this major release might be released in the second half of next
year, which should give distributors enough time to prepare for the
change.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 Documentation/BreakingChanges.adoc | 38 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/Documentation/BreakingChanges.adoc b/Documentation/BreakingChanges.adoc
index f8d2eba061..0512411030 100644
--- a/Documentation/BreakingChanges.adoc
+++ b/Documentation/BreakingChanges.adoc
@@ -165,6 +165,44 @@ A prerequisite for this change is that the ecosystem is ready to support the
 "reftable" format. Most importantly, alternative implementations of Git like
 JGit, libgit2 and Gitoxide need to support it.
 
+* Git will require Rust as a mandatory part of the build process. While Git
+  already started to adopt Rust in Git 2.52, all parts written in Rust are
+  optional for the time being. This includes:
++
+  ** Subsystems that have an alternative implementation in Rust to test
+     interoperability between our C and Rust codebase.
+  ** Newly written features that are not mission critical for a fully functional
+     Git client.
++
+These changes are meant as test balloons to allow distributors of Git to prepare
+for Rust becoming a mandatory part of the build process. There will be multiple
+milestones for the introduction of Rust:
++
+--
+1. Initially, with Git 2.52, support for Rust will be auto-detected by Meson and
+   disabled in our Makefile so that the project can sort out the initial
+   infrastructure.
+2. In Git 2.53, both build systems will default-enable support for Rust.
+   Consequently, builds will break by default if Rust is not available on the
+   build host. The use of Rust can still be explicitly disabled via build
+   flags.
+3. In Git 3.0, the build options will be removed and support for Rust is
+   mandatory.
+--
++
+You can explicitly ask both Meson and our Makefile-based system to enable Rust
+by saying `meson configure -Drust=enabled` and `make WITH_RUST=YesPlease`,
+respectively.
++
+The Git project will declare the last version before Git 3.0 to be a long-term
+support release. This long-term release will receive important bug fixes for at
+least four release cycles and security fixes for six release cycles. The Git
+project will hand over maintainership of the long-term release to distributors
+in case they need to extend the life of that long-term release even further. In
+that case, the backporting process will be handled by these distributors, but
+the backported patches will be reviewed on the mailing list and pulled in by the
+Git maintainer.
+
 === Removals
 
 * Support for grafting commits has long been superseded by git-replace(1).

-- 
2.51.0.450.g87641ccf93.dirty

Re: [PATCH v5 7/9] BreakingChanges: announce Rust becoming mandatory

[SZEDER Gábor]

On Mon, Sep 15, 2025 at 01:22:54PM +0200, Patrick Steinhardt wrote:
> Over the last couple of years the appetite for bringing Rust into the
> codebase has grown significantly across the developer base. Introducing
> Rust is a major change though and has ramifications for the whole
> ecosystem:
> 
>   - Some platforms have a Rust toolchain available, but have not yet
>     integrated it into their build infrastructure.
> 
>   - Some platforms don't have any support for Rust at all.
> 
>   - Some platforms may have to figure out how to fit Rust into their
>     bootstrapping sequence.
> 
> Due to this, and given that Git is a critical piece of infrastructure
> for the whole industry, we cannot just introduce such a heavyweight
> dependency without doing our due diligence.
> 
> Instead, preceding commits have introduced a test balloon into our build
> infrastructure that convert one tiny subsystem to use Rust. For now,
> using Rust to build that subsystem is entirely optional -- if no Rust
> support is available, we continue to use the C implementation. This test
> balloon has the intention to give distributions time and let them ease
> into our adoption of Rust.
> 
> Having multiple implementations of the same subsystem is not sustainable
> though, and the plan is to eventually be able to use Rust freely all
> across our codebase. As such, there is the intent to make Rust become a
> mandatory part of our build process.
> 
> Add an announcement to our breaking changes that Rust will become
> mandatory in Git 3.0. A (very careful and non-binding) estimate might be
> that this major release might be released in the second half of next
> year, which should give distributors enough time to prepare for the
> change.
> 
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
>  Documentation/BreakingChanges.adoc | 38 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 38 insertions(+)
> 
> diff --git a/Documentation/BreakingChanges.adoc b/Documentation/BreakingChanges.adoc
> index f8d2eba061..0512411030 100644
> --- a/Documentation/BreakingChanges.adoc
> +++ b/Documentation/BreakingChanges.adoc
> @@ -165,6 +165,44 @@ A prerequisite for this change is that the ecosystem is ready to support the
>  "reftable" format. Most importantly, alternative implementations of Git like
>  JGit, libgit2 and Gitoxide need to support it.
>  
> +* Git will require Rust as a mandatory part of the build process. While Git
> +  already started to adopt Rust in Git 2.52, all parts written in Rust are
> +  optional for the time being. This includes:
> ++
> +  ** Subsystems that have an alternative implementation in Rust to test
> +     interoperability between our C and Rust codebase.
> +  ** Newly written features that are not mission critical for a fully functional
> +     Git client.
> ++
> +These changes are meant as test balloons to allow distributors of Git to prepare
> +for Rust becoming a mandatory part of the build process. There will be multiple
> +milestones for the introduction of Rust:
> ++
> +--
> +1. Initially, with Git 2.52, support for Rust will be auto-detected by Meson and
> +   disabled in our Makefile so that the project can sort out the initial
> +   infrastructure.
> +2. In Git 2.53, both build systems will default-enable support for Rust.
> +   Consequently, builds will break by default if Rust is not available on the
> +   build host. The use of Rust can still be explicitly disabled via build
> +   flags.
> +3. In Git 3.0, the build options will be removed and support for Rust is
> +   mandatory.
> +--
> ++
> +You can explicitly ask both Meson and our Makefile-based system to enable Rust
> +by saying `meson configure -Drust=enabled` and `make WITH_RUST=YesPlease`,
> +respectively.
> ++
> +The Git project will declare the last version before Git 3.0 to be a long-term
> +support release. This long-term release will receive important bug fixes for at
> +least four release cycles and security fixes for six release cycles. The Git
> +project will hand over maintainership of the long-term release to distributors
> +in case they need to extend the life of that long-term release even further. In
> +that case, the backporting process will be handled by these distributors, but
> +the backported patches will be reviewed on the mailing list and pulled in by the
> +Git maintainer.

Providing an LTS release for those platforms that can't jump on the
Rust bandwagon is great, but...

Git 3.0 will switch the default hash algorithm for newly initialized
repositories to SHA-256, which, presumably, will also encourage SHA-1
-> SHA-256 migrations in existing repositories.  Alas, it appears that
the SHA-1/SHA-256 interop feature will only be available in Rust.

How will this affect those platforms without Rust?  What will and
won't work on such platforms?

I think it should be called out explicitly in the justification that
whatever limitations this imposes on those platforms with respect to
hash function transition, the project has duly considered that and is
OK with it.

Re: [PATCH v5 7/9] BreakingChanges: announce Rust becoming mandatory

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 3569 bytes --]

On 2025-09-17 at 22:09:10, SZEDER Gábor wrote:
> Providing an LTS release for those platforms that can't jump on the
> Rust bandwagon is great, but...
> 
> Git 3.0 will switch the default hash algorithm for newly initialized
> repositories to SHA-256, which, presumably, will also encourage SHA-1
> -> SHA-256 migrations in existing repositories.  Alas, it appears that
> the SHA-1/SHA-256 interop feature will only be available in Rust.
> 
> How will this affect those platforms without Rust?  What will and
> won't work on such platforms?

On Git 3.0, nothing will work without Rust because it will be mandatory.
However, people who want to perform the conversion can do that by
booting a Linux VM[0] and converting the repository there, then pushing
it somewhere.  The only inconvenience is that you'll have to have a flag
day for working with the repository on older Git: you won't be able to
dynamically pull from or push to a repository with a different main
algorithm than you.

One of my first patches is that setting extensions.compatObjectFormat
without Rust will simply die and say that's not supported.  If that
config value is unset, then Git up to 3.0 will simply function as
normal, so full single-hash compatibility is assured.  We already have
that: SHA-256 repositories work just fine with SHA-256 remotes and SHA-1
repositories work just fine with SHA-1 remotes, but they're currently
not interoperable.

> I think it should be called out explicitly in the justification that
> whatever limitations this imposes on those platforms with respect to
> hash function transition, the project has duly considered that and is
> OK with it.

I am fine with this and I don't think this is a problem.

I will mention that I have also already written the code in Rust and it
is elegant and tidy and more efficient, better tested, and shorter than
the equivalent C code.  Writing the code also took much less time than
the equivalent C code would have.  I am not planning to rewrite it in C,
since I already have a substantial amount of other interoperability work
to do, so unless someone else is planning on doing so, the project has
two choices: use the Rust code and accept that, or decide that they
don't want the interoperability work for Git 3.0.

I want to point out that so far, all of the SHA-256 work, including the
interoperability work, has been on my own time.  I understand that my
contributions to the project have to be acceptable to the project, but I
also am not willing to rewrite a bunch of work because we already
decided that we were going to do something and then changed our mind.
If the project wants to be fickle on this matter, then other
contributors can do the interoperability work on those terms.

I realize the decision to incorporate Rust was made recently, but the
binary loose object maps are a blocker for some of the protocol work I'm
doing, and if we want the interoperability functionality in Git 3.0 in a
year, then I can't afford to wait here, since this kind of discussion
tends to drag on extensively.

[0] Debian actually offers multiarch support, so as long as Debian has
support for the architecture you're running on, you can boot a Debian VM
of your native architecture, install amd64 or arm64 packages and QEMU,
and then run those binaries in emulation.  It will be slow, but it works
for virtually all architectures.  I've done something similar with
risc64 containers on my amd64 laptop.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [PATCH v5 7/9] BreakingChanges: announce Rust becoming mandatory

[SZEDER Gábor]

On Thu, Sep 18, 2025 at 01:19:19AM +0000, brian m. carlson wrote:
> On 2025-09-17 at 22:09:10, SZEDER Gábor wrote:
> > Providing an LTS release for those platforms that can't jump on the
> > Rust bandwagon is great, but...
> > 
> > Git 3.0 will switch the default hash algorithm for newly initialized
> > repositories to SHA-256, which, presumably, will also encourage SHA-1
> > -> SHA-256 migrations in existing repositories.  Alas, it appears that
> > the SHA-1/SHA-256 interop feature will only be available in Rust.
> > 
> > How will this affect those platforms without Rust?  What will and
> > won't work on such platforms?
> 
> On Git 3.0, nothing will work without Rust because it will be mandatory.

Well, "What will and won't work with respect to hash transition" was
what I meant but, alas, didn't convey.

> However, people who want to perform the conversion can do that by
> booting a Linux VM[0] and converting the repository there, then pushing
> it somewhere.  The only inconvenience is that you'll have to have a flag
> day for working with the repository on older Git: you won't be able to
> dynamically pull from or push to a repository with a different main
> algorithm than you.
> 
> One of my first patches is that setting extensions.compatObjectFormat
> without Rust will simply die and say that's not supported.  If that
> config value is unset, then Git up to 3.0 will simply function as
> normal, so full single-hash compatibility is assured.  We already have
> that: SHA-256 repositories work just fine with SHA-256 remotes and SHA-1
> repositories work just fine with SHA-1 remotes, but they're currently
> not interoperable.

Thanks for the explanation.  I think this would indeed be a worthwhile
addition to the commit message, or perhaps even to the BreakingChanges
document.

> > I think it should be called out explicitly in the justification that
> > whatever limitations this imposes on those platforms with respect to
> > hash function transition, the project has duly considered that and is
> > OK with it.
> 
> I am fine with this and I don't think this is a problem.

Not sure I can agree with that, though.


> I realize the decision to incorporate Rust was made recently,

Indeed it was.

Re: [PATCH v5 7/9] BreakingChanges: announce Rust becoming mandatory

[Junio C Hamano]

SZEDER Gábor <szeder.dev@gmail.com> writes:

> On Thu, Sep 18, 2025 at 01:19:19AM +0000, brian m. carlson wrote:
>> On 2025-09-17 at 22:09:10, SZEDER Gábor wrote:
>> > Providing an LTS release for those platforms that can't jump on the
>> > Rust bandwagon is great, but...
>> > 
>> > Git 3.0 will switch the default hash algorithm for newly initialized
>> > repositories to SHA-256, which, presumably, will also encourage SHA-1
>> > -> SHA-256 migrations in existing repositories.  Alas, it appears that
>> > the SHA-1/SHA-256 interop feature will only be available in Rust.
>> > 
>> > How will this affect those platforms without Rust?  What will and
>> > won't work on such platforms?
>> 
>> On Git 3.0, nothing will work without Rust because it will be mandatory.
>
> Well, "What will and won't work with respect to hash transition" was
> what I meant but, alas, didn't convey.

But "here is a topic to consolidate everything we talked about
starting to use Rust" Ezekiel works on incorporates the "dip our
toes in water rewrite of varint.c into Rust" Patrick started and
"Rust will become mandatory" policy document written by brian [*].
At 3.0, the WITH_BREAKING_CHANGES conditional compilation option is
removed and the conditional code paths protected by that macro
becomes unconditional.  When that happens, you won't have a git
binary from the source for that version of Git at all, unless you
can turn varint.rs into varint.o (which typically is done by
compiling the source with Rust toolchain).

So I would think "nothing will work" is a very fair assessment of
the consequence of that policy.  And the answer would be the same
for "with respect to hash transition" question, I would think.

The version of the document in this thread talks about 2.52 (opt-in)
and 2.53 (opt-out) before jumping to 3.0 (no way to opt-out) but it
does not say anything about how far out that big version bump is.
But the numbers I remember hearing was in the orders of 18 monts or
so if I am not mistaken?

As I already said a few times (e.g. <xmqq8qipzhg3.fsf@gitster.g>), I
feel that the timeline hinted by any of these documents that were
proposed is way too aggressive for affected people to practically
prepare for.

By the way, I was hoping that the hash compatibility work can be
done as an opt-in item available only for those with Rust, while
Rustless folks are forever stuck in a single hash algorithm world,
and be released well before Git 3.0 that makes Rust mandatory.  That
does not change the fact that nothing will work wrt hash transition
for Rustless folks, though ;-).


[Footnote]

* By the way, I _think_ I never saw that policy document until
  Ezekiel started his topic and sent it out as one of the component
  patches; how did it get there from brian to Ezekiel's topic?

Re: [PATCH v5 7/9] BreakingChanges: announce Rust becoming mandatory

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2949 bytes --]

On 2025-09-22 at 20:59:00, Junio C Hamano wrote:
> The version of the document in this thread talks about 2.52 (opt-in)
> and 2.53 (opt-out) before jumping to 3.0 (no way to opt-out) but it
> does not say anything about how far out that big version bump is.
> But the numbers I remember hearing was in the orders of 18 monts or
> so if I am not mistaken?

I think the plan was 4 release cycles, or about a year.  Git 3.0 was
going to replace 2.55.

> As I already said a few times (e.g. <xmqq8qipzhg3.fsf@gitster.g>), I
> feel that the timeline hinted by any of these documents that were
> proposed is way too aggressive for affected people to practically
> prepare for.

I don't think it's substantially more aggressive than the
interoperability code.  Both are aggressive timelines, but getting LLVM
ported to some of the affected targets isn't out of the question
(especially since older versions of it supported some of those targets)
and once that's done, I'm pretty sure Rust upstream would be on board
with supporting those systems.

> By the way, I was hoping that the hash compatibility work can be
> done as an opt-in item available only for those with Rust, while
> Rustless folks are forever stuck in a single hash algorithm world,
> and be released well before Git 3.0 that makes Rust mandatory.  That
> does not change the fact that nothing will work wrt hash transition
> for Rustless folks, though ;-).

I would love to have the interoperability work in sooner, but I don't
think it's realistic.  I have about 100 patches and I expect a total of
200 to 400 for the entire work.  That means someone has to send in 50 to
100 patches every one of the four release cycles before 3.0 and get
them sufficiently polished to get accepted, including any necessary
re-rolls.  I don't think you actually want me to send all of those
patches for one cycle at once, either.

Even with time to work on it at work, that's a lot of time and effort
for one person, and I also have personal responsibilities to family and
friends (someone has to cook dinner, for instance).  We'll see if
additional assistance is forthcoming, in which case timelines could
possibly be more aggressive.

Otherwise, if we want Git 3.0 to contain the interoperability work and
are unwilling to ship without it, then we may have a longer timeframe
for Git 3.0, and it may be more like replacing Git 2.57 or 2.58 instead.

> [Footnote]
> 
> * By the way, I _think_ I never saw that policy document until
>   Ezekiel started his topic and sent it out as one of the component
>   patches; how did it get there from brian to Ezekiel's topic?

I had it in a branch of mine that I was going to submit at some point
and I mentioned it to Ezekiel, who modified it and incorporated it.  The
original branch should be `rust` on my remote for those who are
interested.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [PATCH v5 7/9] BreakingChanges: announce Rust becoming mandatory

[Junio C Hamano]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:


>> As I already said a few times (e.g. <xmqq8qipzhg3.fsf@gitster.g>), I
>> feel that the timeline hinted by any of these documents that were
>> proposed is way too aggressive for affected people to practically
>> prepare for.
>
> I don't think it's substantially more aggressive than the
> interoperability code.  Both are aggressive timelines, but getting LLVM
> ported to some of the affected targets isn't out of the question
> (especially since older versions of it supported some of those targets)
> and once that's done, I'm pretty sure Rust upstream would be on board
> with supporting those systems.

Our timeline being agressive to cause more intense work on our
people is one thing.  It does not make much sense to me to compare
it with the timeline being aggressive to others who do not control
our timeline.

Putting it in another way, I'd call it hopelessly optimistic to
expect that those currently without Rust can somehow come up with a
plan to help their vendors (or they may be vendors themselves, then
convince their management) prepare their platforms to support Rust
within 18 months.  And giving them ultimatum based on the optimism
was never my favorite part of this whole thing.


>> [Footnote]
>> 
>> * By the way, I _think_ I never saw that policy document until
>>   Ezekiel started his topic and sent it out as one of the component
>>   patches; how did it get there from brian to Ezekiel's topic?
>
> I had it in a branch of mine that I was going to submit at some point
> and I mentioned it to Ezekiel, who modified it and incorporated it.  The
> original branch should be `rust` on my remote for those who are
> interested.

I figured that something like that happened.  I was mostly
interested in how firm those original authors supported the version
with Ezekiel's changes, as outsides would not be able to telll how
extensive the change were.

Thanks.

Re: [PATCH v5 7/9] BreakingChanges: announce Rust becoming mandatory

[Elijah Newren]

On Mon, Sep 22, 2025 at 3:56 PM Junio C Hamano <gitster@pobox.com> wrote:
> >> [Footnote]
> >>
> >> * By the way, I _think_ I never saw that policy document until
> >>   Ezekiel started his topic and sent it out as one of the component
> >>   patches; how did it get there from brian to Ezekiel's topic?
> >
> > I had it in a branch of mine that I was going to submit at some point
> > and I mentioned it to Ezekiel, who modified it and incorporated it.  The
> > original branch should be `rust` on my remote for those who are
> > interested.
>
> I figured that something like that happened.  I was mostly
> interested in how firm those original authors supported the version
> with Ezekiel's changes, as outsides would not be able to telll how
> extensive the change were.
>
> Thanks.

Footnote 1 of https://lore.kernel.org/git/aHlwZPbiKnakMN75@fruit.crustytoothpaste.net/

Re: [PATCH v5 7/9] BreakingChanges: announce Rust becoming mandatory

[Patrick Steinhardt]

On Mon, Sep 22, 2025 at 03:56:42PM -0700, Junio C Hamano wrote:
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> >> As I already said a few times (e.g. <xmqq8qipzhg3.fsf@gitster.g>), I
> >> feel that the timeline hinted by any of these documents that were
> >> proposed is way too aggressive for affected people to practically
> >> prepare for.
> >
> > I don't think it's substantially more aggressive than the
> > interoperability code.  Both are aggressive timelines, but getting LLVM
> > ported to some of the affected targets isn't out of the question
> > (especially since older versions of it supported some of those targets)
> > and once that's done, I'm pretty sure Rust upstream would be on board
> > with supporting those systems.
> 
> Our timeline being agressive to cause more intense work on our
> people is one thing.  It does not make much sense to me to compare
> it with the timeline being aggressive to others who do not control
> our timeline.
> 
> Putting it in another way, I'd call it hopelessly optimistic to
> expect that those currently without Rust can somehow come up with a
> plan to help their vendors (or they may be vendors themselves, then
> convince their management) prepare their platforms to support Rust
> within 18 months.  And giving them ultimatum based on the optimism
> was never my favorite part of this whole thing.

We have made other breaking changes conditional on the wider ecosystem.
For example, using reftable by default is conditioned on the ecosystem
having catched up and supporting this new format.

Do we maybe want to do the same with Rust? We can for example add
something like the following paragraph:

    We will carefully evaluate the impact on downstream distributions
    before making Rust mandatory in Git 3.0. If we see that the impact
    on downstream distributions would be significant, we may decide to
    defer this breaking change. This will also take into account our own
    learnings with how painful it is to keep Rust an optional component.

The intent would be to alert distributors, but not "blindly" pull the
trigger. Instead, we should take a step back and evaluate both how the
Rust ecosystem looks like at the Git 3.0 boundary and how painful it is
for us to keep it as an optional component.

Patrick

Re: [PATCH v5 7/9] BreakingChanges: announce Rust becoming mandatory

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

> We have made other breaking changes conditional on the wider ecosystem.
> For example, using reftable by default is conditioned on the ecosystem
> having catched up and supporting this new format.
>
> Do we maybe want to do the same with Rust? We can for example add
> something like the following paragraph:
>
>     We will carefully evaluate the impact on downstream distributions
>     before making Rust mandatory in Git 3.0. If we see that the impact
>     on downstream distributions would be significant, we may decide to
>     defer this breaking change. This will also take into account our own
>     learnings with how painful it is to keep Rust an optional component.
>
> The intent would be to alert distributors, but not "blindly" pull the
> trigger. Instead, we should take a step back and evaluate both how the
> Rust ecosystem looks like at the Git 3.0 boundary and how painful it is
> for us to keep it as an optional component.

I have always been assuming that we are prepared to change course if
that is necessary and though that something like that goes without
saying, but if you want to add it to the document, I am perfectly
fine.  It should apply not just Rust but all other entries we list.

Thanks.

Re: [PATCH v5 7/9] BreakingChanges: announce Rust becoming mandatory

[Ezekiel Newren]

On Mon, Sep 22, 2025 at 2:59 PM Junio C Hamano <gitster@pobox.com> wrote:
> * By the way, I _think_ I never saw that policy document until
>   Ezekiel started his topic and sent it out as one of the component
>   patches; how did it get there from brian to Ezekiel's topic?

You'll have to ask Elijah that. I was oblivious to it until Elijah
pointed it out to me, and now I've forgotten.

Re: [PATCH v5 7/9] BreakingChanges: announce Rust becoming mandatory

[Phillip Wood]

Hi Patrick

On 15/09/2025 12:22, Patrick Steinhardt wrote:
> Over the last couple of years the appetite for bringing Rust into the
> codebase has grown significantly across the developer base. Introducing
> Rust is a major change though and has ramifications for the whole
> ecosystem:
> 
>    - Some platforms have a Rust toolchain available, but have not yet
>      integrated it into their build infrastructure.
> 
>    - Some platforms don't have any support for Rust at all.
> 
>    - Some platforms may have to figure out how to fit Rust into their
>      bootstrapping sequence.
> 
> Due to this, and given that Git is a critical piece of infrastructure
> for the whole industry, we cannot just introduce such a heavyweight
> dependency without doing our due diligence.

I'm not sure what you mean by "doing our due diligence" here. We already 
know that requiring a rust compiler will make it impossible to build git 
on some currently supported platforms. Isn't the purpose of this patch 
to give them notice so they have some time to come up with a plan for 
either (a) accelerating rust support on their platform, or (b) for how 
maintain the LTS branch after the we stop supporting it?

> +1. Initially, with Git 2.52, support for Rust will be auto-detected by Meson and
> +   disabled in our Makefile so that the project can sort out the initial
> +   infrastructure.
> +2. In Git 2.53, both build systems will default-enable support for Rust.
> +   Consequently, builds will break by default if Rust is not available on the
> +   build host. The use of Rust can still be explicitly disabled via build
> +   flags.
> +3. In Git 3.0, the build options will be removed and support for Rust is
> +   mandatory.
> +--
> ++
> +You can explicitly ask both Meson and our Makefile-based system to enable Rust
> +by saying `meson configure -Drust=enabled` and `make WITH_RUST=YesPlease`,
> +respectively.

This is helpful but ideally before Git 2.53 we'd make the Makefile and 
meson print that information if they fail due to a missing rust compiler.

> ++
> +The Git project will declare the last version before Git 3.0 to be a long-term
> +support release. This long-term release will receive important bug fixes for at
> +least four release cycles and security fixes for six release cycles. The Git
> +project will hand over maintainership of the long-term release to distributors
> +in case they need to extend the life of that long-term release even further. In
> +that case, the backporting process will be handled by these distributors, but
> +the backported patches will be reviewed on the mailing list and pulled in by the
> +Git maintainer.

Didn't Junio have some qualms about the last part of this paragraph? I 
thought he suggested that once we hand over maintaining the LTS release 
the people responsible for it could use the security list to coordinate 
their work and would be responsible for pushing fixes the the LTS branch 
themselves.

Thanks for working on this, it will be good to have a formal plan in our 
Documentation that we can refer to.

Phillip

>   === Removals
>   
>   * Support for grafting commits has long been superseded by git-replace(1).
> 

Re: [PATCH v5 7/9] BreakingChanges: announce Rust becoming mandatory

[Patrick Steinhardt]

On Fri, Sep 19, 2025 at 02:59:58PM +0100, Phillip Wood wrote:
> On 15/09/2025 12:22, Patrick Steinhardt wrote:
> > Over the last couple of years the appetite for bringing Rust into the
> > codebase has grown significantly across the developer base. Introducing
> > Rust is a major change though and has ramifications for the whole
> > ecosystem:
> > 
> >    - Some platforms have a Rust toolchain available, but have not yet
> >      integrated it into their build infrastructure.
> > 
> >    - Some platforms don't have any support for Rust at all.
> > 
> >    - Some platforms may have to figure out how to fit Rust into their
> >      bootstrapping sequence.
> > 
> > Due to this, and given that Git is a critical piece of infrastructure
> > for the whole industry, we cannot just introduce such a heavyweight
> > dependency without doing our due diligence.
> 
> I'm not sure what you mean by "doing our due diligence" here. We already
> know that requiring a rust compiler will make it impossible to build git on
> some currently supported platforms. Isn't the purpose of this patch to give
> them notice so they have some time to come up with a plan for either (a)
> accelerating rust support on their platform, or (b) for how maintain the LTS
> branch after the we stop supporting it?

Yeah, I consider having an announcement of our intent out there as being
that "due diligence". The scope of breakage may be much bigger than we
currently anticipate, and if we eventually see that a significant
portion of the ecosystem would break I think we should take a step back
and reevaluate.

> > +1. Initially, with Git 2.52, support for Rust will be auto-detected by Meson and
> > +   disabled in our Makefile so that the project can sort out the initial
> > +   infrastructure.
> > +2. In Git 2.53, both build systems will default-enable support for Rust.
> > +   Consequently, builds will break by default if Rust is not available on the
> > +   build host. The use of Rust can still be explicitly disabled via build
> > +   flags.
> > +3. In Git 3.0, the build options will be removed and support for Rust is
> > +   mandatory.
> > +--
> > ++
> > +You can explicitly ask both Meson and our Makefile-based system to enable Rust
> > +by saying `meson configure -Drust=enabled` and `make WITH_RUST=YesPlease`,
> > +respectively.
> 
> This is helpful but ideally before Git 2.53 we'd make the Makefile and meson
> print that information if they fail due to a missing rust compiler.

The intent here is to allow us a bit of time to iterate on the build
infra before making either of the build systems error out. Ezekiel has a
bunch of follow-ups that we'll want to land to also unblock support on
Windows and to implement things we don't yet have, like Rust-accessible
C bindings.

Is there any particular reason why you want to accelerate this timeline
and make the build systems error out right from the start?

> > +The Git project will declare the last version before Git 3.0 to be a long-term
> > +support release. This long-term release will receive important bug fixes for at
> > +least four release cycles and security fixes for six release cycles. The Git
> > +project will hand over maintainership of the long-term release to distributors
> > +in case they need to extend the life of that long-term release even further. In
> > +that case, the backporting process will be handled by these distributors, but
> > +the backported patches will be reviewed on the mailing list and pulled in by the
> > +Git maintainer.
> 
> Didn't Junio have some qualms about the last part of this paragraph? I
> thought he suggested that once we hand over maintaining the LTS release the
> people responsible for it could use the security list to coordinate their
> work and would be responsible for pushing fixes the the LTS branch
> themselves.
> 
> Thanks for working on this, it will be good to have a formal plan in our
> Documentation that we can refer to.

Yeah, I addressed that feedback in [1]. Junio didn't reply to that part
yet, and I didn't have any idea for how to improve that part. I'm happy
to do so though if this still feels problematic to anyone.

Patrick

[1]: <aMfwGHL7dh8dk2cQ@pks.im>

Re: [PATCH v5 7/9] BreakingChanges: announce Rust becoming mandatory

[Phillip Wood]

Hi Patrick

On 22/09/2025 14:01, Patrick Steinhardt wrote:
> On Fri, Sep 19, 2025 at 02:59:58PM +0100, Phillip Wood wrote:
>> On 15/09/2025 12:22, Patrick Steinhardt wrote:
>>> 
>>> +You can explicitly ask both Meson and our Makefile-based system to enable Rust
>>> +by saying `meson configure -Drust=enabled` and `make WITH_RUST=YesPlease`,
>>> +respectively.
>>
>> This is helpful but ideally before Git 2.53 we'd make the Makefile and meson
>> print that information if they fail due to a missing rust compiler.
> 
> The intent here is to allow us a bit of time to iterate on the build
> infra before making either of the build systems error out. Ezekiel has a
> bunch of follow-ups that we'll want to land to also unblock support on
> Windows and to implement things we don't yet have, like Rust-accessible
> C bindings.
> 
> Is there any particular reason why you want to accelerate this timeline
> and make the build systems error out right from the start?

I'm not suggesting that. I'm saying when rust is enabled by default in 
Git 2.53, if the Makefile cannot find a rust compiler it should print a 
message that says how to build git without rust so that users do not 
have to wade through this document or our release notes to find out how 
to do that.

Thanks

Phillip

Re: [PATCH v5 7/9] BreakingChanges: announce Rust becoming mandatory

[Patrick Steinhardt]

On Mon, Sep 22, 2025 at 03:07:40PM +0100, Phillip Wood wrote:
> Hi Patrick
> 
> On 22/09/2025 14:01, Patrick Steinhardt wrote:
> > On Fri, Sep 19, 2025 at 02:59:58PM +0100, Phillip Wood wrote:
> > > On 15/09/2025 12:22, Patrick Steinhardt wrote:
> > > > 
> > > > +You can explicitly ask both Meson and our Makefile-based system to enable Rust
> > > > +by saying `meson configure -Drust=enabled` and `make WITH_RUST=YesPlease`,
> > > > +respectively.
> > > 
> > > This is helpful but ideally before Git 2.53 we'd make the Makefile and meson
> > > print that information if they fail due to a missing rust compiler.
> > 
> > The intent here is to allow us a bit of time to iterate on the build
> > infra before making either of the build systems error out. Ezekiel has a
> > bunch of follow-ups that we'll want to land to also unblock support on
> > Windows and to implement things we don't yet have, like Rust-accessible
> > C bindings.
> > 
> > Is there any particular reason why you want to accelerate this timeline
> > and make the build systems error out right from the start?
> 
> I'm not suggesting that. I'm saying when rust is enabled by default in Git
> 2.53, if the Makefile cannot find a rust compiler it should print a message
> that says how to build git without rust so that users do not have to wade
> through this document or our release notes to find out how to do that.

Ah, sorry, I misread what you were saying. This would be a useful thing
to do indeed.

Patrick

[PATCH v5 8/9] ci: convert "pedantic" job into full build with breaking changes

[Patrick Steinhardt]

The "pedantic" CI job is building on Fedora with `DEVOPTS=pedantic`.
This build flag doesn't do anything anymore starting with 6a8cbc41ba
(developer: enable pedantic by default, 2021-09-03), where we have
flipped the default so that developers have to opt-out of pedantic
builds via the "no-pedantic" option. As such, all this job really does
is to do a normal build on Fedora, which isn't all that interesting.

Convert that job into a full build-and-test job that uses Meson with
breaking changes enabled. This plugs two gaps:

  - We now test on another distro that we didn't run tests on
    beforehand.

  - We verify that breaking changes work as expected with Meson.

Furthermore, in a subsequent commit we'll modify both jobs that use
breaking changes to also enable Rust. By converting the Fedora job to
use Meson, we ensure that we test our Rust build infrastructure for both
build systems.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 .github/workflows/main.yml |  4 ++--
 .gitlab-ci.yml             |  4 ++--
 ci/install-dependencies.sh |  6 +++++-
 ci/run-build-and-tests.sh  | 29 ++++++++---------------------
 4 files changed, 17 insertions(+), 26 deletions(-)

diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index d122e79415..393ea4d1cc 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -379,6 +379,8 @@ jobs:
         - jobname: linux-breaking-changes
           cc: gcc
           image: ubuntu:rolling
+        - jobname: fedora-breaking-changes-meson
+          image: fedora:latest
         - jobname: linux-leaks
           image: ubuntu:rolling
           cc: gcc
@@ -396,8 +398,6 @@ jobs:
         # Supported until 2025-04-02.
         - jobname: linux32
           image: i386/ubuntu:focal
-        - jobname: pedantic
-          image: fedora:latest
         # A RHEL 8 compatible distro.  Supported until 2029-05-31.
         - jobname: almalinux-8
           image: almalinux:8
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index af10ebb59a..4248506909 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -45,6 +45,8 @@ test:linux:
       - jobname: linux-breaking-changes
         image: ubuntu:20.04
         CC: gcc
+      - jobname: fedora-breaking-changes-meson
+        image: fedora:latest
       - jobname: linux-TEST-vars
         image: ubuntu:20.04
         CC: gcc
@@ -58,8 +60,6 @@ test:linux:
       - jobname: linux-asan-ubsan
         image: ubuntu:rolling
         CC: clang
-      - jobname: pedantic
-        image: fedora:latest
       - jobname: linux-musl-meson
         image: alpine:latest
       - jobname: linux32
diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh
index d061a47293..35bd05b85b 100755
--- a/ci/install-dependencies.sh
+++ b/ci/install-dependencies.sh
@@ -30,8 +30,12 @@ alpine-*)
 		bash cvs gnupg perl-cgi perl-dbd-sqlite perl-io-tty >/dev/null
 	;;
 fedora-*|almalinux-*)
+	case "$jobname" in
+	*-meson)
+		MESON_DEPS="meson ninja";;
+	esac
 	dnf -yq update >/dev/null &&
-	dnf -yq install shadow-utils sudo make gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null
+	dnf -yq install shadow-utils sudo make pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel $MESON_DEPS >/dev/null
 	;;
 ubuntu-*|i386/ubuntu-*|debian-*)
 	# Required so that apt doesn't wait for user input on certain packages.
diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index 01823fd0f1..3680446649 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -5,12 +5,11 @@
 
 . ${0%/*}/lib.sh
 
-run_tests=t
-
 case "$jobname" in
-linux-breaking-changes)
+fedora-breaking-changes-musl|linux-breaking-changes)
 	export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
 	export WITH_BREAKING_CHANGES=YesPlease
+	MESONFLAGS="$MESONFLAGS -Dbreaking_changes=true"
 	;;
 linux-TEST-vars)
 	export OPENSSL_SHA1_UNSAFE=YesPlease
@@ -36,12 +35,6 @@ linux-sha256)
 linux-reftable|linux-reftable-leaks|osx-reftable)
 	export GIT_TEST_DEFAULT_REF_FORMAT=reftable
 	;;
-pedantic)
-	# Don't run the tests; we only care about whether Git can be
-	# built.
-	export DEVOPTS=pedantic
-	run_tests=
-	;;
 esac
 
 case "$jobname" in
@@ -54,21 +47,15 @@ case "$jobname" in
 		-Dtest_output_directory="${TEST_OUTPUT_DIRECTORY:-$(pwd)/t}" \
 		$MESONFLAGS
 	group "Build" meson compile -C build --
-	if test -n "$run_tests"
-	then
-		group "Run tests" meson test -C build --print-errorlogs --test-args="$GIT_TEST_OPTS" || (
-			./t/aggregate-results.sh "${TEST_OUTPUT_DIRECTORY:-t}/test-results"
-			handle_failed_tests
-		)
-	fi
+	group "Run tests" meson test -C build --print-errorlogs --test-args="$GIT_TEST_OPTS" || (
+		./t/aggregate-results.sh "${TEST_OUTPUT_DIRECTORY:-t}/test-results"
+		handle_failed_tests
+	)
 	;;
 *)
 	group Build make
-	if test -n "$run_tests"
-	then
-		group "Run tests" make test ||
-		handle_failed_tests
-	fi
+	group "Run tests" make test ||
+	handle_failed_tests
 	;;
 esac
 

-- 
2.51.0.450.g87641ccf93.dirty

[PATCH v5 9/9] ci: enable Rust for breaking-changes jobs

[Patrick Steinhardt]

Enable Rust for our breaking-changes jobs so that we can verify that the
build infrastructure and the converted Rust subsystems work as expected.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 ci/install-dependencies.sh | 4 ++--
 ci/run-build-and-tests.sh  | 2 ++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh
index 35bd05b85b..0d3aa496fc 100755
--- a/ci/install-dependencies.sh
+++ b/ci/install-dependencies.sh
@@ -35,7 +35,7 @@ fedora-*|almalinux-*)
 		MESON_DEPS="meson ninja";;
 	esac
 	dnf -yq update >/dev/null &&
-	dnf -yq install shadow-utils sudo make pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel $MESON_DEPS >/dev/null
+	dnf -yq install shadow-utils sudo make pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel $MESON_DEPS cargo >/dev/null
 	;;
 ubuntu-*|i386/ubuntu-*|debian-*)
 	# Required so that apt doesn't wait for user input on certain packages.
@@ -62,7 +62,7 @@ ubuntu-*|i386/ubuntu-*|debian-*)
 		make libssl-dev libcurl4-openssl-dev libexpat-dev wget sudo default-jre \
 		tcl tk gettext zlib1g-dev perl-modules liberror-perl libauthen-sasl-perl \
 		libemail-valid-perl libio-pty-perl libio-socket-ssl-perl libnet-smtp-ssl-perl libdbd-sqlite3-perl libcgi-pm-perl \
-		libsecret-1-dev libpcre2-dev meson ninja-build pkg-config \
+		libsecret-1-dev libpcre2-dev meson ninja-build pkg-config cargo \
 		${CC_PACKAGE:-${CC:-gcc}} $PYTHON_PACKAGE
 
 	case "$distro" in
diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index 3680446649..c718bd101a 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -9,7 +9,9 @@ case "$jobname" in
 fedora-breaking-changes-musl|linux-breaking-changes)
 	export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
 	export WITH_BREAKING_CHANGES=YesPlease
+	export WITH_RUST=YesPlease
 	MESONFLAGS="$MESONFLAGS -Dbreaking_changes=true"
+	MESONFLAGS="$MESONFLAGS -Drust=enabled"
 	;;
 linux-TEST-vars)
 	export OPENSSL_SHA1_UNSAFE=YesPlease

-- 
2.51.0.450.g87641ccf93.dirty

Re: [PATCH v5 0/9] Introduce Rust and announce that it will become mandatory

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

> Changes in v5:
>   - Fix indentation in the BreakingChanges document.
>   - Fix a commit message typo.
>   - Include "Cargo.lock" in the `make clean` target again.
>   - Link to v4: https://lore.kernel.org/r/20250910-b4-pks-rust-breaking-change-v4-0-4a63fc69278d@pks.im

It seems that we are converging with smaller and smaller changes
between iterations?  Will queue.

Thanks.

Re: [PATCH v5 0/9] Introduce Rust and announce that it will become mandatory

[Ezekiel Newren]

I am currently working on a patch series that makes Rust optional and
addresses several concerns that this series does not:
  * Rust calling C: Makefile has no way to build or run Rust so it
would have to call cargo test, but that doesn't work unless build.rs
tells cargo where libgit.a is (among other things).
  * Build tooling alignment: My build_rust.sh is called by make and
meson which eliminates defining how to build Rust in 2 places.
  * Cargo vs Meson: Meson is adding support for Rust and it's getting
better, but Cargo is the canonical build system for Rust. cargo is
released in lockstep with rustc, and we _have_ to use cargo when
building with make because Meson won't be available in that case.
  * Crates: Patrick's series assumes the Git codebase is _the_ crate
    * cbindgen: Cbindgen outputs a single header file for each crate,
with only 1 we'll have an unmanageably large auto generated header
file.
    * Modularity: Using multiple crates makes Git more modular. Elijah
told me that there was some desire to make Git more modular.
    * Cargo Dependencies: Patrick wrote his series with Meson first in
mind which doesn't address how we'll be able to use crates from
crates.io
  * CI:
    * Sparse coverage: I think there's only one target that tests his changes.
    * With vs Without Rust: I don't see anywhere that he covers
building with vs without Rust in CI
  * Build integration: Meson has to have every .rs file specified
where as the default layout of a Rust project allows Cargo to just
know where to look for .rs files

Re: [PATCH v5 0/9] Introduce Rust and announce that it will become mandatory

[Patrick Steinhardt]

On Mon, Sep 15, 2025 at 08:03:29PM -0600, Ezekiel Newren wrote:
> I am currently working on a patch series that makes Rust optional and
> addresses several concerns that this series does not:
>   * Rust calling C: Makefile has no way to build or run Rust so it
> would have to call cargo test, but that doesn't work unless build.rs
> tells cargo where libgit.a is (among other things).
>   * Build tooling alignment: My build_rust.sh is called by make and
> meson which eliminates defining how to build Rust in 2 places.
>   * Cargo vs Meson: Meson is adding support for Rust and it's getting
> better, but Cargo is the canonical build system for Rust. cargo is
> released in lockstep with rustc, and we _have_ to use cargo when
> building with make because Meson won't be available in that case.
>   * Crates: Patrick's series assumes the Git codebase is _the_ crate
>     * cbindgen: Cbindgen outputs a single header file for each crate,
> with only 1 we'll have an unmanageably large auto generated header
> file.
>     * Modularity: Using multiple crates makes Git more modular. Elijah
> told me that there was some desire to make Git more modular.
>     * Cargo Dependencies: Patrick wrote his series with Meson first in
> mind which doesn't address how we'll be able to use crates from
> crates.io
>   * CI:
>     * Sparse coverage: I think there's only one target that tests his changes.
>     * With vs Without Rust: I don't see anywhere that he covers
> building with vs without Rust in CI
>   * Build integration: Meson has to have every .rs file specified
> where as the default layout of a Rust project allows Cargo to just
> know where to look for .rs files

Yeah, as I mentioned my patch series here really aims at getting an
minimum viable user of Rust into the Git codebase so that we can focus
the discussion more on the roadmap towards Rust rather than the actual
Rust infrastructure. The whole infra is very simplistic because of that,
but that is intentional for now.

Once we have agreed on the roadmap I very much expect that we will
iterate on it to allow for more complex use cases. My next step would
have been to pick patches from your series that make all of this work
on Windows. But of course I don't have to be the (only) one to iterate
on the initial simple infrasturcture, this should ideally be an effort
by the whole community.

And yes, many of the points you mention above are things we'll have to
address over time to make Rust a viable alternative to implement
anything more complex than the trivial "varint.c" thing. I think that
iteration is key here: let's start simple and then gradually build out
the infrastructure.

Patrick

Re: [PATCH v5 0/9] Introduce Rust and announce that it will become mandatory

[Sam James]

Patrick Steinhardt <ps@pks.im> writes:

> On Mon, Sep 15, 2025 at 08:03:29PM -0600, Ezekiel Newren wrote:
>> I am currently working on a patch series that makes Rust optional and
>> addresses several concerns that this series does not:
>>   * Rust calling C: Makefile has no way to build or run Rust so it
>> would have to call cargo test, but that doesn't work unless build.rs
>> tells cargo where libgit.a is (among other things).
>>   * Build tooling alignment: My build_rust.sh is called by make and
>> meson which eliminates defining how to build Rust in 2 places.
>>   * Cargo vs Meson: Meson is adding support for Rust and it's getting
>> better, but Cargo is the canonical build system for Rust. cargo is
>> released in lockstep with rustc, and we _have_ to use cargo when
>> building with make because Meson won't be available in that case.
>>   * Crates: Patrick's series assumes the Git codebase is _the_ crate
>>     * cbindgen: Cbindgen outputs a single header file for each crate,
>> with only 1 we'll have an unmanageably large auto generated header
>> file.
>>     * Modularity: Using multiple crates makes Git more modular. Elijah
>> told me that there was some desire to make Git more modular.
>>     * Cargo Dependencies: Patrick wrote his series with Meson first in
>> mind which doesn't address how we'll be able to use crates from
>> crates.io
>>   * CI:
>>     * Sparse coverage: I think there's only one target that tests his changes.
>>     * With vs Without Rust: I don't see anywhere that he covers
>> building with vs without Rust in CI
>>   * Build integration: Meson has to have every .rs file specified
>> where as the default layout of a Rust project allows Cargo to just
>> know where to look for .rs files
>
> Yeah, as I mentioned my patch series here really aims at getting an
> minimum viable user of Rust into the Git codebase so that we can focus
> the discussion more on the roadmap towards Rust rather than the actual
> Rust infrastructure. The whole infra is very simplistic because of that,
> but that is intentional for now.
>
> Once we have agreed on the roadmap I very much expect that we will
> iterate on it to allow for more complex use cases. My next step would
> have been to pick patches from your series that make all of this work
> on Windows. But of course I don't have to be the (only) one to iterate
> on the initial simple infrasturcture, this should ideally be an effort
> by the whole community.
>
> And yes, many of the points you mention above are things we'll have to
> address over time to make Rust a viable alternative to implement
> anything more complex than the trivial "varint.c" thing. I think that
> iteration is key here: let's start simple and then gradually build out
> the infrastructure.

I think adding external crates especially will need discussion given the
licencing and "offline" issues (which are solvable but they should be
examined).

>
> Patrick

Re: [PATCH v5 0/9] Introduce Rust and announce that it will become mandatory

[Ezekiel Newren]

On Wed, Sep 17, 2025 at 6:07 AM Sam James <sam@gentoo.org> wrote:
> I think adding external crates especially will need discussion given the
> licencing and "offline" issues (which are solvable but they should be
> examined).

I agree. My opinion is that creating a new crate in Git should be its
own commit. Same with adding a dependency to an existing crate in Git.
Just because it'll be easy to add depdendencies doesn't mean we should
add them willy nilly. But making them easy to add encourages trying
out tools to see if it's a good idea or not.

Re: [PATCH v5 0/9] Introduce Rust and announce that it will become mandatory

[Ramsay Jones]

On 16/09/2025 03:03, Ezekiel Newren wrote:
> I am currently working on a patch series that makes Rust optional and
> addresses several concerns that this series does not:
>   * Rust calling C: Makefile has no way to build or run Rust so it
> would have to call cargo test, but that doesn't work unless build.rs
> tells cargo where libgit.a is (among other things).
>   * Build tooling alignment: My build_rust.sh is called by make and

I meant to mention during the initial 'xdiff series' that running
the build_rust.sh script failed for me on Linux Mint 22.2, because:

  $ rustc --version
  rustc 1.75.0 (82e1608df 2023-12-21) (built from a source tarball)
  $ cargo --version
  cargo 1.75.0
  $ rustup --version
  Command 'rustup' not found, but can be installed with:
  sudo apt install rustup
  $ 

[if you try to install rustup, it offers to remove rustc and cargo!]

> meson which eliminates defining how to build Rust in 2 places.
>   * Cargo vs Meson: Meson is adding support for Rust and it's getting
> better, but Cargo is the canonical build system for Rust. cargo is
> released in lockstep with rustc, and we _have_ to use cargo when
> building with make because Meson won't be available in that case.
>   * Crates: Patrick's series assumes the Git codebase is _the_ crate
>     * cbindgen: Cbindgen outputs a single header file for each crate,

Also:

  $ cbindgen --version
  Command 'cbindgen' not found, but can be installed with:
  sudo apt install cbindgen
  $ 

[I haven't tried installing cbindgen, so I don't know if it would uninstall
rustc and cargo :) ]

ATB,
Ramsay Jones

Re: [PATCH v5 0/9] Introduce Rust and announce that it will become mandatory

[Ezekiel Newren]

On Tue, Sep 16, 2025 at 5:05 PM Ramsay Jones
<ramsay@ramsayjones.plus.com> wrote:
> I meant to mention during the initial 'xdiff series' that running
> the build_rust.sh script failed for me on Linux Mint 22.2, because:
>
>   $ rustc --version
>   rustc 1.75.0 (82e1608df 2023-12-21) (built from a source tarball)
>   $ cargo --version
>   cargo 1.75.0
>   $ rustup --version
>   Command 'rustup' not found, but can be installed with:
>   sudo apt install rustup
>   $
>
> [if you try to install rustup, it offers to remove rustc and cargo!]

The parts of my CI code that use rustup should not be interpreted as
the right or wrong way to acquire rustc + cargo. So long as the
distribution you're using has an appropriate rustc and cargo version
then it doesn't matter. The reason why I used rustup in the github
workflows is because rustup makes it easy to install different
toolchains. rustc and cargo are released in lockstep so it's confusing
when they're not both part of the same package in a distro.

> Also:
>
>   $ cbindgen --version
>   Command 'cbindgen' not found, but can be installed with:
>   sudo apt install cbindgen
>   $
>
> [I haven't tried installing cbindgen, so I don't know if it would uninstall
> rustc and cargo :) ]

Again this is confusing because cbindgen is a crate that can be
installed via 'cargo install cbindgen` and then run as `cbindgen`. I
think it would be worthwhile to go over some Rust terminology:
[rustc]: The rust compiler.
[cargo]: Canonical build system + package manager. Even rustc uses
cargo to build itself.
[rustup]: Rust toolchain manager. This provides rustc and cargo + other stuff.
[crate]: The unit of compilation. In C it's akin to a single library
file or executable. It follows the structure of
my_crate
├── Cargo.toml
└── src
    ├── do_that.rs
    ├── do_this.rs
    └── lib.rs
Where src/lib.rs (the entry point) means it's a library crate and
main.rs (the entry point) would mean it's an executable crate (though
you can define both in the same crate).

This means for each crate there will be lib<crate>.a and optionally
interop/<crate>.h. So places like xdiff and reftable would be easy to
fit into the concept of a crate. The rest of Git would take some doing
to organize into crates.

Re: [PATCH v5 0/9] Introduce Rust and announce that it will become mandatory

[Ramsay Jones]

On 17/09/2025 00:38, Ezekiel Newren wrote:
> On Tue, Sep 16, 2025 at 5:05 PM Ramsay Jones
> <ramsay@ramsayjones.plus.com> wrote:
>> I meant to mention during the initial 'xdiff series' that running
>> the build_rust.sh script failed for me on Linux Mint 22.2, because:
>>
>>   $ rustc --version
>>   rustc 1.75.0 (82e1608df 2023-12-21) (built from a source tarball)
>>   $ cargo --version
>>   cargo 1.75.0
>>   $ rustup --version
>>   Command 'rustup' not found, but can be installed with:
>>   sudo apt install rustup
>>   $
>>
>> [if you try to install rustup, it offers to remove rustc and cargo!]
> 
> The parts of my CI code that use rustup should not be interpreted as
> the right or wrong way to acquire rustc + cargo. So long as the
> distribution you're using has an appropriate rustc and cargo version
> then it doesn't matter. The reason why I used rustup in the github
> workflows is because rustup makes it easy to install different
> toolchains. rustc and cargo are released in lockstep so it's confusing
> when they're not both part of the same package in a distro.

Ah, sorry, I was not very clear. The 'build_rust.sh' script unconditionally
uses the rustup command, assuming that every developer has it installed, but
not all devs _will_ have it installed (relying on their distro's packages for
rustc and cargo).

If memory serves (and it may not), rustup was only used to determine if the
current platform was windows (so that it could set the library file extension
to '*.a' or '*.lib'). It should not be too difficult to find some other means
to determine that. (famous last words!)

> 
>> Also:
>>
>>   $ cbindgen --version
>>   Command 'cbindgen' not found, but can be installed with:
>>   sudo apt install cbindgen
>>   $
>>
>> [I haven't tried installing cbindgen, so I don't know if it would uninstall
>> rustc and cargo :) ]
> 
> Again this is confusing because cbindgen is a crate that can be
> installed via 'cargo install cbindgen` and then run as `cbindgen`. I
> think it would be worthwhile to go over some Rust terminology:

So, is the (I guess debian) cbindgen package an executable or a crate?
(can you execute a crate?). BTW the package version is 0.26.0-3.


ATB,
Ramsay Jones

Re: [PATCH v5 0/9] Introduce Rust and announce that it will become mandatory

[Elijah Newren]

Hi Patrick,

On Mon, Sep 15, 2025 at 4:23 AM Patrick Steinhardt <ps@pks.im> wrote:
>
> Hi,
>
> this small patch series introduces Rust into the core of Git. This patch
> series is designed as a test balloon, similar to how we introduced test
> balloons for C99 features in the past. The goal is threefold:
>
>   - Give us some time to experiment with Rust and introduce proper build
>     infrastructure.
>
>   - Give distributors time to ease into the new toolchain requirements.
>     Introducing Rust is impossible for some platforms and hard for
>     others.
>
>   - Announce that Git 3.0 will make Rust a mandatory part of our build
>     infrastructure.
>
> The test balloon itself is quite uninteresting: I've chosen to convert
> the "varint.c" subsystem, mostly because it is trivial and does not have
> any dependencies. But it does allow us to verify that C to Rust interop
> works as expected, and to play around with tooling. All tests pass with
> the "varint.rs" implementation.
>
> For now, the series only contains support for Meson. If we agree to go
> down this route I'll also introduce support for Rust into our Makefiles
> at a later point in time.
>
> Furthermore missing is additional tooling:
>
>   - At least one CI job to verify that Rust builds and works as
>     expected.
>
>   - Tooling and CI jobs to ensure that we have consistent formatting via
>     `cargo format`.
>
> And probably lots more. As said, the entire goal is for us to have an
> easy playground that we can experiment on and develop the infrastructure
> incrementally without yet having to commit to anything.
>
> I'm mostly splitting out the topic of introducing Rust from the larger
> series that introduce it into xdiff so that we can focus more on the
> actual process of introducing Rust into Git and less on the potential
> features that we want to build on top of it.
>
> Changes in v2:
>   - Introduce support for building the Rust library via our Makefile.
>   - Introduce a '-DWITH_RUST' define. This define is used to print
>     whether or not Git is built with Rust via `git version
>     --build-options`.
>   - Adjust Meson to not depend on v1.9.0 and newer anymore.
>   - Introduce a roadmap into our BreakingChanges document to explain how
>     we'll iterate towards mandatory Rust support.
>   - Rework the Fedora job to do a full compile-and-test run with Meson
>     and breaking changes enabled.
>   - Adapt our breaking-changes jobs to enable Rust support.
>   - Link to v1: https://lore.kernel.org/r/20250904-b4-pks-rust-breaking-change-v1-0-3af1d25e0be9@pks.im
>
> Changes in v3:
>   - Reorder all uses of `WITH_RUST` after the include of "config.mak".
>   - Add a test to verify overflow behaviour in Rust and explicitly use
>     `add_wrapping()`.
>   - Use explicit dependencies for the Rust library in our Makefile.
>   - Fix Alma Linux CI job.
>   - Stop tying maintenance of our LTS release to the availability of
>     gcc-rs.
>   - Add a fallback to Meson to use cargo directly.
>   - I've fixed the Rust edition to 2018 for now. This is intentionally
>     conservative so that we might be able to use Rust 1.49. For now, we
>     don't have any reason to use a newer edition, either. So let's take
>     the oldest version we can live with for now and then bump it as
>     required.
>   - Link to v2: https://lore.kernel.org/r/20250905-b4-pks-rust-breaking-change-v2-0-6939cbf4a0b8@pks.im
>
> Changes in v4:
>   - Convert "varint.c" to use explicit integer width so that we don't
>     need to use C types in Rust.
>   - Adapt Meson to unconditionally use Cargo.
>   - Don't use the unstable `--out-dir` option in Cargo. Instead, we
>     resort to a wrapper script in Meson.
>   - Shorten the timeline a bit to drop the extra step that ties Rust
>     support to `-Dbreaking_changes=true`. This accelerates the timeline
>     until distros are made forcibly aware of the upcoming changes in
>     Rust.
>   - Link to v3: https://lore.kernel.org/r/20250908-b4-pks-rust-breaking-change-v3-0-1cd7189fed3b@pks.im
>
> Changes in v5:
>   - Fix indentation in the BreakingChanges document.
>   - Fix a commit message typo.
>   - Include "Cargo.lock" in the `make clean` target again.
>   - Link to v4: https://lore.kernel.org/r/20250910-b4-pks-rust-breaking-change-v4-0-4a63fc69278d@pks.im

Patch 7 still has the same error as v2; could we get the wording
corrected?  I suggested an alternative already[*]:

"...While Git already started to adopt Rust in Git 2.52, all parts..."

=>

"...While Git already started to adopt Rust into the core in Git 2.52
(and as an optional "contrib" component back in Git 2.49), all
parts..."


Also, as discussed over at
https://lore.kernel.org/git/xmqqy0qcae6z.fsf@gitster.g/, would you be
willing to re-roll a single-patch v6 (with just your updated patch 7),
and let Junio merge that?  That would get the important timeline that
you wanted landed, and then Ezekiel could pull your varint and help
changes together with brian's Documentation change and Johannes'
git-for-windows change to create a test balloon and introduce Rust and
have it build on all CI'd platforms.

Thanks,
Elijah

what's missing from newer C? [was: [PATCH v5 0/9] Introduce Rust ....]

[Eric Wong]

Patrick Steinhardt <ps@pks.im> wrote:
> this small patch series introduces Rust into the core of Git. This patch
> series is designed as a test balloon, similar to how we introduced test
> balloons for C99 features in the past. The goal is threefold:

>   - Give distributors time to ease into the new toolchain requirements.
>     Introducing Rust is impossible for some platforms and hard for
>     others.
> 
>   - Announce that Git 3.0 will make Rust a mandatory part of our build
>     infrastructure.

Newer (and perhaps experimental) C has some safety and ergonomic
features which Rust advocates might be overlooking:

1. C23 has stdckdint.h for checked arithmetic to prevent overflows

2. __counted_by__ attribute in clang 18 and gcc 15 for
   guarding against buffer overflows:
   https://people.kernel.org/gustavoars/how-to-use-the-new-counted_by-attribute-in-c-and-linux
   It's easy to fall back to disabling it for unsupported compilers.

3. __cleanup__ attribute is supported by TinyCC, gcc, and clang
   for many years (even decades), now.  Auto cleanup makes managing
   locks for parallelism much easier along with normal resource
   management ergonomic improvement.  __cleanup__ should be trivial
   for other compiler maintainers to add (even TinyCC supports it)

4. Userspace RCU provides concurrent data structures even w/o
   RCU (and AFAIK ConcurrencyKit, too, but I've never used CK)

5. compilers check format strings nowadays (but I dislike format
   strings for performance reasons unless using qrintf)

6. regexps (POSIX ERE or PCRE2) are already used by git and can
   be used more extensively to make safer parsers.  There's also
   things like wuffs and re2c to generate C (I've yet to try
   either).

We also have Valgrind, ASAN, TSAN, etc...

__cleanup__ and __counted_by__ are the biggest deals to me and I
hope they'll be standardized soon.  The rest of the other stuff
is pretty well-known at this point...


What else is missing from C?


FWIW, I detest hacking in verbose AOT languages in general and
don't write a lot of C as a result.  However, I've spent a
large part of this century fixing C code written by others for
the usual memory leaks, memory errors, races, overflows, etc.

I'm not particularly a fan of the C code in git for a variety
of reasons but have sought to improve it here and there
(container_of, list.h, etc.)

Building git nowadays is painful for me due to the (lack of)
speed from lld/gold/mold on my ancient hardware.  Rust's
famously slow compilation speeds would mean only developers
willing to work for and/or promote $MEGACORP interests would be
able to afford to hack on code.

Thanks for reading.

Re: what's missing from newer C? [was: [PATCH v5 0/9] Introduce Rust ....]

[Ezekiel Newren]

On Wed, Sep 24, 2025 at 7:10 PM Eric Wong <e@80x24.org> wrote:
> What else is missing from C?

1. Checked Arithmetic
  * C23: <stdckdint.h> for checked integer operations.
  * Rust: built-ins like checked_add, wrapping_add.
2. __counted_by__ attribute
  * Clang 18 / GCC 15: experimental, helps catch buffer overflows.
  * Rust: slices already carry length, preventing out-of-bounds by design.
3. __cleanup__ attribute
  * GCC, Clang, TinyCC: long-standing extension for RAII-like cleanup.
  * Rust: Drop trait ensures deterministic cleanup.
4. RCU / concurrency libraries
  * Userspace RCU, ConcurrencyKit, etc. available in C.
  * Rust: crossbeam, Arc, lock-free crates.
5. Format string checking
  * GCC/Clang/MSVC check format strings at compile time.
  * Rust: format! macros type-check arguments.
6. Regex and parsing
  * C: POSIX regex, PCRE2, re2c, wuffs.
  * Rust: regex crate (safe, no unchecked buffer access).
7. Dynamic analysis
  * C: Valgrind, ASan, TSan, UBSan, MSan.
  * Rust: Miri, LLVM sanitizers.

What else is missing in C?

Compared to Rust, here's where C still falls short at the language
level (not just tooling):

1. Ownership and lifetimes
  * No borrow checker; compiler can't prevent use-after-free, double
free, or aliasing bugs.
2. Async/await coroutines
  * No language support. Async requires threads, callbacks, or libraries.
  * Rust: async fn / .await integrated into the language.
3. Explicit numeric conversions
  * C silently promotes between ints/floats/signed/unsigned.
  * Rust requires explicit casts (down and up), reducing surprises.
4. Sum types with exhaustiveness checks
  * C: enum + union is manual, compiler won’t enforce full handling.
  * Rust: enum + match requires covering all variants.
5. Safer error handling
  * C: errno, return codes, ad hoc conventions.
  * Rust: Result<T, E> + ? operator, forcing handling.
6. Concurrency safety by design
  * C11 added atomics, but race conditions are unchecked.
  * Rust: Send / Sync traits enforce thread-safety at compile time.
7. Namespaces / modules
  * C: relies on foo_bar() prefixes and headers.
  * Rust: mod and crate system.
8. Default immutability
  * C: everything mutable unless marked const.
  * Rust: immutable by default, opt into mut. You have a choice of 1
mutable reference xor many immutable references to something.
9. Package management
  * C: out of scope for the language
  * Rust: built in with Cargo dependencies

In Rust there is a difference between concurrency and parallelism.
Concurrency in Rust is about running multiple tasks with a single
system thread. Whereas parallelism is about assigning tasks to
multiple threads. I highly doubt that C will ever get coroutines
because it requires the compiler to create a state machine out of each
function that uses async or await keywords. The C language just isn't
robust enough for that in my opinion.

And there's probably more that I haven't covered here.

Re: what's missing from newer C? [was: [PATCH v5 0/9] Introduce Rust ....]

[Eric Wong]

Ezekiel Newren <ezekielnewren@gmail.com> wrote:
> On Wed, Sep 24, 2025 at 7:10 PM Eric Wong <e@80x24.org> wrote:
> > What else is missing from C?
> 
> 1. Checked Arithmetic
>   * C23: <stdckdint.h> for checked integer operations.
>   * Rust: built-ins like checked_add, wrapping_add.
> 2. __counted_by__ attribute
>   * Clang 18 / GCC 15: experimental, helps catch buffer overflows.
>   * Rust: slices already carry length, preventing out-of-bounds by design.
> 3. __cleanup__ attribute
>   * GCC, Clang, TinyCC: long-standing extension for RAII-like cleanup.
>   * Rust: Drop trait ensures deterministic cleanup.
> 4. RCU / concurrency libraries
>   * Userspace RCU, ConcurrencyKit, etc. available in C.
>   * Rust: crossbeam, Arc, lock-free crates.
> 5. Format string checking
>   * GCC/Clang/MSVC check format strings at compile time.
>   * Rust: format! macros type-check arguments.
> 6. Regex and parsing
>   * C: POSIX regex, PCRE2, re2c, wuffs.
>   * Rust: regex crate (safe, no unchecked buffer access).
> 7. Dynamic analysis
>   * C: Valgrind, ASan, TSan, UBSan, MSan.
>   * Rust: Miri, LLVM sanitizers.
> 
> What else is missing in C?
> 
> Compared to Rust, here's where C still falls short at the language
> level (not just tooling):
> 
> 1. Ownership and lifetimes
>   * No borrow checker; compiler can't prevent use-after-free, double
> free, or aliasing bugs.

As I understand it, the borrow checker is a big part of the slow
compile times which makes it impractical for poor (and/or
anti-consumerist) folks to contribute.  At least Rc/Arc exists
but we can also rely on __cleanup__ to do RC in C.

RCU also has GC-like properties for resource management
with less overhead than a full-blown GC.

> 2. Async/await coroutines
>   * No language support. Async requires threads, callbacks, or libraries.
>   * Rust: async fn / .await integrated into the language.

As someone who's worked on implementing async/green threads for
a VM; I find myself disagreeing with async/green-threads these
days because stacks end up eating large amounts of memory in
less-than-obvious ways.  Memory used by a pure event loop (or
event loop combined w/ native threads|processes) is a sunk cost
in either design.  However, (last I checked,) even Golang ends
up growing stacks in giant 2KB increments whereas event systems
only need dozens or hundreds of bytes (not KB) per FD.

> 3. Explicit numeric conversions
>   * C silently promotes between ints/floats/signed/unsigned.
>   * Rust requires explicit casts (down and up), reducing surprises.

I think the "new" -Wconversion switch can help
<https://gcc.gnu.org/wiki/NewWconversion>, but I haven't tried it.
Using C23 ckd_* functions and wrappers can also help, of course.

> 4. Sum types with exhaustiveness checks
>   * C: enum + union is manual, compiler won’t enforce full handling.
>   * Rust: enum + match requires covering all variants.

Not sure what you mean by "full handling" (banning the
`default:' label?), but C switch + enums do a pretty good job
of warning, already.

I certainly wish enums were more widely used in C projects.

> 5. Safer error handling
>   * C: errno, return codes, ad hoc conventions.
>   * Rust: Result<T, E> + ? operator, forcing handling.

It's down to coding style, yes, but it's not bad.  Linux kernel
uses __attribute__((__warn_unused_result__)) (aka
`__must_check') to force error checking.

> 6. Concurrency safety by design
>   * C11 added atomics, but race conditions are unchecked.
>   * Rust: Send / Sync traits enforce thread-safety at compile time.

I assume you mean "parallelism" safety? (referencing our
terminology below).  It's never been a big problem to me
with RCU and proper understanding of POSIX semantics.

> 7. Namespaces / modules
>   * C: relies on foo_bar() prefixes and headers.
>   * Rust: mod and crate system.

I don't miss namespaces; it seems to be mainly dealing with
colons vs underscores. (Side note: underscores tend to be
cheaper for Xapian (and presumably other search engines)
to deal with :>).

AFAIK, Rust modules + crates are centrally controlled and
publishing requires an account on a proprietary service owned
and operated by a convicted monopolist.  That doesn't fly with
some folks such as myself.

> 8. Default immutability
>   * C: everything mutable unless marked const.
>   * Rust: immutable by default, opt into mut. You have a choice of 1
> mutable reference xor many immutable references to something.

Sure mistakes were made ~50 years ago, but const exists and we
can enforce that via coding style.

> 9. Package management
>   * C: out of scope for the language
>   * Rust: built in with Cargo dependencies

As a Perl user who has avoided CPAN for ~25 years, I prefer
to let distros manage packages and ignore language-specific
managers.  This seems out-of-scope for this discussion,
so more in footnote[1]

> In Rust there is a difference between concurrency and parallelism.
> Concurrency in Rust is about running multiple tasks with a single
> system thread. Whereas parallelism is about assigning tasks to
> multiple threads. I highly doubt that C will ever get coroutines
> because it requires the compiler to create a state machine out of each
> function that uses async or await keywords. The C language just isn't
> robust enough for that in my opinion.

Your terminology matches mine even outside of Rust (IOW,
"ConcurrencyKit" probably should've been named "ParallelismKit").

There's certainly been attempts at coroutines for C.  From what
I've seen in headlines, it certainly seems async + function
coloring in Rust has its fair share of problems and growing
pains.  Again, I really don't think async is worth the problems
and surprises, especially in a low-level(?) language.

> And there's probably more that I haven't covered here.

Again, I would've been much happier if git used more very
high-level language(s) instead of rewriting things to C years
ago.  Given that ship has long sailed, an evolutionary approach
towards improving C would be less exclusionary than a
revolutionary one such as Rust.

Rust seems to try to be a replacement for C++ (with even slower
build times) rather than a thin layer to interface with the OS +
hardware.  C++ mixes high-level and low-level concepts too much
for my liking (and Rust the same).  This is down to personal
taste, but I prefer a good distinction between high and
low-level languages.


[1] - I strongly prefer to only use distro package managers due
      to multi-language projects, distro-specific quirks, extra
      review, ethics/license checks, etc.  I also strongly prefer
      NOT having a central entity affecting users across all
      distros.

Re: what's missing from newer C? [was: [PATCH v5 0/9] Introduce Rust ....]

[Pierre-Emmanuel Patry]

[-- Attachment #1.1.1: Type: text/plain, Size: 1709 bytes --]

> As I understand it, the borrow checker is a big part of the slow
> compile times

 From what can been observed in benchmarks (perf.rust-lang.org) the 
borrow checker is not the biggest part of the slow compile times. It 
certainly isn't the quickest one but I wouldn't make it the culprit.

> As someone who's worked on implementing async/green threads for
> a VM

You seems to be mixing async and green threads within the same point. 
Green threads were removed almost ten years ago before rust 1.0. You may 
learn more about that removal from RFC 230.

>  It's never been a big problem to me
> with RCU and proper understanding of POSIX semantics.

But it has been a problem with less experienced people and that kind of 
problem easily slip through a review.

> it seems to be mainly dealing with colons vs underscores

It doesn't. This is only true when dealing from a C perspective where 
everything can be seen from everywhere. Huge identifiers are harder to 
read. Namespaces offer context dependent short identifiers that won't 
leak in the whole TU.

> AFAIK, Rust modules + crates are centrally controlled and
> publishing requires an account on a proprietary service owned
> and operated by a convicted monopolist.

Publishing on that platform indeed requires an account on GitHub. It's 
probably worth mentioning they're willing to change it but do not have 
the resources nor the bandwidth to do so.

crates.io is not a mandatory step, it's the default and easiest way to 
publish or retrieve a dependencies just like cargo is with building. 
More services like this one may appear but it looks very expensive to 
run and maintain.


Pierre-Emmanuel


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 2513 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 665 bytes --]

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[John Paul Adrian Glaubitz]

Hello Patrick,

On Thu, 2025-09-04 at 16:26 +0200, Patrick Steinhardt wrote:
> this small patch series introduces Rust into the core of Git. This patch
> series is designed as a test balloon, similar to how we introduced test
> balloons for C99 features in the past. The goal is threefold:
> 
>   - Give us some time to experiment with Rust and introduce proper build
>     infrastructure.
> 
>   - Give distributors time to ease into the new toolchain requirements.
>     Introducing Rust is impossible for some platforms and hard for
>     others.
> 
>   - Announce that Git 3.0 will make Rust a mandatory part of our build
>     infrastructure.

I'm one of Debian's maintainers in Debian Ports and I maintain Debian unstable
on older and more obscure architectures such as alpha, hppa, m68k, sh4 and sparc64.

Of all the architectures in Debian, there are currently four architectures that
don't support rustc. Those are alpha, hppa, m68k and sh4 [1]. For m68k, the
situation is special as both LLVM and rustc already support m68k but with Linux
still defaulting to 16-bit alignment on this architecture [2], building LLVM and
rustc is currently not possible. I'm working on a switch to 32-bit alignment
though which is default for NetBSD/m68k and also what specified in the official
SysV ELF ABI documentation.

In general, I'm not against introducing Rust support into existing projects. However,
I wished projects would be a little more patient until either the GCC codegen in
rustc called rustc_codegen_gcc [3] or the Rust frontend in GCC have become ready
for prime time.

My hope would be that more talented Rust developers would help support the two
GCC Rust projects so that these become ready for prime time sooner and that one
of the last blockers for introducing the Rust language across a lot of open source
projects would go away.

I'm not an expert with the Non-Stop operating system, but I could imagine that
a working Rust frontend in GCC would ease porting the Rust language to that
platform as well.

Cheers,
Adrian

> [1] https://buildd.debian.org/status/package.php?p=rustc&suite=sid
> [2] https://wiki.debian.org/M68k/Alignment
> [3] https://rust-for-linux.com/rustc_codegen_gcc
> [4] https://rust-for-linux.com/gccrs

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Patrick Steinhardt]

On Fri, Sep 19, 2025 at 08:41:45PM +0200, John Paul Adrian Glaubitz wrote:
> On Thu, 2025-09-04 at 16:26 +0200, Patrick Steinhardt wrote:
> > this small patch series introduces Rust into the core of Git. This patch
> > series is designed as a test balloon, similar to how we introduced test
> > balloons for C99 features in the past. The goal is threefold:
> > 
> >   - Give us some time to experiment with Rust and introduce proper build
> >     infrastructure.
> > 
> >   - Give distributors time to ease into the new toolchain requirements.
> >     Introducing Rust is impossible for some platforms and hard for
> >     others.
> > 
> >   - Announce that Git 3.0 will make Rust a mandatory part of our build
> >     infrastructure.
> 
> I'm one of Debian's maintainers in Debian Ports and I maintain Debian unstable
> on older and more obscure architectures such as alpha, hppa, m68k, sh4 and sparc64.
> 
> Of all the architectures in Debian, there are currently four architectures that
> don't support rustc. Those are alpha, hppa, m68k and sh4 [1]. For m68k, the
> situation is special as both LLVM and rustc already support m68k but with Linux
> still defaulting to 16-bit alignment on this architecture [2], building LLVM and
> rustc is currently not possible. I'm working on a switch to 32-bit alignment
> though which is default for NetBSD/m68k and also what specified in the official
> SysV ELF ABI documentation.
> 
> In general, I'm not against introducing Rust support into existing projects. However,
> I wished projects would be a little more patient until either the GCC codegen in
> rustc called rustc_codegen_gcc [3] or the Rust frontend in GCC have become ready
> for prime time.

Thanks for raising these concerns, I really appreciate that! Making
platform maintainers aware of this upcoming change was one of the goals
of announcing the breaking change in the first place, so I'm happy to
see that this discussion is happening now :) After all, we are aware
that the proposed change can create hardships for downstream
distributions and maintainers.

The timeline I have layed out right now is trying to cater towards
gccrs, at least to a certain extent. As Pierre-Emmanuel mentioned in
[1], gccrs _may_ start to become ready next year with a target version
of Rust 1.49. Given proposed timelines, Git 3.0 with mandatory Rust
would be released at the end of next year, which would hopefully be
after gccrs slowly becoming a viable alternative to compile Rust.

This is also the reason why I've picked Rust 2018 as the edition, as
Rust 1.49 doesn't know about any later editions.

Of course, given that the work on gccrs is driven by volunteers to the
best of my understanding I don't want to "force" them to get this done
by that point, and Pierre-Emmanual also made clear that the initial
release is still likely to have many bugs. So it may be the case that
gccrs or any other codegen is not ready yet at that point in time. If
so, we might have to reopen the discussion of whether or not we really
want to switch over to mandatory Rust with Git 3.0.

Ultimately, I guess that this will also depend on how much of a pain it
is for us to keep Rust non-mandatory. We don't have a lot of experience
with Rust in our codebase yet, but if we eventually see that it's a
breeze to keep it optional I think we should consider deferring the date
where it's becoming mandatory.

All to say: I don't think we should blindly pull the trigger with Git
3.0. I think we should take a more nuanced approach and consider:

  - Any of the learnings we had with the initial Rust infra and how hard
    it is to keep it optional.

  - The status quo of the ecosystem and whether we can expect either
    gccrs or rustc_codegen_gcc to become stable.

That being said, I think we should keep the current intent spelt out in
our breaking changes document so that we can get more feedback from
downstream maintainers that aren't currently aware of the porposed
upcoming change.

Thanks!

Patrick

[1]: <7bf054a1-0196-4ad8-aaa4-a432cd2c93a5@embecosm.com>

[PATCH v6 0/9] Introduce Rust and announce that it will become mandatory

[Patrick Steinhardt]

Hi,

this small patch series introduces Rust into the core of Git. This patch
series is designed as a test balloon, similar to how we introduced test
balloons for C99 features in the past. The goal is threefold:

  - Give us some time to experiment with Rust and introduce proper build
    infrastructure.

  - Give distributors time to ease into the new toolchain requirements.
    Introducing Rust is impossible for some platforms and hard for
    others.

  - Announce that Git 3.0 will make Rust a mandatory part of our build
    infrastructure.

The test balloon itself is quite uninteresting: I've chosen to convert
the "varint.c" subsystem, mostly because it is trivial and does not have
any dependencies. But it does allow us to verify that C to Rust interop
works as expected, and to play around with tooling. All tests pass with
the "varint.rs" implementation.

For now, the series only contains support for Meson. If we agree to go
down this route I'll also introduce support for Rust into our Makefiles
at a later point in time.

Furthermore missing is additional tooling:

  - At least one CI job to verify that Rust builds and works as
    expected.

  - Tooling and CI jobs to ensure that we have consistent formatting via
    `cargo format`.

And probably lots more. As said, the entire goal is for us to have an
easy playground that we can experiment on and develop the infrastructure
incrementally without yet having to commit to anything.

I'm mostly splitting out the topic of introducing Rust from the larger
series that introduce it into xdiff so that we can focus more on the
actual process of introducing Rust into Git and less on the potential
features that we want to build on top of it.

Changes in v2:
  - Introduce support for building the Rust library via our Makefile.
  - Introduce a '-DWITH_RUST' define. This define is used to print
    whether or not Git is built with Rust via `git version
    --build-options`.
  - Adjust Meson to not depend on v1.9.0 and newer anymore.
  - Introduce a roadmap into our BreakingChanges document to explain how
    we'll iterate towards mandatory Rust support.
  - Rework the Fedora job to do a full compile-and-test run with Meson
    and breaking changes enabled.
  - Adapt our breaking-changes jobs to enable Rust support.
  - Link to v1: https://lore.kernel.org/r/20250904-b4-pks-rust-breaking-change-v1-0-3af1d25e0be9@pks.im

Changes in v3:
  - Reorder all uses of `WITH_RUST` after the include of "config.mak".
  - Add a test to verify overflow behaviour in Rust and explicitly use
    `add_wrapping()`.
  - Use explicit dependencies for the Rust library in our Makefile.
  - Fix Alma Linux CI job.
  - Stop tying maintenance of our LTS release to the availability of
    gcc-rs.
  - Add a fallback to Meson to use cargo directly.
  - I've fixed the Rust edition to 2018 for now. This is intentionally
    conservative so that we might be able to use Rust 1.49. For now, we
    don't have any reason to use a newer edition, either. So let's take
    the oldest version we can live with for now and then bump it as
    required.
  - Link to v2: https://lore.kernel.org/r/20250905-b4-pks-rust-breaking-change-v2-0-6939cbf4a0b8@pks.im

Changes in v4:
  - Convert "varint.c" to use explicit integer width so that we don't
    need to use C types in Rust.
  - Adapt Meson to unconditionally use Cargo.
  - Don't use the unstable `--out-dir` option in Cargo. Instead, we
    resort to a wrapper script in Meson.
  - Shorten the timeline a bit to drop the extra step that ties Rust
    support to `-Dbreaking_changes=true`. This accelerates the timeline
    until distros are made forcibly aware of the upcoming changes in
    Rust.
  - Link to v3: https://lore.kernel.org/r/20250908-b4-pks-rust-breaking-change-v3-0-1cd7189fed3b@pks.im

Changes in v5:
  - Fix indentation in the BreakingChanges document.
  - Fix a commit message typo.
  - Include "Cargo.lock" in the `make clean` target again.
  - Link to v4: https://lore.kernel.org/r/20250910-b4-pks-rust-breaking-change-v4-0-4a63fc69278d@pks.im

Changes in v6:
  - Give attribution to Ezekiel for kickstarting the Rust adoption
    again. I'm happy to change how I do the attribution.
  - Fix "varint.rs" to use `u64` instead of `usize`. Issues like these
    will eventually be catched by cbindgen.
  - Adapt the breaking changes document to mention that we already have
    Rust in our tree starting with Git 2.49.
  - Mention that we won't blindly make Rust mandatory, but consider the
    impact on downstream distributions.
  - Slightly reword how we'll handle LTS maintainership. This probably
    still is an ongoing discussion.
  - Link to v5: https://lore.kernel.org/r/20250915-b4-pks-rust-breaking-change-v5-0-dc3a32fbb216@pks.im

Thanks!

Patrick

---
Patrick Steinhardt (9):
      meson: add infrastructure to build internal Rust library
      Makefile: reorder sources after includes
      Makefile: introduce infrastructure to build internal Rust library
      help: report on whether or not Rust is enabled
      varint: use explicit width for integers
      varint: reimplement as test balloon for Rust
      BreakingChanges: announce Rust becoming mandatory
      ci: convert "pedantic" job into full build with breaking changes
      ci: enable Rust for breaking-changes jobs

 .github/workflows/main.yml         |   4 +-
 .gitignore                         |   2 +
 .gitlab-ci.yml                     |   4 +-
 Cargo.toml                         |   9 ++
 Documentation/BreakingChanges.adoc |  45 ++++++++
 Makefile                           | 214 ++++++++++++++++++++++---------------
 ci/install-dependencies.sh         |   8 +-
 ci/run-build-and-tests.sh          |  31 ++----
 dir.c                              |  18 ++--
 help.c                             |   6 ++
 meson.build                        |  15 ++-
 meson_options.txt                  |   2 +
 read-cache.c                       |   6 +-
 shared.mak                         |   1 +
 src/cargo-meson.sh                 |  32 ++++++
 src/lib.rs                         |   1 +
 src/meson.build                    |  41 +++++++
 src/varint.rs                      |  92 ++++++++++++++++
 varint.c                           |   6 +-
 varint.h                           |   4 +-
 20 files changed, 410 insertions(+), 131 deletions(-)

Range-diff versus v5:

 1:  22925bf016 !  1:  06872fe524 meson: add infrastructure to build internal Rust library
    @@ Commit message
         want to introduce features that were added in more recent editions of
         Rust though we should reevaluate that choice.
     
    +    Inspired-by: Ezekiel Newren <ezekielnewren@gmail.com>
         Signed-off-by: Patrick Steinhardt <ps@pks.im>
     
      ## Cargo.toml (new) ##
 2:  bcd30c4e0f =  2:  0f243f137e Makefile: reorder sources after includes
 3:  45663309c3 !  3:  cb078bdffc Makefile: introduce infrastructure to build internal Rust library
    @@ Commit message
         commit. Developers can enable the infrastructure by passing the new
         `WITH_RUST` build toggle.
     
    +    Inspired-by: Ezekiel Newren <ezekielnewren@gmail.com>
         Signed-off-by: Patrick Steinhardt <ps@pks.im>
     
      ## .gitignore ##
 4:  1eec68d6a3 =  4:  b043011938 help: report on whether or not Rust is enabled
 5:  95f705fc07 =  5:  b3b415b277 varint: use explicit width for integers
 6:  2d36e3bb54 !  6:  435e5c3ae5 varint: reimplement as test balloon for Rust
    @@ src/meson.build
      ## src/varint.rs (new) ##
     @@
     +#[no_mangle]
    -+pub unsafe extern "C" fn decode_varint(bufp: *mut *const u8) -> usize {
    ++pub unsafe extern "C" fn decode_varint(bufp: *mut *const u8) -> u64 {
     +    let mut buf = *bufp;
     +    let mut c = *buf;
    -+    let mut val = usize::from(c & 127);
    ++    let mut val = u64::from(c & 127);
     +
     +    buf = buf.add(1);
     +
    @@ src/varint.rs (new)
     +        c = *buf;
     +        buf = buf.add(1);
     +
    -+        val = (val << 7) + usize::from(c & 127);
    ++        val = (val << 7) + u64::from(c & 127);
     +    }
     +
     +    *bufp = buf;
    @@ src/varint.rs (new)
     +}
     +
     +#[no_mangle]
    -+pub unsafe extern "C" fn encode_varint(value: usize, buf: *mut u8) -> u8 {
    ++pub unsafe extern "C" fn encode_varint(value: u64, buf: *mut u8) -> u8 {
     +    let mut varint: [u8; 16] = [0; 16];
     +    let mut pos = varint.len() - 1;
     +
 7:  92590e9f87 !  7:  3f0cb3550a BreakingChanges: announce Rust becoming mandatory
    @@ Documentation/BreakingChanges.adoc: A prerequisite for this change is that the e
      JGit, libgit2 and Gitoxide need to support it.
      
     +* Git will require Rust as a mandatory part of the build process. While Git
    -+  already started to adopt Rust in Git 2.52, all parts written in Rust are
    ++  already started to adopt Rust in Git 2.49, all parts written in Rust are
     +  optional for the time being. This includes:
     ++
    ++  ** The Rust wrapper around libgit.a that is part of "contrib/" and which has
    ++     been introduced in Git 2.49.
     +  ** Subsystems that have an alternative implementation in Rust to test
     +     interoperability between our C and Rust codebase.
     +  ** Newly written features that are not mission critical for a fully functional
    @@ Documentation/BreakingChanges.adoc: A prerequisite for this change is that the e
     +project will hand over maintainership of the long-term release to distributors
     +in case they need to extend the life of that long-term release even further. In
     +that case, the backporting process will be handled by these distributors, but
    -+the backported patches will be reviewed on the mailing list and pulled in by the
    -+Git maintainer.
    ++the long-term release tags will be created in the canonical Git repository.
    +++
    ++We will evaluate the impact on downstream distributions before making Rust
    ++mandatory in Git 3.0. If we see that the impact on downstream distributions
    ++would be significant, we may decide to defer this breaking change to a
    ++subsequent minor release. This evaluation will also take into account our own
    ++learnings with how painful it is to keep Rust an optional component.
     +
      === Removals
      
 8:  3c7b2edeb4 =  8:  e5dc29bc1c ci: convert "pedantic" job into full build with breaking changes
 9:  c3803ab47b =  9:  9fcaa8c540 ci: enable Rust for breaking-changes jobs

---
base-commit: 2462961280690837670d997bde64bd4ebf8ae66d
change-id: 20250904-b4-pks-rust-breaking-change-7167d9d3e37d

[PATCH v6 1/9] meson: add infrastructure to build internal Rust library

[Patrick Steinhardt]

Add the infrastructure into Meson to build an internal Rust library.
Building the Rust parts of Git are for now entirely optional, as they
are mostly intended as a test balloon for both Git developers, but also
for distributors of Git. So for now, they may contain:

  - New features that are not mission critical to Git and that users can
    easily live without.

  - Alternative implementations of small subsystems.

If these test balloons are successful, we will eventually make Rust a
mandatory dependency for our build process in Git 3.0.

The availability of a Rust toolchain will be auto-detected by Meson at
setup time. This behaviour can be tweaked via the `-Drust=` feature
toggle.

Next to the linkable Rust library, also wire up tests that can be
executed via `meson test`. This allows us to use the native unit testing
capabilities of Rust.

Note that the Rust edition is currently set to 2018. This edition is
supported by Rust 1.49, which is the target for the upcoming gcc-rs
backend. For now we don't use any features of Rust that would require a
newer version, so settling on this old version makes sense so that
gcc-rs may become an alternative backend for compiling Git. If we _do_
want to introduce features that were added in more recent editions of
Rust though we should reevaluate that choice.

Inspired-by: Ezekiel Newren <ezekielnewren@gmail.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 Cargo.toml         |  9 +++++++++
 meson.build        | 10 +++++++++-
 meson_options.txt  |  2 ++
 src/cargo-meson.sh | 32 ++++++++++++++++++++++++++++++++
 src/lib.rs         |  0
 src/meson.build    | 40 ++++++++++++++++++++++++++++++++++++++++
 6 files changed, 92 insertions(+), 1 deletion(-)

diff --git a/Cargo.toml b/Cargo.toml
new file mode 100644
index 00000000000..b9a41dbc792
--- /dev/null
+++ b/Cargo.toml
@@ -0,0 +1,9 @@
+[package]
+name = "git"
+version = "0.1.0"
+edition = "2018"
+
+[lib]
+crate-type = ["staticlib"]
+
+[dependencies]
diff --git a/meson.build b/meson.build
index e8ec0eca165..234a9e9d6fd 100644
--- a/meson.build
+++ b/meson.build
@@ -220,7 +220,7 @@ project('git', 'c',
   # learned to define __STDC_VERSION__ with C11 and later. We thus require
   # GNU C99 and fall back to C11. Meson only learned to handle the fallback
   # with version 1.3.0, so on older versions we use GNU C99 unconditionally.
-  default_options: meson.version().version_compare('>=1.3.0') ? ['c_std=gnu99,c11'] : ['c_std=gnu99'],
+  default_options: meson.version().version_compare('>=1.3.0') ? ['rust_std=2018', 'c_std=gnu99,c11'] : ['rust_std=2018', 'c_std=gnu99'],
 )
 
 fs = import('fs')
@@ -1702,6 +1702,13 @@ version_def_h = custom_target(
 )
 libgit_sources += version_def_h
 
+cargo = find_program('cargo', dirs: program_path, native: true, required: get_option('rust'))
+rust_option = get_option('rust').disable_auto_if(not cargo.found())
+if rust_option.allowed()
+  subdir('src')
+  libgit_c_args += '-DWITH_RUST'
+endif
+
 libgit = declare_dependency(
   link_with: static_library('git',
     sources: libgit_sources,
@@ -2239,6 +2246,7 @@ summary({
   'pcre2': pcre2,
   'perl': perl_features_enabled,
   'python': target_python.found(),
+  'rust': rust_option.allowed(),
 }, section: 'Auto-detected features', bool_yn: true)
 
 summary({
diff --git a/meson_options.txt b/meson_options.txt
index 1668f260a18..143dee9237c 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -71,6 +71,8 @@ option('zlib_backend', type: 'combo', choices: ['auto', 'zlib', 'zlib-ng'], valu
 # Build tweaks.
 option('breaking_changes', type: 'boolean', value: false,
   description: 'Enable upcoming breaking changes.')
+option('rust', type: 'feature', value: 'auto',
+  description: 'Enable building with Rust.')
 option('macos_use_homebrew_gettext', type: 'boolean', value: true,
   description: 'Use gettext from Homebrew instead of the slightly-broken system-provided one.')
 
diff --git a/src/cargo-meson.sh b/src/cargo-meson.sh
new file mode 100755
index 00000000000..f29745beb36
--- /dev/null
+++ b/src/cargo-meson.sh
@@ -0,0 +1,32 @@
+#!/bin/sh
+
+if test "$#" -lt 2
+then
+	exit 1
+fi
+
+SOURCE_DIR="$1"
+BUILD_DIR="$2"
+BUILD_TYPE=debug
+
+shift 2
+
+for arg
+do
+	case "$arg" in
+	--release)
+		BUILD_TYPE=release;;
+	esac
+done
+
+cargo build --lib --quiet --manifest-path="$SOURCE_DIR/Cargo.toml" --target-dir="$BUILD_DIR" "$@"
+RET=$?
+if test $RET -ne 0
+then
+	exit $RET
+fi
+
+if ! cmp "$BUILD_DIR/$BUILD_TYPE/libgit.a" "$BUILD_DIR/libgit.a" >/dev/null 2>&1
+then
+	cp "$BUILD_DIR/$BUILD_TYPE/libgit.a" "$BUILD_DIR/libgit.a"
+fi
diff --git a/src/lib.rs b/src/lib.rs
new file mode 100644
index 00000000000..e69de29bb2d
diff --git a/src/meson.build b/src/meson.build
new file mode 100644
index 00000000000..734de0b4fa9
--- /dev/null
+++ b/src/meson.build
@@ -0,0 +1,40 @@
+libgit_rs_sources = [
+  'lib.rs',
+]
+
+# Unfortunately we must use a wrapper command to move the output file into the
+# current build directory. This can fixed once `cargo build --artifact-dir`
+# stabilizes. See https://github.com/rust-lang/cargo/issues/6790 for that
+# effort.
+cargo_command = [
+  shell,
+  meson.current_source_dir() / 'cargo-meson.sh',
+  meson.project_source_root(),
+  meson.current_build_dir(),
+]
+if get_option('buildtype') == 'release'
+  cargo_command += '--release'
+endif
+
+libgit_rs = custom_target('git_rs',
+  input: libgit_rs_sources + [
+    meson.project_source_root() / 'Cargo.toml',
+  ],
+  output: 'libgit.a',
+  command: cargo_command,
+)
+libgit_dependencies += declare_dependency(link_with: libgit_rs)
+
+if get_option('tests')
+  test('rust', cargo,
+    args: [
+      'test',
+      '--manifest-path',
+      meson.project_source_root() / 'Cargo.toml',
+      '--target-dir',
+      meson.current_build_dir() / 'target',
+    ],
+    timeout: 0,
+    protocol: 'rust',
+  )
+endif

-- 
2.51.0.536.g15c5d4f767.dirty

[PATCH v6 2/9] Makefile: reorder sources after includes

[Patrick Steinhardt]

In an upcoming change we'll make some of the sources compile
conditionally based on whether or not `WITH_RUST` is defined. To let
developers specify that flag in their "config.mak" we'll thus have to
reorder our sources so that they come after the include of that file.

Do so.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 Makefile | 176 +++++++++++++++++++++++++++++++--------------------------------
 1 file changed, 88 insertions(+), 88 deletions(-)

diff --git a/Makefile b/Makefile
index 555b7f4dc3..7e52625d75 100644
--- a/Makefile
+++ b/Makefile
@@ -919,6 +919,94 @@ LIB_FILE = libgit.a
 XDIFF_LIB = xdiff/lib.a
 REFTABLE_LIB = reftable/libreftable.a
 
+# xdiff and reftable libs may in turn depend on what is in libgit.a
+GITLIBS = common-main.o $(LIB_FILE) $(XDIFF_LIB) $(REFTABLE_LIB) $(LIB_FILE)
+EXTLIBS =
+
+GIT_USER_AGENT = git/$(GIT_VERSION)
+
+ifeq ($(wildcard sha1collisiondetection/lib/sha1.h),sha1collisiondetection/lib/sha1.h)
+DC_SHA1_SUBMODULE = auto
+endif
+
+# Set CFLAGS, LDFLAGS and other *FLAGS variables. These might be
+# tweaked by config.* below as well as the command-line, both of
+# which'll override these defaults.
+# Older versions of GCC may require adding "-std=gnu99" at the end.
+CFLAGS = -g -O2 -Wall
+LDFLAGS =
+CC_LD_DYNPATH = -Wl,-rpath,
+BASIC_CFLAGS = -I.
+BASIC_LDFLAGS =
+
+# library flags
+ARFLAGS = rcs
+PTHREAD_CFLAGS =
+
+# For the 'sparse' target
+SPARSE_FLAGS ?= -std=gnu99 -D__STDC_NO_VLA__
+SP_EXTRA_FLAGS =
+
+# For informing GIT-BUILD-OPTIONS of the SANITIZE=leak,address targets
+SANITIZE_LEAK =
+SANITIZE_ADDRESS =
+
+# For the 'coccicheck' target
+SPATCH_INCLUDE_FLAGS = --all-includes
+SPATCH_FLAGS =
+SPATCH_TEST_FLAGS =
+
+# If *.o files are present, have "coccicheck" depend on them, with
+# COMPUTE_HEADER_DEPENDENCIES this will speed up the common-case of
+# only needing to re-generate coccicheck results for the users of a
+# given API if it's changed, and not all files in the project. If
+# COMPUTE_HEADER_DEPENDENCIES=no this will be unset too.
+SPATCH_USE_O_DEPENDENCIES = YesPlease
+
+# Set SPATCH_CONCAT_COCCI to concatenate the contrib/cocci/*.cocci
+# files into a single contrib/cocci/ALL.cocci before running
+# "coccicheck".
+#
+# Pros:
+#
+# - Speeds up a one-shot run of "make coccicheck", as we won't have to
+#   parse *.[ch] files N times for the N *.cocci rules
+#
+# Cons:
+#
+# - Will make incremental development of *.cocci slower, as
+#   e.g. changing strbuf.cocci will re-run all *.cocci.
+#
+# - Makes error and performance analysis harder, as rules will be
+#   applied from a monolithic ALL.cocci, rather than
+#   e.g. strbuf.cocci. To work around this either undefine this, or
+#   generate a specific patch, e.g. this will always use strbuf.cocci,
+#   not ALL.cocci:
+#
+#	make contrib/coccinelle/strbuf.cocci.patch
+SPATCH_CONCAT_COCCI = YesPlease
+
+# Rebuild 'coccicheck' if $(SPATCH), its flags etc. change
+TRACK_SPATCH_DEFINES =
+TRACK_SPATCH_DEFINES += $(SPATCH)
+TRACK_SPATCH_DEFINES += $(SPATCH_INCLUDE_FLAGS)
+TRACK_SPATCH_DEFINES += $(SPATCH_FLAGS)
+TRACK_SPATCH_DEFINES += $(SPATCH_TEST_FLAGS)
+GIT-SPATCH-DEFINES: FORCE
+	@FLAGS='$(TRACK_SPATCH_DEFINES)'; \
+	    if test x"$$FLAGS" != x"`cat GIT-SPATCH-DEFINES 2>/dev/null`" ; then \
+		echo >&2 "    * new spatch flags"; \
+		echo "$$FLAGS" >GIT-SPATCH-DEFINES; \
+            fi
+
+include config.mak.uname
+-include config.mak.autogen
+-include config.mak
+
+ifdef DEVELOPER
+include config.mak.dev
+endif
+
 GENERATED_H += command-list.h
 GENERATED_H += config-list.h
 GENERATED_H += hook-list.h
@@ -1387,94 +1475,6 @@ CLAR_TEST_OBJS += $(UNIT_TEST_DIR)/unit-test.o
 
 UNIT_TEST_OBJS += $(UNIT_TEST_DIR)/test-lib.o
 
-# xdiff and reftable libs may in turn depend on what is in libgit.a
-GITLIBS = common-main.o $(LIB_FILE) $(XDIFF_LIB) $(REFTABLE_LIB) $(LIB_FILE)
-EXTLIBS =
-
-GIT_USER_AGENT = git/$(GIT_VERSION)
-
-ifeq ($(wildcard sha1collisiondetection/lib/sha1.h),sha1collisiondetection/lib/sha1.h)
-DC_SHA1_SUBMODULE = auto
-endif
-
-# Set CFLAGS, LDFLAGS and other *FLAGS variables. These might be
-# tweaked by config.* below as well as the command-line, both of
-# which'll override these defaults.
-# Older versions of GCC may require adding "-std=gnu99" at the end.
-CFLAGS = -g -O2 -Wall
-LDFLAGS =
-CC_LD_DYNPATH = -Wl,-rpath,
-BASIC_CFLAGS = -I.
-BASIC_LDFLAGS =
-
-# library flags
-ARFLAGS = rcs
-PTHREAD_CFLAGS =
-
-# For the 'sparse' target
-SPARSE_FLAGS ?= -std=gnu99 -D__STDC_NO_VLA__
-SP_EXTRA_FLAGS =
-
-# For informing GIT-BUILD-OPTIONS of the SANITIZE=leak,address targets
-SANITIZE_LEAK =
-SANITIZE_ADDRESS =
-
-# For the 'coccicheck' target
-SPATCH_INCLUDE_FLAGS = --all-includes
-SPATCH_FLAGS =
-SPATCH_TEST_FLAGS =
-
-# If *.o files are present, have "coccicheck" depend on them, with
-# COMPUTE_HEADER_DEPENDENCIES this will speed up the common-case of
-# only needing to re-generate coccicheck results for the users of a
-# given API if it's changed, and not all files in the project. If
-# COMPUTE_HEADER_DEPENDENCIES=no this will be unset too.
-SPATCH_USE_O_DEPENDENCIES = YesPlease
-
-# Set SPATCH_CONCAT_COCCI to concatenate the contrib/cocci/*.cocci
-# files into a single contrib/cocci/ALL.cocci before running
-# "coccicheck".
-#
-# Pros:
-#
-# - Speeds up a one-shot run of "make coccicheck", as we won't have to
-#   parse *.[ch] files N times for the N *.cocci rules
-#
-# Cons:
-#
-# - Will make incremental development of *.cocci slower, as
-#   e.g. changing strbuf.cocci will re-run all *.cocci.
-#
-# - Makes error and performance analysis harder, as rules will be
-#   applied from a monolithic ALL.cocci, rather than
-#   e.g. strbuf.cocci. To work around this either undefine this, or
-#   generate a specific patch, e.g. this will always use strbuf.cocci,
-#   not ALL.cocci:
-#
-#	make contrib/coccinelle/strbuf.cocci.patch
-SPATCH_CONCAT_COCCI = YesPlease
-
-# Rebuild 'coccicheck' if $(SPATCH), its flags etc. change
-TRACK_SPATCH_DEFINES =
-TRACK_SPATCH_DEFINES += $(SPATCH)
-TRACK_SPATCH_DEFINES += $(SPATCH_INCLUDE_FLAGS)
-TRACK_SPATCH_DEFINES += $(SPATCH_FLAGS)
-TRACK_SPATCH_DEFINES += $(SPATCH_TEST_FLAGS)
-GIT-SPATCH-DEFINES: FORCE
-	@FLAGS='$(TRACK_SPATCH_DEFINES)'; \
-	    if test x"$$FLAGS" != x"`cat GIT-SPATCH-DEFINES 2>/dev/null`" ; then \
-		echo >&2 "    * new spatch flags"; \
-		echo "$$FLAGS" >GIT-SPATCH-DEFINES; \
-            fi
-
-include config.mak.uname
--include config.mak.autogen
--include config.mak
-
-ifdef DEVELOPER
-include config.mak.dev
-endif
-
 GIT-VERSION-FILE: FORCE
 	@OLD=$$(cat $@ 2>/dev/null || :) && \
 	$(call version_gen,"$(shell pwd)",GIT-VERSION-FILE.in,$@) && \

-- 
2.51.0.536.g15c5d4f767.dirty

[PATCH v6 3/9] Makefile: introduce infrastructure to build internal Rust library

[Patrick Steinhardt]

Introduce infrastructure to build the internal Rust library. This
mirrors the infrastructure we have added to Meson in the preceding
commit. Developers can enable the infrastructure by passing the new
`WITH_RUST` build toggle.

Inspired-by: Ezekiel Newren <ezekielnewren@gmail.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 .gitignore |  2 ++
 Makefile   | 37 +++++++++++++++++++++++++++++++++++++
 shared.mak |  1 +
 3 files changed, 40 insertions(+)

diff --git a/.gitignore b/.gitignore
index 1803023427..0833453cf6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,4 +1,6 @@
 /fuzz_corpora
+/target/
+/Cargo.lock
 /GIT-BUILD-DIR
 /GIT-BUILD-OPTIONS
 /GIT-CFLAGS
diff --git a/Makefile b/Makefile
index 7e52625d75..e8518198fc 100644
--- a/Makefile
+++ b/Makefile
@@ -483,6 +483,14 @@ include shared.mak
 # Define LIBPCREDIR=/foo/bar if your PCRE header and library files are
 # in /foo/bar/include and /foo/bar/lib directories.
 #
+# == Optional Rust support ==
+#
+# Define WITH_RUST if you want to include features and subsystems written in
+# Rust into Git. For now, Rust is still an optional feature of the build
+# process. With Git 3.0 though, Rust will always be enabled.
+#
+# Building Rust code requires Cargo.
+#
 # == SHA-1 and SHA-256 defines ==
 #
 # === SHA-1 backend ===
@@ -683,6 +691,7 @@ OBJECTS =
 OTHER_PROGRAMS =
 PROGRAM_OBJS =
 PROGRAMS =
+RUST_SOURCES =
 EXCLUDED_PROGRAMS =
 SCRIPT_PERL =
 SCRIPT_PYTHON =
@@ -918,6 +927,11 @@ TEST_SHELL_PATH = $(SHELL_PATH)
 LIB_FILE = libgit.a
 XDIFF_LIB = xdiff/lib.a
 REFTABLE_LIB = reftable/libreftable.a
+ifdef DEBUG
+RUST_LIB = target/debug/libgit.a
+else
+RUST_LIB = target/release/libgit.a
+endif
 
 # xdiff and reftable libs may in turn depend on what is in libgit.a
 GITLIBS = common-main.o $(LIB_FILE) $(XDIFF_LIB) $(REFTABLE_LIB) $(LIB_FILE)
@@ -943,6 +957,15 @@ BASIC_LDFLAGS =
 ARFLAGS = rcs
 PTHREAD_CFLAGS =
 
+# Rust flags
+CARGO_ARGS =
+ifndef V
+CARGO_ARGS += --quiet
+endif
+ifndef DEBUG
+CARGO_ARGS += --release
+endif
+
 # For the 'sparse' target
 SPARSE_FLAGS ?= -std=gnu99 -D__STDC_NO_VLA__
 SP_EXTRA_FLAGS =
@@ -1475,6 +1498,8 @@ CLAR_TEST_OBJS += $(UNIT_TEST_DIR)/unit-test.o
 
 UNIT_TEST_OBJS += $(UNIT_TEST_DIR)/test-lib.o
 
+RUST_SOURCES += src/lib.rs
+
 GIT-VERSION-FILE: FORCE
 	@OLD=$$(cat $@ 2>/dev/null || :) && \
 	$(call version_gen,"$(shell pwd)",GIT-VERSION-FILE.in,$@) && \
@@ -1504,6 +1529,11 @@ endif
 ALL_CFLAGS = $(DEVELOPER_CFLAGS) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_APPEND)
 ALL_LDFLAGS = $(LDFLAGS) $(LDFLAGS_APPEND)
 
+ifdef WITH_RUST
+BASIC_CFLAGS += -DWITH_RUST
+GITLIBS += $(RUST_LIB)
+endif
+
 ifdef SANITIZE
 SANITIZERS := $(foreach flag,$(subst $(comma),$(space),$(SANITIZE)),$(flag))
 BASIC_CFLAGS += -fsanitize=$(SANITIZE) -fno-sanitize-recover=$(SANITIZE)
@@ -2918,6 +2948,12 @@ scalar$X: scalar.o GIT-LDFLAGS $(GITLIBS)
 $(LIB_FILE): $(LIB_OBJS)
 	$(QUIET_AR)$(RM) $@ && $(AR) $(ARFLAGS) $@ $^
 
+$(RUST_LIB): Cargo.toml $(RUST_SOURCES)
+	$(QUIET_CARGO)cargo build $(CARGO_ARGS)
+
+.PHONY: rust
+rust: $(RUST_LIB)
+
 $(XDIFF_LIB): $(XDIFF_OBJS)
 	$(QUIET_AR)$(RM) $@ && $(AR) $(ARFLAGS) $@ $^
 
@@ -3768,6 +3804,7 @@ clean: profile-clean coverage-clean cocciclean
 	$(RM) $(FUZZ_PROGRAMS)
 	$(RM) $(SP_OBJ)
 	$(RM) $(HCC)
+	$(RM) -r Cargo.lock target/
 	$(RM) version-def.h
 	$(RM) -r $(dep_dirs) $(compdb_dir) compile_commands.json
 	$(RM) $(test_bindir_programs)
diff --git a/shared.mak b/shared.mak
index 5c7bc94785..0e7492076e 100644
--- a/shared.mak
+++ b/shared.mak
@@ -56,6 +56,7 @@ ifndef V
 	QUIET_MKDIR_P_PARENT  = @echo '   ' MKDIR -p $(@D);
 
 ## Used in "Makefile"
+	QUIET_CARGO    = @echo '   ' CARGO $@;
 	QUIET_CC       = @echo '   ' CC $@;
 	QUIET_AR       = @echo '   ' AR $@;
 	QUIET_LINK     = @echo '   ' LINK $@;

-- 
2.51.0.536.g15c5d4f767.dirty

[PATCH v6 4/9] help: report on whether or not Rust is enabled

[Patrick Steinhardt]

We're about to introduce support for Rust into the core of Git, where
some (trivial) subsystems are converted to Rust. These subsystems will
also retain a C implementation though as Rust is not yet mandatory.
Consequently, it now becomes possible for a Git version to have bugs
that are specific to whether or not it is built with Rust support
overall.

Expose information about whether or not Git was built with Rust via our
build info. This means that both `git version --build-options`, but also
`git bugreport` will now expose that bit of information. Hopefully, this
should make it easier for us to discover any Rust-specific issues.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 help.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/help.c b/help.c
index bb20498cfd..5854dd4a7e 100644
--- a/help.c
+++ b/help.c
@@ -791,6 +791,12 @@ void get_version_info(struct strbuf *buf, int show_build_options)
 		strbuf_addf(buf, "shell-path: %s\n", SHELL_PATH);
 		/* NEEDSWORK: also save and output GIT-BUILD_OPTIONS? */
 
+#if defined WITH_RUST
+		strbuf_addstr(buf, "rust: enabled\n");
+#else
+		strbuf_addstr(buf, "rust: disabled\n");
+#endif
+
 		if (fsmonitor_ipc__is_supported())
 			strbuf_addstr(buf, "feature: fsmonitor--daemon\n");
 #if defined LIBCURL_VERSION

-- 
2.51.0.536.g15c5d4f767.dirty

[PATCH v6 5/9] varint: use explicit width for integers

[Patrick Steinhardt]

The varint subsystem currently uses implcit widths for integers. On the
one hand we use `uintmax_t` for the actual value. On the other hand, we
use `int` for the length of the encoded varint.

Both of these have known maximum vaules, as we only support at most 16
bytes when encoding varints. Thus, we know that we won't ever exceed
`uint64_t` for the actual value and `uint8_t` for the prefix length.

Refactor the code to use explicit widths. Besides making the logic
platform-independent, it also makes our life a bit easier in the next
commit, where we reimplement "varint.c" in Rust.

Suggested-by: Ezekiel Newren <ezekielnewren@gmail.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 dir.c        | 18 ++++++++++--------
 read-cache.c |  6 ++++--
 varint.c     |  6 +++---
 varint.h     |  4 ++--
 4 files changed, 19 insertions(+), 15 deletions(-)

diff --git a/dir.c b/dir.c
index 71108ac79b7..0a67a99cb3d 100644
--- a/dir.c
+++ b/dir.c
@@ -3579,7 +3579,8 @@ static void write_one_dir(struct untracked_cache_dir *untracked,
 	struct stat_data stat_data;
 	struct strbuf *out = &wd->out;
 	unsigned char intbuf[16];
-	unsigned int intlen, value;
+	unsigned int value;
+	uint8_t intlen;
 	int i = wd->index++;
 
 	/*
@@ -3632,7 +3633,7 @@ void write_untracked_extension(struct strbuf *out, struct untracked_cache *untra
 	struct ondisk_untracked_cache *ouc;
 	struct write_data wd;
 	unsigned char varbuf[16];
-	int varint_len;
+	uint8_t varint_len;
 	const unsigned hashsz = the_hash_algo->rawsz;
 
 	CALLOC_ARRAY(ouc, 1);
@@ -3738,7 +3739,7 @@ static int read_one_dir(struct untracked_cache_dir **untracked_,
 	struct untracked_cache_dir ud, *untracked;
 	const unsigned char *data = rd->data, *end = rd->end;
 	const unsigned char *eos;
-	unsigned int value;
+	uint64_t value;
 	int i;
 
 	memset(&ud, 0, sizeof(ud));
@@ -3830,7 +3831,8 @@ struct untracked_cache *read_untracked_extension(const void *data, unsigned long
 	struct read_data rd;
 	const unsigned char *next = data, *end = (const unsigned char *)data + sz;
 	const char *ident;
-	int ident_len;
+	uint64_t ident_len;
+	uint64_t varint_len;
 	ssize_t len;
 	const char *exclude_per_dir;
 	const unsigned hashsz = the_hash_algo->rawsz;
@@ -3867,8 +3869,8 @@ struct untracked_cache *read_untracked_extension(const void *data, unsigned long
 	if (next >= end)
 		goto done2;
 
-	len = decode_varint(&next);
-	if (next > end || len == 0)
+	varint_len = decode_varint(&next);
+	if (next > end || varint_len == 0)
 		goto done2;
 
 	rd.valid      = ewah_new();
@@ -3877,9 +3879,9 @@ struct untracked_cache *read_untracked_extension(const void *data, unsigned long
 	rd.data	      = next;
 	rd.end	      = end;
 	rd.index      = 0;
-	ALLOC_ARRAY(rd.ucd, len);
+	ALLOC_ARRAY(rd.ucd, varint_len);
 
-	if (read_one_dir(&uc->root, &rd) || rd.index != len)
+	if (read_one_dir(&uc->root, &rd) || rd.index != varint_len)
 		goto done;
 
 	next = rd.data;
diff --git a/read-cache.c b/read-cache.c
index 06ad74db228..41b44148b1e 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1807,7 +1807,7 @@ static struct cache_entry *create_from_disk(struct mem_pool *ce_mem_pool,
 
 	if (expand_name_field) {
 		const unsigned char *cp = (const unsigned char *)name;
-		size_t strip_len, previous_len;
+		uint64_t strip_len, previous_len;
 
 		/* If we're at the beginning of a block, ignore the previous name */
 		strip_len = decode_varint(&cp);
@@ -2655,8 +2655,10 @@ static int ce_write_entry(struct hashfile *f, struct cache_entry *ce,
 		hashwrite(f, ce->name, len);
 		hashwrite(f, padding, align_padding_size(size, len));
 	} else {
-		int common, to_remove, prefix_size;
+		int common, to_remove;
+		uint8_t prefix_size;
 		unsigned char to_remove_vi[16];
+
 		for (common = 0;
 		     (common < previous_name->len &&
 		      ce->name[common] &&
diff --git a/varint.c b/varint.c
index 409c4977a1e..03cd54416b6 100644
--- a/varint.c
+++ b/varint.c
@@ -1,11 +1,11 @@
 #include "git-compat-util.h"
 #include "varint.h"
 
-uintmax_t decode_varint(const unsigned char **bufp)
+uint64_t decode_varint(const unsigned char **bufp)
 {
 	const unsigned char *buf = *bufp;
 	unsigned char c = *buf++;
-	uintmax_t val = c & 127;
+	uint64_t val = c & 127;
 	while (c & 128) {
 		val += 1;
 		if (!val || MSB(val, 7))
@@ -17,7 +17,7 @@ uintmax_t decode_varint(const unsigned char **bufp)
 	return val;
 }
 
-int encode_varint(uintmax_t value, unsigned char *buf)
+uint8_t encode_varint(uint64_t value, unsigned char *buf)
 {
 	unsigned char varint[16];
 	unsigned pos = sizeof(varint) - 1;
diff --git a/varint.h b/varint.h
index f78bb0ca528..eb401935bd2 100644
--- a/varint.h
+++ b/varint.h
@@ -1,7 +1,7 @@
 #ifndef VARINT_H
 #define VARINT_H
 
-int encode_varint(uintmax_t, unsigned char *);
-uintmax_t decode_varint(const unsigned char **);
+uint8_t encode_varint(uint64_t, unsigned char *);
+uint64_t decode_varint(const unsigned char **);
 
 #endif /* VARINT_H */

-- 
2.51.0.536.g15c5d4f767.dirty

[PATCH v6 6/9] varint: reimplement as test balloon for Rust

[Patrick Steinhardt]

Implement a trivial test balloon for our Rust build infrastructure by
reimplementing the "varint.c" subsystem in Rust. This subsystem is
chosen because it is trivial to convert and because it doesn't have any
dependencies to other components of Git.

If support for Rust is enabled, we stop compiling "varint.c" and instead
compile and use "src/varint.rs".

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 Makefile        |  3 ++
 meson.build     |  5 +++-
 src/lib.rs      |  1 +
 src/meson.build |  1 +
 src/varint.rs   | 92 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 101 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index e8518198fcb..d7d6f6eefcb 100644
--- a/Makefile
+++ b/Makefile
@@ -1307,7 +1307,9 @@ LIB_OBJS += urlmatch.o
 LIB_OBJS += usage.o
 LIB_OBJS += userdiff.o
 LIB_OBJS += utf8.o
+ifndef WITH_RUST
 LIB_OBJS += varint.o
+endif
 LIB_OBJS += version.o
 LIB_OBJS += versioncmp.o
 LIB_OBJS += walker.o
@@ -1499,6 +1501,7 @@ CLAR_TEST_OBJS += $(UNIT_TEST_DIR)/unit-test.o
 UNIT_TEST_OBJS += $(UNIT_TEST_DIR)/test-lib.o
 
 RUST_SOURCES += src/lib.rs
+RUST_SOURCES += src/varint.rs
 
 GIT-VERSION-FILE: FORCE
 	@OLD=$$(cat $@ 2>/dev/null || :) && \
diff --git a/meson.build b/meson.build
index 234a9e9d6fd..37dfa286017 100644
--- a/meson.build
+++ b/meson.build
@@ -522,7 +522,6 @@ libgit_sources = [
   'usage.c',
   'userdiff.c',
   'utf8.c',
-  'varint.c',
   'version.c',
   'versioncmp.c',
   'walker.c',
@@ -1707,6 +1706,10 @@ rust_option = get_option('rust').disable_auto_if(not cargo.found())
 if rust_option.allowed()
   subdir('src')
   libgit_c_args += '-DWITH_RUST'
+else
+  libgit_sources += [
+    'varint.c',
+  ]
 endif
 
 libgit = declare_dependency(
diff --git a/src/lib.rs b/src/lib.rs
index e69de29bb2d..9da70d8b57d 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -0,0 +1 @@
+pub mod varint;
diff --git a/src/meson.build b/src/meson.build
index 734de0b4fa9..b19ef4c0b51 100644
--- a/src/meson.build
+++ b/src/meson.build
@@ -1,5 +1,6 @@
 libgit_rs_sources = [
   'lib.rs',
+  'varint.rs',
 ]
 
 # Unfortunately we must use a wrapper command to move the output file into the
diff --git a/src/varint.rs b/src/varint.rs
new file mode 100644
index 00000000000..6e610bdd8e0
--- /dev/null
+++ b/src/varint.rs
@@ -0,0 +1,92 @@
+#[no_mangle]
+pub unsafe extern "C" fn decode_varint(bufp: *mut *const u8) -> u64 {
+    let mut buf = *bufp;
+    let mut c = *buf;
+    let mut val = u64::from(c & 127);
+
+    buf = buf.add(1);
+
+    while (c & 128) != 0 {
+        val = val.wrapping_add(1);
+        if val == 0 || val.leading_zeros() < 7 {
+            return 0; // overflow
+        }
+
+        c = *buf;
+        buf = buf.add(1);
+
+        val = (val << 7) + u64::from(c & 127);
+    }
+
+    *bufp = buf;
+    val
+}
+
+#[no_mangle]
+pub unsafe extern "C" fn encode_varint(value: u64, buf: *mut u8) -> u8 {
+    let mut varint: [u8; 16] = [0; 16];
+    let mut pos = varint.len() - 1;
+
+    varint[pos] = (value & 127) as u8;
+
+    let mut value = value >> 7;
+    while value != 0 {
+        pos -= 1;
+        value -= 1;
+        varint[pos] = 128 | (value & 127) as u8;
+        value >>= 7;
+    }
+
+    if !buf.is_null() {
+        std::ptr::copy_nonoverlapping(varint.as_ptr().add(pos), buf, varint.len() - pos);
+    }
+
+    (varint.len() - pos) as u8
+}
+
+#[cfg(test)]
+mod tests {
+    use super::*;
+
+    #[test]
+    fn test_decode_varint() {
+        unsafe {
+            assert_eq!(decode_varint(&mut [0x00].as_slice().as_ptr()), 0);
+            assert_eq!(decode_varint(&mut [0x01].as_slice().as_ptr()), 1);
+            assert_eq!(decode_varint(&mut [0x7f].as_slice().as_ptr()), 127);
+            assert_eq!(decode_varint(&mut [0x80, 0x00].as_slice().as_ptr()), 128);
+            assert_eq!(decode_varint(&mut [0x80, 0x01].as_slice().as_ptr()), 129);
+            assert_eq!(decode_varint(&mut [0x80, 0x7f].as_slice().as_ptr()), 255);
+
+            // Overflows are expected to return 0.
+            assert_eq!(decode_varint(&mut [0x88; 16].as_slice().as_ptr()), 0);
+        }
+    }
+
+    #[test]
+    fn test_encode_varint() {
+        unsafe {
+            let mut varint: [u8; 16] = [0; 16];
+
+            assert_eq!(encode_varint(0, std::ptr::null_mut()), 1);
+
+            assert_eq!(encode_varint(0, varint.as_mut_slice().as_mut_ptr()), 1);
+            assert_eq!(varint, [0; 16]);
+
+            assert_eq!(encode_varint(10, varint.as_mut_slice().as_mut_ptr()), 1);
+            assert_eq!(varint, [10, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+
+            assert_eq!(encode_varint(127, varint.as_mut_slice().as_mut_ptr()), 1);
+            assert_eq!(varint, [127, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+
+            assert_eq!(encode_varint(128, varint.as_mut_slice().as_mut_ptr()), 2);
+            assert_eq!(varint, [128, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+
+            assert_eq!(encode_varint(129, varint.as_mut_slice().as_mut_ptr()), 2);
+            assert_eq!(varint, [128, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+
+            assert_eq!(encode_varint(255, varint.as_mut_slice().as_mut_ptr()), 2);
+            assert_eq!(varint, [128, 127, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+        }
+    }
+}

-- 
2.51.0.536.g15c5d4f767.dirty

[PATCH v6 7/9] BreakingChanges: announce Rust becoming mandatory

[Patrick Steinhardt]

Over the last couple of years the appetite for bringing Rust into the
codebase has grown significantly across the developer base. Introducing
Rust is a major change though and has ramifications for the whole
ecosystem:

  - Some platforms have a Rust toolchain available, but have not yet
    integrated it into their build infrastructure.

  - Some platforms don't have any support for Rust at all.

  - Some platforms may have to figure out how to fit Rust into their
    bootstrapping sequence.

Due to this, and given that Git is a critical piece of infrastructure
for the whole industry, we cannot just introduce such a heavyweight
dependency without doing our due diligence.

Instead, preceding commits have introduced a test balloon into our build
infrastructure that convert one tiny subsystem to use Rust. For now,
using Rust to build that subsystem is entirely optional -- if no Rust
support is available, we continue to use the C implementation. This test
balloon has the intention to give distributions time and let them ease
into our adoption of Rust.

Having multiple implementations of the same subsystem is not sustainable
though, and the plan is to eventually be able to use Rust freely all
across our codebase. As such, there is the intent to make Rust become a
mandatory part of our build process.

Add an announcement to our breaking changes that Rust will become
mandatory in Git 3.0. A (very careful and non-binding) estimate might be
that this major release might be released in the second half of next
year, which should give distributors enough time to prepare for the
change.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 Documentation/BreakingChanges.adoc | 45 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/Documentation/BreakingChanges.adoc b/Documentation/BreakingChanges.adoc
index f8d2eba061..d249e604b5 100644
--- a/Documentation/BreakingChanges.adoc
+++ b/Documentation/BreakingChanges.adoc
@@ -165,6 +165,51 @@ A prerequisite for this change is that the ecosystem is ready to support the
 "reftable" format. Most importantly, alternative implementations of Git like
 JGit, libgit2 and Gitoxide need to support it.
 
+* Git will require Rust as a mandatory part of the build process. While Git
+  already started to adopt Rust in Git 2.49, all parts written in Rust are
+  optional for the time being. This includes:
++
+  ** The Rust wrapper around libgit.a that is part of "contrib/" and which has
+     been introduced in Git 2.49.
+  ** Subsystems that have an alternative implementation in Rust to test
+     interoperability between our C and Rust codebase.
+  ** Newly written features that are not mission critical for a fully functional
+     Git client.
++
+These changes are meant as test balloons to allow distributors of Git to prepare
+for Rust becoming a mandatory part of the build process. There will be multiple
+milestones for the introduction of Rust:
++
+--
+1. Initially, with Git 2.52, support for Rust will be auto-detected by Meson and
+   disabled in our Makefile so that the project can sort out the initial
+   infrastructure.
+2. In Git 2.53, both build systems will default-enable support for Rust.
+   Consequently, builds will break by default if Rust is not available on the
+   build host. The use of Rust can still be explicitly disabled via build
+   flags.
+3. In Git 3.0, the build options will be removed and support for Rust is
+   mandatory.
+--
++
+You can explicitly ask both Meson and our Makefile-based system to enable Rust
+by saying `meson configure -Drust=enabled` and `make WITH_RUST=YesPlease`,
+respectively.
++
+The Git project will declare the last version before Git 3.0 to be a long-term
+support release. This long-term release will receive important bug fixes for at
+least four release cycles and security fixes for six release cycles. The Git
+project will hand over maintainership of the long-term release to distributors
+in case they need to extend the life of that long-term release even further. In
+that case, the backporting process will be handled by these distributors, but
+the long-term release tags will be created in the canonical Git repository.
++
+We will evaluate the impact on downstream distributions before making Rust
+mandatory in Git 3.0. If we see that the impact on downstream distributions
+would be significant, we may decide to defer this breaking change to a
+subsequent minor release. This evaluation will also take into account our own
+learnings with how painful it is to keep Rust an optional component.
+
 === Removals
 
 * Support for grafting commits has long been superseded by git-replace(1).

-- 
2.51.0.536.g15c5d4f767.dirty

Re: [PATCH v6 7/9] BreakingChanges: announce Rust becoming mandatory

[Phillip Wood]

Hi Patrick

On 23/09/2025 10:45, Patrick Steinhardt wrote:
> ++
> +The Git project will declare the last version before Git 3.0 to be a long-term
> +support release. This long-term release will receive important bug fixes for at
> +least four release cycles and security fixes for six release cycles. The Git
> +project will hand over maintainership of the long-term release to distributors
> +in case they need to extend the life of that long-term release even further. In
> +that case, the backporting process will be handled by these distributors, but
> +the long-term release tags will be created in the canonical Git repository.
> ++
> +We will evaluate the impact on downstream distributions before making Rust
> +mandatory in Git 3.0. If we see that the impact on downstream distributions
> +would be significant, we may decide to defer this breaking change to a
> +subsequent minor release. This evaluation will also take into account our own
> +learnings with how painful it is to keep Rust an optional component.

I think this last paragraph is a welcome addition as it makes it clear 
we're not going to blindly pursue rust if it causes widespread problems. 
Personally I'd say "experience" rather than "learnings" but that's 
probably me being a grumpy pedant.

Thanks

Phillip

Re: [PATCH v6 7/9] BreakingChanges: announce Rust becoming mandatory

[Junio C Hamano]

Phillip Wood <phillip.wood123@gmail.com> writes:

>> +We will evaluate the impact on downstream distributions before making Rust
>> +mandatory in Git 3.0. If we see that the impact on downstream distributions
>> +would be significant, we may decide to defer this breaking change to a
>> +subsequent minor release. This evaluation will also take into account our own
>> +learnings with how painful it is to keep Rust an optional component.
>
> I think this last paragraph is a welcome addition as it makes it clear
> we're not going to blindly pursue rust if it causes widespread
> problems. Personally I'd say "experience" rather than "learnings" but
> that's probably me being a grumpy pedant.

If this transition turns out to be way too disruptive even for the
3.0 that promises big changes anyway, can "this breaking change"
realistically be "deferred" to a subsequent "minor" release?

The only way I can think of that is permissible in a minor release
would be to pear it down so much that it no longer is disruptive,
but that would be very different from "this breaking change"
anymore.

Or is this talking about waiting until the downstream distribions
either die out without adding Rust support or start supporting Rust?
That, except for the risk of having to wait forever, might work, but
then to surviving distros, it would no longer be a "breaking" change
even if we ship the same change as "this breaking change", right?

I don't know.  To me, the last sentence sounds like reserving the
right to later say "we learned that trying to support opt-in Rust
component that we have to (partially) replicate in C is so painful,
so we won't keep Rust an optional component".

Re: [PATCH v6 7/9] BreakingChanges: announce Rust becoming mandatory

[Patrick Steinhardt]

On Tue, Sep 23, 2025 at 10:29:46AM -0700, Junio C Hamano wrote:
> Phillip Wood <phillip.wood123@gmail.com> writes:
> 
> >> +We will evaluate the impact on downstream distributions before making Rust
> >> +mandatory in Git 3.0. If we see that the impact on downstream distributions
> >> +would be significant, we may decide to defer this breaking change to a
> >> +subsequent minor release. This evaluation will also take into account our own
> >> +learnings with how painful it is to keep Rust an optional component.
> >
> > I think this last paragraph is a welcome addition as it makes it clear
> > we're not going to blindly pursue rust if it causes widespread
> > problems. Personally I'd say "experience" rather than "learnings" but
> > that's probably me being a grumpy pedant.
> 
> If this transition turns out to be way too disruptive even for the
> 3.0 that promises big changes anyway, can "this breaking change"
> realistically be "deferred" to a subsequent "minor" release?
> 
> The only way I can think of that is permissible in a minor release
> would be to pear it down so much that it no longer is disruptive,
> but that would be very different from "this breaking change"
> anymore.
> 
> Or is this talking about waiting until the downstream distribions
> either die out without adding Rust support or start supporting Rust?
> That, except for the risk of having to wait forever, might work, but
> then to surviving distros, it would no longer be a "breaking" change
> even if we ship the same change as "this breaking change", right?

I guess the answer is "it depends". We're counting on tools like gccrs
and rustc_codegen_c to become viable, as those tools may help us quite
significantly to reduce the blast radius. But "reduce" doesn't
necessarily mean that there are no victims anymore.

I'll slightly reword this to say "this change" instead of "this breaking
change" though.

> I don't know.  To me, the last sentence sounds like reserving the
> right to later say "we learned that trying to support opt-in Rust
> component that we have to (partially) replicate in C is so painful,
> so we won't keep Rust an optional component".

We haven't gained a lot of experience with Rust yet, so I think we
should keep all options open for now. I really want the Rust experiment
to succeed (well, otherwise I wouldn't push this series), but we simply
don't know how it'll play out at this point.

Patrick

[PATCH v6 8/9] ci: convert "pedantic" job into full build with breaking changes

[Patrick Steinhardt]

The "pedantic" CI job is building on Fedora with `DEVOPTS=pedantic`.
This build flag doesn't do anything anymore starting with 6a8cbc41ba
(developer: enable pedantic by default, 2021-09-03), where we have
flipped the default so that developers have to opt-out of pedantic
builds via the "no-pedantic" option. As such, all this job really does
is to do a normal build on Fedora, which isn't all that interesting.

Convert that job into a full build-and-test job that uses Meson with
breaking changes enabled. This plugs two gaps:

  - We now test on another distro that we didn't run tests on
    beforehand.

  - We verify that breaking changes work as expected with Meson.

Furthermore, in a subsequent commit we'll modify both jobs that use
breaking changes to also enable Rust. By converting the Fedora job to
use Meson, we ensure that we test our Rust build infrastructure for both
build systems.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 .github/workflows/main.yml |  4 ++--
 .gitlab-ci.yml             |  4 ++--
 ci/install-dependencies.sh |  6 +++++-
 ci/run-build-and-tests.sh  | 29 ++++++++---------------------
 4 files changed, 17 insertions(+), 26 deletions(-)

diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index d122e79415..393ea4d1cc 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -379,6 +379,8 @@ jobs:
         - jobname: linux-breaking-changes
           cc: gcc
           image: ubuntu:rolling
+        - jobname: fedora-breaking-changes-meson
+          image: fedora:latest
         - jobname: linux-leaks
           image: ubuntu:rolling
           cc: gcc
@@ -396,8 +398,6 @@ jobs:
         # Supported until 2025-04-02.
         - jobname: linux32
           image: i386/ubuntu:focal
-        - jobname: pedantic
-          image: fedora:latest
         # A RHEL 8 compatible distro.  Supported until 2029-05-31.
         - jobname: almalinux-8
           image: almalinux:8
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index af10ebb59a..4248506909 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -45,6 +45,8 @@ test:linux:
       - jobname: linux-breaking-changes
         image: ubuntu:20.04
         CC: gcc
+      - jobname: fedora-breaking-changes-meson
+        image: fedora:latest
       - jobname: linux-TEST-vars
         image: ubuntu:20.04
         CC: gcc
@@ -58,8 +60,6 @@ test:linux:
       - jobname: linux-asan-ubsan
         image: ubuntu:rolling
         CC: clang
-      - jobname: pedantic
-        image: fedora:latest
       - jobname: linux-musl-meson
         image: alpine:latest
       - jobname: linux32
diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh
index d061a47293..35bd05b85b 100755
--- a/ci/install-dependencies.sh
+++ b/ci/install-dependencies.sh
@@ -30,8 +30,12 @@ alpine-*)
 		bash cvs gnupg perl-cgi perl-dbd-sqlite perl-io-tty >/dev/null
 	;;
 fedora-*|almalinux-*)
+	case "$jobname" in
+	*-meson)
+		MESON_DEPS="meson ninja";;
+	esac
 	dnf -yq update >/dev/null &&
-	dnf -yq install shadow-utils sudo make gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null
+	dnf -yq install shadow-utils sudo make pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel $MESON_DEPS >/dev/null
 	;;
 ubuntu-*|i386/ubuntu-*|debian-*)
 	# Required so that apt doesn't wait for user input on certain packages.
diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index 01823fd0f1..3680446649 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -5,12 +5,11 @@
 
 . ${0%/*}/lib.sh
 
-run_tests=t
-
 case "$jobname" in
-linux-breaking-changes)
+fedora-breaking-changes-musl|linux-breaking-changes)
 	export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
 	export WITH_BREAKING_CHANGES=YesPlease
+	MESONFLAGS="$MESONFLAGS -Dbreaking_changes=true"
 	;;
 linux-TEST-vars)
 	export OPENSSL_SHA1_UNSAFE=YesPlease
@@ -36,12 +35,6 @@ linux-sha256)
 linux-reftable|linux-reftable-leaks|osx-reftable)
 	export GIT_TEST_DEFAULT_REF_FORMAT=reftable
 	;;
-pedantic)
-	# Don't run the tests; we only care about whether Git can be
-	# built.
-	export DEVOPTS=pedantic
-	run_tests=
-	;;
 esac
 
 case "$jobname" in
@@ -54,21 +47,15 @@ case "$jobname" in
 		-Dtest_output_directory="${TEST_OUTPUT_DIRECTORY:-$(pwd)/t}" \
 		$MESONFLAGS
 	group "Build" meson compile -C build --
-	if test -n "$run_tests"
-	then
-		group "Run tests" meson test -C build --print-errorlogs --test-args="$GIT_TEST_OPTS" || (
-			./t/aggregate-results.sh "${TEST_OUTPUT_DIRECTORY:-t}/test-results"
-			handle_failed_tests
-		)
-	fi
+	group "Run tests" meson test -C build --print-errorlogs --test-args="$GIT_TEST_OPTS" || (
+		./t/aggregate-results.sh "${TEST_OUTPUT_DIRECTORY:-t}/test-results"
+		handle_failed_tests
+	)
 	;;
 *)
 	group Build make
-	if test -n "$run_tests"
-	then
-		group "Run tests" make test ||
-		handle_failed_tests
-	fi
+	group "Run tests" make test ||
+	handle_failed_tests
 	;;
 esac
 

-- 
2.51.0.536.g15c5d4f767.dirty

[PATCH v6 9/9] ci: enable Rust for breaking-changes jobs

[Patrick Steinhardt]

Enable Rust for our breaking-changes jobs so that we can verify that the
build infrastructure and the converted Rust subsystems work as expected.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 ci/install-dependencies.sh | 4 ++--
 ci/run-build-and-tests.sh  | 2 ++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh
index 35bd05b85b..0d3aa496fc 100755
--- a/ci/install-dependencies.sh
+++ b/ci/install-dependencies.sh
@@ -35,7 +35,7 @@ fedora-*|almalinux-*)
 		MESON_DEPS="meson ninja";;
 	esac
 	dnf -yq update >/dev/null &&
-	dnf -yq install shadow-utils sudo make pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel $MESON_DEPS >/dev/null
+	dnf -yq install shadow-utils sudo make pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel $MESON_DEPS cargo >/dev/null
 	;;
 ubuntu-*|i386/ubuntu-*|debian-*)
 	# Required so that apt doesn't wait for user input on certain packages.
@@ -62,7 +62,7 @@ ubuntu-*|i386/ubuntu-*|debian-*)
 		make libssl-dev libcurl4-openssl-dev libexpat-dev wget sudo default-jre \
 		tcl tk gettext zlib1g-dev perl-modules liberror-perl libauthen-sasl-perl \
 		libemail-valid-perl libio-pty-perl libio-socket-ssl-perl libnet-smtp-ssl-perl libdbd-sqlite3-perl libcgi-pm-perl \
-		libsecret-1-dev libpcre2-dev meson ninja-build pkg-config \
+		libsecret-1-dev libpcre2-dev meson ninja-build pkg-config cargo \
 		${CC_PACKAGE:-${CC:-gcc}} $PYTHON_PACKAGE
 
 	case "$distro" in
diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index 3680446649..c718bd101a 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -9,7 +9,9 @@ case "$jobname" in
 fedora-breaking-changes-musl|linux-breaking-changes)
 	export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
 	export WITH_BREAKING_CHANGES=YesPlease
+	export WITH_RUST=YesPlease
 	MESONFLAGS="$MESONFLAGS -Dbreaking_changes=true"
+	MESONFLAGS="$MESONFLAGS -Drust=enabled"
 	;;
 linux-TEST-vars)
 	export OPENSSL_SHA1_UNSAFE=YesPlease

-- 
2.51.0.536.g15c5d4f767.dirty

Re: [PATCH v6 0/9] Introduce Rust and announce that it will become mandatory

[Ezekiel Newren]

On Tue, Sep 23, 2025 at 3:45 AM Patrick Steinhardt <ps@pks.im> wrote:
Your patch series has 2 critical problems:
  * meson doesn't check for "is windows and using msvc" -> <crate>.lib
else lib<crate>.a
  * Using the name "git" for the crate is problematic because both
Make and Meson already produce libgit.a which is different from the
libgit.a that cargo is producing. Change the name in Cargo.toml from
"git" to "gitcore".

I created some temporary patches on top of this patch series that
always forces Rust and then pushed it to GitHub. The only target that
failed was windows building with meson + msvc, everything else
including the 32 bit linux target passed.

I have some nitpicks about varint, but they're not worth mentioning
here. Fix those 2 points and you'll have my seal of approval for this
patch series.

Re: [PATCH v6 0/9] Introduce Rust and announce that it will become mandatory

[Patrick Steinhardt]

On Tue, Sep 23, 2025 at 02:15:35PM -0600, Ezekiel Newren wrote:
> On Tue, Sep 23, 2025 at 3:45 AM Patrick Steinhardt <ps@pks.im> wrote:
> Your patch series has 2 critical problems:
>   * meson doesn't check for "is windows and using msvc" -> <crate>.lib
> else lib<crate>.a

I didn't wire Windows up yet, so this is a known omission. It's not
handled in the Makefile yet, either. My plan here was to tackle Windows
support as the immediate next step once this patch series lands.

Would that be fine with you?

>   * Using the name "git" for the crate is problematic because both
> Make and Meson already produce libgit.a which is different from the
> libgit.a that cargo is producing. Change the name in Cargo.toml from
> "git" to "gitcore".

I wasn't quite happy with the "git" name anyway, so I'll happily take
"gitcore" instead.

Thanks!

Patrick

Re: [PATCH v6 0/9] Introduce Rust and announce that it will become mandatory

[Ezekiel Newren]

On Tue, Sep 23, 2025 at 11:02 PM Patrick Steinhardt <ps@pks.im> wrote:
>
> On Tue, Sep 23, 2025 at 02:15:35PM -0600, Ezekiel Newren wrote:
> > On Tue, Sep 23, 2025 at 3:45 AM Patrick Steinhardt <ps@pks.im> wrote:
> > Your patch series has 2 critical problems:
> >   * meson doesn't check for "is windows and using msvc" -> <crate>.lib
> > else lib<crate>.a
>
> I didn't wire Windows up yet, so this is a known omission. It's not
> handled in the Makefile yet, either. My plan here was to tackle Windows
> support as the immediate next step once this patch series lands.
>
> Would that be fine with you?

So long as you're aware, I'm fine with it being fixed later. I believe
that Makefile doesn't ever use msvc in the github workflows and you'd
only need to tell meson to look for <crate>.lib since cargo will
produce that if it's using the Rust toolcahin x86_64-pc-windows-msvc.
Also you'd need to update your cargo-meson.sh script to merely look
for <crate>.lib instead of lib<crate>.a and move it.

> >   * Using the name "git" for the crate is problematic because both
> > Make and Meson already produce libgit.a which is different from the
> > libgit.a that cargo is producing. Change the name in Cargo.toml from
> > "git" to "gitcore".
>
> I wasn't quite happy with the "git" name anyway, so I'll happily take
> "gitcore" instead.

Ok.

Thanks.

Ezekiel.

[PATCH v7 0/9] Introduce Rust and announce that it will become mandatory

[Patrick Steinhardt]

Hi,

this small patch series introduces Rust into the core of Git. This patch
series is designed as a test balloon, similar to how we introduced test
balloons for C99 features in the past. The goal is threefold:

  - Give us some time to experiment with Rust and introduce proper build
    infrastructure.

  - Give distributors time to ease into the new toolchain requirements.
    Introducing Rust is impossible for some platforms and hard for
    others.

  - Announce that Git 3.0 will make Rust a mandatory part of our build
    infrastructure.

The test balloon itself is quite uninteresting: I've chosen to convert
the "varint.c" subsystem, mostly because it is trivial and does not have
any dependencies. But it does allow us to verify that C to Rust interop
works as expected, and to play around with tooling. All tests pass with
the "varint.rs" implementation.

For now, the series only contains support for Meson. If we agree to go
down this route I'll also introduce support for Rust into our Makefiles
at a later point in time.

Furthermore missing is additional tooling:

  - At least one CI job to verify that Rust builds and works as
    expected.

  - Tooling and CI jobs to ensure that we have consistent formatting via
    `cargo format`.

And probably lots more. As said, the entire goal is for us to have an
easy playground that we can experiment on and develop the infrastructure
incrementally without yet having to commit to anything.

I'm mostly splitting out the topic of introducing Rust from the larger
series that introduce it into xdiff so that we can focus more on the
actual process of introducing Rust into Git and less on the potential
features that we want to build on top of it.

Changes in v2:
  - Introduce support for building the Rust library via our Makefile.
  - Introduce a '-DWITH_RUST' define. This define is used to print
    whether or not Git is built with Rust via `git version
    --build-options`.
  - Adjust Meson to not depend on v1.9.0 and newer anymore.
  - Introduce a roadmap into our BreakingChanges document to explain how
    we'll iterate towards mandatory Rust support.
  - Rework the Fedora job to do a full compile-and-test run with Meson
    and breaking changes enabled.
  - Adapt our breaking-changes jobs to enable Rust support.
  - Link to v1: https://lore.kernel.org/r/20250904-b4-pks-rust-breaking-change-v1-0-3af1d25e0be9@pks.im

Changes in v3:
  - Reorder all uses of `WITH_RUST` after the include of "config.mak".
  - Add a test to verify overflow behaviour in Rust and explicitly use
    `add_wrapping()`.
  - Use explicit dependencies for the Rust library in our Makefile.
  - Fix Alma Linux CI job.
  - Stop tying maintenance of our LTS release to the availability of
    gcc-rs.
  - Add a fallback to Meson to use cargo directly.
  - I've fixed the Rust edition to 2018 for now. This is intentionally
    conservative so that we might be able to use Rust 1.49. For now, we
    don't have any reason to use a newer edition, either. So let's take
    the oldest version we can live with for now and then bump it as
    required.
  - Link to v2: https://lore.kernel.org/r/20250905-b4-pks-rust-breaking-change-v2-0-6939cbf4a0b8@pks.im

Changes in v4:
  - Convert "varint.c" to use explicit integer width so that we don't
    need to use C types in Rust.
  - Adapt Meson to unconditionally use Cargo.
  - Don't use the unstable `--out-dir` option in Cargo. Instead, we
    resort to a wrapper script in Meson.
  - Shorten the timeline a bit to drop the extra step that ties Rust
    support to `-Dbreaking_changes=true`. This accelerates the timeline
    until distros are made forcibly aware of the upcoming changes in
    Rust.
  - Link to v3: https://lore.kernel.org/r/20250908-b4-pks-rust-breaking-change-v3-0-1cd7189fed3b@pks.im

Changes in v5:
  - Fix indentation in the BreakingChanges document.
  - Fix a commit message typo.
  - Include "Cargo.lock" in the `make clean` target again.
  - Link to v4: https://lore.kernel.org/r/20250910-b4-pks-rust-breaking-change-v4-0-4a63fc69278d@pks.im

Changes in v6:
  - Give attribution to Ezekiel for kickstarting the Rust adoption
    again. I'm happy to change how I do the attribution.
  - Fix "varint.rs" to use `u64` instead of `usize`. Issues like these
    will eventually be catched by cbindgen.
  - Adapt the breaking changes document to mention that we already have
    Rust in our tree starting with Git 2.49.
  - Mention that we won't blindly make Rust mandatory, but consider the
    impact on downstream distributions.
  - Slightly reword how we'll handle LTS maintainership. This probably
    still is an ongoing discussion.
  - Link to v5: https://lore.kernel.org/r/20250915-b4-pks-rust-breaking-change-v5-0-dc3a32fbb216@pks.im

Changes in v7:
  - Rename "git" crate to "gitcore".
  - Some word smithing for the breaking changes doc.
  - Punt on the exact details of how we hand over maintenance of the LTS
    release to the community. This is something we can decide on in the
    future.
  - Link to v6: https://lore.kernel.org/r/20250923-b4-pks-rust-breaking-change-v6-0-59076fee486a@pks.im

Thanks!

Patrick

---
Patrick Steinhardt (9):
      meson: add infrastructure to build internal Rust library
      Makefile: reorder sources after includes
      Makefile: introduce infrastructure to build internal Rust library
      help: report on whether or not Rust is enabled
      varint: use explicit width for integers
      varint: reimplement as test balloon for Rust
      BreakingChanges: announce Rust becoming mandatory
      ci: convert "pedantic" job into full build with breaking changes
      ci: enable Rust for breaking-changes jobs

 .github/workflows/main.yml         |   4 +-
 .gitignore                         |   2 +
 .gitlab-ci.yml                     |   4 +-
 Cargo.toml                         |   9 ++
 Documentation/BreakingChanges.adoc |  45 ++++++++
 Makefile                           | 214 ++++++++++++++++++++++---------------
 ci/install-dependencies.sh         |   8 +-
 ci/run-build-and-tests.sh          |  31 ++----
 dir.c                              |  18 ++--
 help.c                             |   6 ++
 meson.build                        |  15 ++-
 meson_options.txt                  |   2 +
 read-cache.c                       |   6 +-
 shared.mak                         |   1 +
 src/cargo-meson.sh                 |  32 ++++++
 src/lib.rs                         |   1 +
 src/meson.build                    |  41 +++++++
 src/varint.rs                      |  92 ++++++++++++++++
 varint.c                           |   6 +-
 varint.h                           |   4 +-
 20 files changed, 410 insertions(+), 131 deletions(-)

Range-diff versus v6:

 1:  bb793b71e3 !  1:  4c4b07ed93 meson: add infrastructure to build internal Rust library
    @@ Commit message
      ## Cargo.toml (new) ##
     @@
     +[package]
    -+name = "git"
    ++name = "gitcore"
     +version = "0.1.0"
     +edition = "2018"
     +
    @@ src/cargo-meson.sh (new)
     +	exit $RET
     +fi
     +
    -+if ! cmp "$BUILD_DIR/$BUILD_TYPE/libgit.a" "$BUILD_DIR/libgit.a" >/dev/null 2>&1
    ++if ! cmp "$BUILD_DIR/$BUILD_TYPE/libgitcore.a" "$BUILD_DIR/libgitcore.a" >/dev/null 2>&1
     +then
    -+	cp "$BUILD_DIR/$BUILD_TYPE/libgit.a" "$BUILD_DIR/libgit.a"
    ++	cp "$BUILD_DIR/$BUILD_TYPE/libgitcore.a" "$BUILD_DIR/libgitcore.a"
     +fi
     
      ## src/lib.rs (new) ##
    @@ src/meson.build (new)
     +  input: libgit_rs_sources + [
     +    meson.project_source_root() / 'Cargo.toml',
     +  ],
    -+  output: 'libgit.a',
    ++  output: 'libgitcore.a',
     +  command: cargo_command,
     +)
     +libgit_dependencies += declare_dependency(link_with: libgit_rs)
 2:  e3f8101578 =  2:  58633be050 Makefile: reorder sources after includes
 3:  66673f7ce5 !  3:  16300fbeba Makefile: introduce infrastructure to build internal Rust library
    @@ Makefile: TEST_SHELL_PATH = $(SHELL_PATH)
      XDIFF_LIB = xdiff/lib.a
      REFTABLE_LIB = reftable/libreftable.a
     +ifdef DEBUG
    -+RUST_LIB = target/debug/libgit.a
    ++RUST_LIB = target/debug/libgitcore.a
     +else
    -+RUST_LIB = target/release/libgit.a
    ++RUST_LIB = target/release/libgitcore.a
     +endif
      
      # xdiff and reftable libs may in turn depend on what is in libgit.a
 4:  65bcb1233d =  4:  240bc33e56 help: report on whether or not Rust is enabled
 5:  908150d3ea =  5:  43e1f96e06 varint: use explicit width for integers
 6:  8f92ff1e13 =  6:  e9f421bfb6 varint: reimplement as test balloon for Rust
 7:  5e88d4d553 !  7:  73f4a8e639 BreakingChanges: announce Rust becoming mandatory
    @@ Documentation/BreakingChanges.adoc: A prerequisite for this change is that the e
     +support release. This long-term release will receive important bug fixes for at
     +least four release cycles and security fixes for six release cycles. The Git
     +project will hand over maintainership of the long-term release to distributors
    -+in case they need to extend the life of that long-term release even further. In
    -+that case, the backporting process will be handled by these distributors, but
    -+the long-term release tags will be created in the canonical Git repository.
    ++in case they need to extend the life of that long-term release even further.
    ++Details of how this long-term release will be handed over to the community will
    ++be discussed once the Git project decides to stop officially supporting it.
     ++
     +We will evaluate the impact on downstream distributions before making Rust
     +mandatory in Git 3.0. If we see that the impact on downstream distributions
    -+would be significant, we may decide to defer this breaking change to a
    -+subsequent minor release. This evaluation will also take into account our own
    -+learnings with how painful it is to keep Rust an optional component.
    ++would be significant, we may decide to defer this change to a subsequent minor
    ++release. This evaluation will also take into account our own experience with
    ++how painful it is to keep Rust an optional component.
     +
      === Removals
      
 8:  d7d7256a48 =  8:  c1d3c3fcab ci: convert "pedantic" job into full build with breaking changes
 9:  a38eec0af9 =  9:  14271538e3 ci: enable Rust for breaking-changes jobs

---
base-commit: 2462961280690837670d997bde64bd4ebf8ae66d
change-id: 20250904-b4-pks-rust-breaking-change-7167d9d3e37d

[PATCH v7 1/9] meson: add infrastructure to build internal Rust library

[Patrick Steinhardt]

Add the infrastructure into Meson to build an internal Rust library.
Building the Rust parts of Git are for now entirely optional, as they
are mostly intended as a test balloon for both Git developers, but also
for distributors of Git. So for now, they may contain:

  - New features that are not mission critical to Git and that users can
    easily live without.

  - Alternative implementations of small subsystems.

If these test balloons are successful, we will eventually make Rust a
mandatory dependency for our build process in Git 3.0.

The availability of a Rust toolchain will be auto-detected by Meson at
setup time. This behaviour can be tweaked via the `-Drust=` feature
toggle.

Next to the linkable Rust library, also wire up tests that can be
executed via `meson test`. This allows us to use the native unit testing
capabilities of Rust.

Note that the Rust edition is currently set to 2018. This edition is
supported by Rust 1.49, which is the target for the upcoming gcc-rs
backend. For now we don't use any features of Rust that would require a
newer version, so settling on this old version makes sense so that
gcc-rs may become an alternative backend for compiling Git. If we _do_
want to introduce features that were added in more recent editions of
Rust though we should reevaluate that choice.

Inspired-by: Ezekiel Newren <ezekielnewren@gmail.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 Cargo.toml         |  9 +++++++++
 meson.build        | 10 +++++++++-
 meson_options.txt  |  2 ++
 src/cargo-meson.sh | 32 ++++++++++++++++++++++++++++++++
 src/lib.rs         |  0
 src/meson.build    | 40 ++++++++++++++++++++++++++++++++++++++++
 6 files changed, 92 insertions(+), 1 deletion(-)

diff --git a/Cargo.toml b/Cargo.toml
new file mode 100644
index 00000000000..45c9b34981a
--- /dev/null
+++ b/Cargo.toml
@@ -0,0 +1,9 @@
+[package]
+name = "gitcore"
+version = "0.1.0"
+edition = "2018"
+
+[lib]
+crate-type = ["staticlib"]
+
+[dependencies]
diff --git a/meson.build b/meson.build
index e8ec0eca165..234a9e9d6fd 100644
--- a/meson.build
+++ b/meson.build
@@ -220,7 +220,7 @@ project('git', 'c',
   # learned to define __STDC_VERSION__ with C11 and later. We thus require
   # GNU C99 and fall back to C11. Meson only learned to handle the fallback
   # with version 1.3.0, so on older versions we use GNU C99 unconditionally.
-  default_options: meson.version().version_compare('>=1.3.0') ? ['c_std=gnu99,c11'] : ['c_std=gnu99'],
+  default_options: meson.version().version_compare('>=1.3.0') ? ['rust_std=2018', 'c_std=gnu99,c11'] : ['rust_std=2018', 'c_std=gnu99'],
 )
 
 fs = import('fs')
@@ -1702,6 +1702,13 @@ version_def_h = custom_target(
 )
 libgit_sources += version_def_h
 
+cargo = find_program('cargo', dirs: program_path, native: true, required: get_option('rust'))
+rust_option = get_option('rust').disable_auto_if(not cargo.found())
+if rust_option.allowed()
+  subdir('src')
+  libgit_c_args += '-DWITH_RUST'
+endif
+
 libgit = declare_dependency(
   link_with: static_library('git',
     sources: libgit_sources,
@@ -2239,6 +2246,7 @@ summary({
   'pcre2': pcre2,
   'perl': perl_features_enabled,
   'python': target_python.found(),
+  'rust': rust_option.allowed(),
 }, section: 'Auto-detected features', bool_yn: true)
 
 summary({
diff --git a/meson_options.txt b/meson_options.txt
index 1668f260a18..143dee9237c 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -71,6 +71,8 @@ option('zlib_backend', type: 'combo', choices: ['auto', 'zlib', 'zlib-ng'], valu
 # Build tweaks.
 option('breaking_changes', type: 'boolean', value: false,
   description: 'Enable upcoming breaking changes.')
+option('rust', type: 'feature', value: 'auto',
+  description: 'Enable building with Rust.')
 option('macos_use_homebrew_gettext', type: 'boolean', value: true,
   description: 'Use gettext from Homebrew instead of the slightly-broken system-provided one.')
 
diff --git a/src/cargo-meson.sh b/src/cargo-meson.sh
new file mode 100755
index 00000000000..99400986d93
--- /dev/null
+++ b/src/cargo-meson.sh
@@ -0,0 +1,32 @@
+#!/bin/sh
+
+if test "$#" -lt 2
+then
+	exit 1
+fi
+
+SOURCE_DIR="$1"
+BUILD_DIR="$2"
+BUILD_TYPE=debug
+
+shift 2
+
+for arg
+do
+	case "$arg" in
+	--release)
+		BUILD_TYPE=release;;
+	esac
+done
+
+cargo build --lib --quiet --manifest-path="$SOURCE_DIR/Cargo.toml" --target-dir="$BUILD_DIR" "$@"
+RET=$?
+if test $RET -ne 0
+then
+	exit $RET
+fi
+
+if ! cmp "$BUILD_DIR/$BUILD_TYPE/libgitcore.a" "$BUILD_DIR/libgitcore.a" >/dev/null 2>&1
+then
+	cp "$BUILD_DIR/$BUILD_TYPE/libgitcore.a" "$BUILD_DIR/libgitcore.a"
+fi
diff --git a/src/lib.rs b/src/lib.rs
new file mode 100644
index 00000000000..e69de29bb2d
diff --git a/src/meson.build b/src/meson.build
new file mode 100644
index 00000000000..c8d874b2106
--- /dev/null
+++ b/src/meson.build
@@ -0,0 +1,40 @@
+libgit_rs_sources = [
+  'lib.rs',
+]
+
+# Unfortunately we must use a wrapper command to move the output file into the
+# current build directory. This can fixed once `cargo build --artifact-dir`
+# stabilizes. See https://github.com/rust-lang/cargo/issues/6790 for that
+# effort.
+cargo_command = [
+  shell,
+  meson.current_source_dir() / 'cargo-meson.sh',
+  meson.project_source_root(),
+  meson.current_build_dir(),
+]
+if get_option('buildtype') == 'release'
+  cargo_command += '--release'
+endif
+
+libgit_rs = custom_target('git_rs',
+  input: libgit_rs_sources + [
+    meson.project_source_root() / 'Cargo.toml',
+  ],
+  output: 'libgitcore.a',
+  command: cargo_command,
+)
+libgit_dependencies += declare_dependency(link_with: libgit_rs)
+
+if get_option('tests')
+  test('rust', cargo,
+    args: [
+      'test',
+      '--manifest-path',
+      meson.project_source_root() / 'Cargo.toml',
+      '--target-dir',
+      meson.current_build_dir() / 'target',
+    ],
+    timeout: 0,
+    protocol: 'rust',
+  )
+endif

-- 
2.51.0.618.g983fd99d29.dirty

[PATCH v7 2/9] Makefile: reorder sources after includes

[Patrick Steinhardt]

In an upcoming change we'll make some of the sources compile
conditionally based on whether or not `WITH_RUST` is defined. To let
developers specify that flag in their "config.mak" we'll thus have to
reorder our sources so that they come after the include of that file.

Do so.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 Makefile | 176 +++++++++++++++++++++++++++++++--------------------------------
 1 file changed, 88 insertions(+), 88 deletions(-)

diff --git a/Makefile b/Makefile
index 555b7f4dc3..7e52625d75 100644
--- a/Makefile
+++ b/Makefile
@@ -919,6 +919,94 @@ LIB_FILE = libgit.a
 XDIFF_LIB = xdiff/lib.a
 REFTABLE_LIB = reftable/libreftable.a
 
+# xdiff and reftable libs may in turn depend on what is in libgit.a
+GITLIBS = common-main.o $(LIB_FILE) $(XDIFF_LIB) $(REFTABLE_LIB) $(LIB_FILE)
+EXTLIBS =
+
+GIT_USER_AGENT = git/$(GIT_VERSION)
+
+ifeq ($(wildcard sha1collisiondetection/lib/sha1.h),sha1collisiondetection/lib/sha1.h)
+DC_SHA1_SUBMODULE = auto
+endif
+
+# Set CFLAGS, LDFLAGS and other *FLAGS variables. These might be
+# tweaked by config.* below as well as the command-line, both of
+# which'll override these defaults.
+# Older versions of GCC may require adding "-std=gnu99" at the end.
+CFLAGS = -g -O2 -Wall
+LDFLAGS =
+CC_LD_DYNPATH = -Wl,-rpath,
+BASIC_CFLAGS = -I.
+BASIC_LDFLAGS =
+
+# library flags
+ARFLAGS = rcs
+PTHREAD_CFLAGS =
+
+# For the 'sparse' target
+SPARSE_FLAGS ?= -std=gnu99 -D__STDC_NO_VLA__
+SP_EXTRA_FLAGS =
+
+# For informing GIT-BUILD-OPTIONS of the SANITIZE=leak,address targets
+SANITIZE_LEAK =
+SANITIZE_ADDRESS =
+
+# For the 'coccicheck' target
+SPATCH_INCLUDE_FLAGS = --all-includes
+SPATCH_FLAGS =
+SPATCH_TEST_FLAGS =
+
+# If *.o files are present, have "coccicheck" depend on them, with
+# COMPUTE_HEADER_DEPENDENCIES this will speed up the common-case of
+# only needing to re-generate coccicheck results for the users of a
+# given API if it's changed, and not all files in the project. If
+# COMPUTE_HEADER_DEPENDENCIES=no this will be unset too.
+SPATCH_USE_O_DEPENDENCIES = YesPlease
+
+# Set SPATCH_CONCAT_COCCI to concatenate the contrib/cocci/*.cocci
+# files into a single contrib/cocci/ALL.cocci before running
+# "coccicheck".
+#
+# Pros:
+#
+# - Speeds up a one-shot run of "make coccicheck", as we won't have to
+#   parse *.[ch] files N times for the N *.cocci rules
+#
+# Cons:
+#
+# - Will make incremental development of *.cocci slower, as
+#   e.g. changing strbuf.cocci will re-run all *.cocci.
+#
+# - Makes error and performance analysis harder, as rules will be
+#   applied from a monolithic ALL.cocci, rather than
+#   e.g. strbuf.cocci. To work around this either undefine this, or
+#   generate a specific patch, e.g. this will always use strbuf.cocci,
+#   not ALL.cocci:
+#
+#	make contrib/coccinelle/strbuf.cocci.patch
+SPATCH_CONCAT_COCCI = YesPlease
+
+# Rebuild 'coccicheck' if $(SPATCH), its flags etc. change
+TRACK_SPATCH_DEFINES =
+TRACK_SPATCH_DEFINES += $(SPATCH)
+TRACK_SPATCH_DEFINES += $(SPATCH_INCLUDE_FLAGS)
+TRACK_SPATCH_DEFINES += $(SPATCH_FLAGS)
+TRACK_SPATCH_DEFINES += $(SPATCH_TEST_FLAGS)
+GIT-SPATCH-DEFINES: FORCE
+	@FLAGS='$(TRACK_SPATCH_DEFINES)'; \
+	    if test x"$$FLAGS" != x"`cat GIT-SPATCH-DEFINES 2>/dev/null`" ; then \
+		echo >&2 "    * new spatch flags"; \
+		echo "$$FLAGS" >GIT-SPATCH-DEFINES; \
+            fi
+
+include config.mak.uname
+-include config.mak.autogen
+-include config.mak
+
+ifdef DEVELOPER
+include config.mak.dev
+endif
+
 GENERATED_H += command-list.h
 GENERATED_H += config-list.h
 GENERATED_H += hook-list.h
@@ -1387,94 +1475,6 @@ CLAR_TEST_OBJS += $(UNIT_TEST_DIR)/unit-test.o
 
 UNIT_TEST_OBJS += $(UNIT_TEST_DIR)/test-lib.o
 
-# xdiff and reftable libs may in turn depend on what is in libgit.a
-GITLIBS = common-main.o $(LIB_FILE) $(XDIFF_LIB) $(REFTABLE_LIB) $(LIB_FILE)
-EXTLIBS =
-
-GIT_USER_AGENT = git/$(GIT_VERSION)
-
-ifeq ($(wildcard sha1collisiondetection/lib/sha1.h),sha1collisiondetection/lib/sha1.h)
-DC_SHA1_SUBMODULE = auto
-endif
-
-# Set CFLAGS, LDFLAGS and other *FLAGS variables. These might be
-# tweaked by config.* below as well as the command-line, both of
-# which'll override these defaults.
-# Older versions of GCC may require adding "-std=gnu99" at the end.
-CFLAGS = -g -O2 -Wall
-LDFLAGS =
-CC_LD_DYNPATH = -Wl,-rpath,
-BASIC_CFLAGS = -I.
-BASIC_LDFLAGS =
-
-# library flags
-ARFLAGS = rcs
-PTHREAD_CFLAGS =
-
-# For the 'sparse' target
-SPARSE_FLAGS ?= -std=gnu99 -D__STDC_NO_VLA__
-SP_EXTRA_FLAGS =
-
-# For informing GIT-BUILD-OPTIONS of the SANITIZE=leak,address targets
-SANITIZE_LEAK =
-SANITIZE_ADDRESS =
-
-# For the 'coccicheck' target
-SPATCH_INCLUDE_FLAGS = --all-includes
-SPATCH_FLAGS =
-SPATCH_TEST_FLAGS =
-
-# If *.o files are present, have "coccicheck" depend on them, with
-# COMPUTE_HEADER_DEPENDENCIES this will speed up the common-case of
-# only needing to re-generate coccicheck results for the users of a
-# given API if it's changed, and not all files in the project. If
-# COMPUTE_HEADER_DEPENDENCIES=no this will be unset too.
-SPATCH_USE_O_DEPENDENCIES = YesPlease
-
-# Set SPATCH_CONCAT_COCCI to concatenate the contrib/cocci/*.cocci
-# files into a single contrib/cocci/ALL.cocci before running
-# "coccicheck".
-#
-# Pros:
-#
-# - Speeds up a one-shot run of "make coccicheck", as we won't have to
-#   parse *.[ch] files N times for the N *.cocci rules
-#
-# Cons:
-#
-# - Will make incremental development of *.cocci slower, as
-#   e.g. changing strbuf.cocci will re-run all *.cocci.
-#
-# - Makes error and performance analysis harder, as rules will be
-#   applied from a monolithic ALL.cocci, rather than
-#   e.g. strbuf.cocci. To work around this either undefine this, or
-#   generate a specific patch, e.g. this will always use strbuf.cocci,
-#   not ALL.cocci:
-#
-#	make contrib/coccinelle/strbuf.cocci.patch
-SPATCH_CONCAT_COCCI = YesPlease
-
-# Rebuild 'coccicheck' if $(SPATCH), its flags etc. change
-TRACK_SPATCH_DEFINES =
-TRACK_SPATCH_DEFINES += $(SPATCH)
-TRACK_SPATCH_DEFINES += $(SPATCH_INCLUDE_FLAGS)
-TRACK_SPATCH_DEFINES += $(SPATCH_FLAGS)
-TRACK_SPATCH_DEFINES += $(SPATCH_TEST_FLAGS)
-GIT-SPATCH-DEFINES: FORCE
-	@FLAGS='$(TRACK_SPATCH_DEFINES)'; \
-	    if test x"$$FLAGS" != x"`cat GIT-SPATCH-DEFINES 2>/dev/null`" ; then \
-		echo >&2 "    * new spatch flags"; \
-		echo "$$FLAGS" >GIT-SPATCH-DEFINES; \
-            fi
-
-include config.mak.uname
--include config.mak.autogen
--include config.mak
-
-ifdef DEVELOPER
-include config.mak.dev
-endif
-
 GIT-VERSION-FILE: FORCE
 	@OLD=$$(cat $@ 2>/dev/null || :) && \
 	$(call version_gen,"$(shell pwd)",GIT-VERSION-FILE.in,$@) && \

-- 
2.51.0.618.g983fd99d29.dirty

Re: [PATCH v7 2/9] Makefile: reorder sources after includes

[Ramsay Jones]

On 25/09/2025 7:30 am, Patrick Steinhardt wrote:
> In an upcoming change we'll make some of the sources compile
> conditionally based on whether or not `WITH_RUST` is defined. To let
> developers specify that flag in their "config.mak" we'll thus have to
> reorder our sources so that they come after the include of that file.
> 
> Do so.

Yep, I have a very similar patch which I used recently on cygwin so that
I could just 'make' git - having to remember to type 'make WITH_RUST=false'
all the time (and always forgetting) was somewhat annoying! :)

So, thanks for that!

ATB,
Ramsay Jones

[PATCH v7 3/9] Makefile: introduce infrastructure to build internal Rust library

[Patrick Steinhardt]

Introduce infrastructure to build the internal Rust library. This
mirrors the infrastructure we have added to Meson in the preceding
commit. Developers can enable the infrastructure by passing the new
`WITH_RUST` build toggle.

Inspired-by: Ezekiel Newren <ezekielnewren@gmail.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 .gitignore |  2 ++
 Makefile   | 37 +++++++++++++++++++++++++++++++++++++
 shared.mak |  1 +
 3 files changed, 40 insertions(+)

diff --git a/.gitignore b/.gitignore
index 1803023427..0833453cf6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,4 +1,6 @@
 /fuzz_corpora
+/target/
+/Cargo.lock
 /GIT-BUILD-DIR
 /GIT-BUILD-OPTIONS
 /GIT-CFLAGS
diff --git a/Makefile b/Makefile
index 7e52625d75..31e79342e1 100644
--- a/Makefile
+++ b/Makefile
@@ -483,6 +483,14 @@ include shared.mak
 # Define LIBPCREDIR=/foo/bar if your PCRE header and library files are
 # in /foo/bar/include and /foo/bar/lib directories.
 #
+# == Optional Rust support ==
+#
+# Define WITH_RUST if you want to include features and subsystems written in
+# Rust into Git. For now, Rust is still an optional feature of the build
+# process. With Git 3.0 though, Rust will always be enabled.
+#
+# Building Rust code requires Cargo.
+#
 # == SHA-1 and SHA-256 defines ==
 #
 # === SHA-1 backend ===
@@ -683,6 +691,7 @@ OBJECTS =
 OTHER_PROGRAMS =
 PROGRAM_OBJS =
 PROGRAMS =
+RUST_SOURCES =
 EXCLUDED_PROGRAMS =
 SCRIPT_PERL =
 SCRIPT_PYTHON =
@@ -918,6 +927,11 @@ TEST_SHELL_PATH = $(SHELL_PATH)
 LIB_FILE = libgit.a
 XDIFF_LIB = xdiff/lib.a
 REFTABLE_LIB = reftable/libreftable.a
+ifdef DEBUG
+RUST_LIB = target/debug/libgitcore.a
+else
+RUST_LIB = target/release/libgitcore.a
+endif
 
 # xdiff and reftable libs may in turn depend on what is in libgit.a
 GITLIBS = common-main.o $(LIB_FILE) $(XDIFF_LIB) $(REFTABLE_LIB) $(LIB_FILE)
@@ -943,6 +957,15 @@ BASIC_LDFLAGS =
 ARFLAGS = rcs
 PTHREAD_CFLAGS =
 
+# Rust flags
+CARGO_ARGS =
+ifndef V
+CARGO_ARGS += --quiet
+endif
+ifndef DEBUG
+CARGO_ARGS += --release
+endif
+
 # For the 'sparse' target
 SPARSE_FLAGS ?= -std=gnu99 -D__STDC_NO_VLA__
 SP_EXTRA_FLAGS =
@@ -1475,6 +1498,8 @@ CLAR_TEST_OBJS += $(UNIT_TEST_DIR)/unit-test.o
 
 UNIT_TEST_OBJS += $(UNIT_TEST_DIR)/test-lib.o
 
+RUST_SOURCES += src/lib.rs
+
 GIT-VERSION-FILE: FORCE
 	@OLD=$$(cat $@ 2>/dev/null || :) && \
 	$(call version_gen,"$(shell pwd)",GIT-VERSION-FILE.in,$@) && \
@@ -1504,6 +1529,11 @@ endif
 ALL_CFLAGS = $(DEVELOPER_CFLAGS) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_APPEND)
 ALL_LDFLAGS = $(LDFLAGS) $(LDFLAGS_APPEND)
 
+ifdef WITH_RUST
+BASIC_CFLAGS += -DWITH_RUST
+GITLIBS += $(RUST_LIB)
+endif
+
 ifdef SANITIZE
 SANITIZERS := $(foreach flag,$(subst $(comma),$(space),$(SANITIZE)),$(flag))
 BASIC_CFLAGS += -fsanitize=$(SANITIZE) -fno-sanitize-recover=$(SANITIZE)
@@ -2918,6 +2948,12 @@ scalar$X: scalar.o GIT-LDFLAGS $(GITLIBS)
 $(LIB_FILE): $(LIB_OBJS)
 	$(QUIET_AR)$(RM) $@ && $(AR) $(ARFLAGS) $@ $^
 
+$(RUST_LIB): Cargo.toml $(RUST_SOURCES)
+	$(QUIET_CARGO)cargo build $(CARGO_ARGS)
+
+.PHONY: rust
+rust: $(RUST_LIB)
+
 $(XDIFF_LIB): $(XDIFF_OBJS)
 	$(QUIET_AR)$(RM) $@ && $(AR) $(ARFLAGS) $@ $^
 
@@ -3768,6 +3804,7 @@ clean: profile-clean coverage-clean cocciclean
 	$(RM) $(FUZZ_PROGRAMS)
 	$(RM) $(SP_OBJ)
 	$(RM) $(HCC)
+	$(RM) -r Cargo.lock target/
 	$(RM) version-def.h
 	$(RM) -r $(dep_dirs) $(compdb_dir) compile_commands.json
 	$(RM) $(test_bindir_programs)
diff --git a/shared.mak b/shared.mak
index 5c7bc94785..0e7492076e 100644
--- a/shared.mak
+++ b/shared.mak
@@ -56,6 +56,7 @@ ifndef V
 	QUIET_MKDIR_P_PARENT  = @echo '   ' MKDIR -p $(@D);
 
 ## Used in "Makefile"
+	QUIET_CARGO    = @echo '   ' CARGO $@;
 	QUIET_CC       = @echo '   ' CC $@;
 	QUIET_AR       = @echo '   ' AR $@;
 	QUIET_LINK     = @echo '   ' LINK $@;

-- 
2.51.0.618.g983fd99d29.dirty

[PATCH v7 4/9] help: report on whether or not Rust is enabled

[Patrick Steinhardt]

We're about to introduce support for Rust into the core of Git, where
some (trivial) subsystems are converted to Rust. These subsystems will
also retain a C implementation though as Rust is not yet mandatory.
Consequently, it now becomes possible for a Git version to have bugs
that are specific to whether or not it is built with Rust support
overall.

Expose information about whether or not Git was built with Rust via our
build info. This means that both `git version --build-options`, but also
`git bugreport` will now expose that bit of information. Hopefully, this
should make it easier for us to discover any Rust-specific issues.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 help.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/help.c b/help.c
index bb20498cfd..5854dd4a7e 100644
--- a/help.c
+++ b/help.c
@@ -791,6 +791,12 @@ void get_version_info(struct strbuf *buf, int show_build_options)
 		strbuf_addf(buf, "shell-path: %s\n", SHELL_PATH);
 		/* NEEDSWORK: also save and output GIT-BUILD_OPTIONS? */
 
+#if defined WITH_RUST
+		strbuf_addstr(buf, "rust: enabled\n");
+#else
+		strbuf_addstr(buf, "rust: disabled\n");
+#endif
+
 		if (fsmonitor_ipc__is_supported())
 			strbuf_addstr(buf, "feature: fsmonitor--daemon\n");
 #if defined LIBCURL_VERSION

-- 
2.51.0.618.g983fd99d29.dirty

[PATCH v7 5/9] varint: use explicit width for integers

[Patrick Steinhardt]

The varint subsystem currently uses implcit widths for integers. On the
one hand we use `uintmax_t` for the actual value. On the other hand, we
use `int` for the length of the encoded varint.

Both of these have known maximum vaules, as we only support at most 16
bytes when encoding varints. Thus, we know that we won't ever exceed
`uint64_t` for the actual value and `uint8_t` for the prefix length.

Refactor the code to use explicit widths. Besides making the logic
platform-independent, it also makes our life a bit easier in the next
commit, where we reimplement "varint.c" in Rust.

Suggested-by: Ezekiel Newren <ezekielnewren@gmail.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 dir.c        | 18 ++++++++++--------
 read-cache.c |  6 ++++--
 varint.c     |  6 +++---
 varint.h     |  4 ++--
 4 files changed, 19 insertions(+), 15 deletions(-)

diff --git a/dir.c b/dir.c
index 71108ac79b7..0a67a99cb3d 100644
--- a/dir.c
+++ b/dir.c
@@ -3579,7 +3579,8 @@ static void write_one_dir(struct untracked_cache_dir *untracked,
 	struct stat_data stat_data;
 	struct strbuf *out = &wd->out;
 	unsigned char intbuf[16];
-	unsigned int intlen, value;
+	unsigned int value;
+	uint8_t intlen;
 	int i = wd->index++;
 
 	/*
@@ -3632,7 +3633,7 @@ void write_untracked_extension(struct strbuf *out, struct untracked_cache *untra
 	struct ondisk_untracked_cache *ouc;
 	struct write_data wd;
 	unsigned char varbuf[16];
-	int varint_len;
+	uint8_t varint_len;
 	const unsigned hashsz = the_hash_algo->rawsz;
 
 	CALLOC_ARRAY(ouc, 1);
@@ -3738,7 +3739,7 @@ static int read_one_dir(struct untracked_cache_dir **untracked_,
 	struct untracked_cache_dir ud, *untracked;
 	const unsigned char *data = rd->data, *end = rd->end;
 	const unsigned char *eos;
-	unsigned int value;
+	uint64_t value;
 	int i;
 
 	memset(&ud, 0, sizeof(ud));
@@ -3830,7 +3831,8 @@ struct untracked_cache *read_untracked_extension(const void *data, unsigned long
 	struct read_data rd;
 	const unsigned char *next = data, *end = (const unsigned char *)data + sz;
 	const char *ident;
-	int ident_len;
+	uint64_t ident_len;
+	uint64_t varint_len;
 	ssize_t len;
 	const char *exclude_per_dir;
 	const unsigned hashsz = the_hash_algo->rawsz;
@@ -3867,8 +3869,8 @@ struct untracked_cache *read_untracked_extension(const void *data, unsigned long
 	if (next >= end)
 		goto done2;
 
-	len = decode_varint(&next);
-	if (next > end || len == 0)
+	varint_len = decode_varint(&next);
+	if (next > end || varint_len == 0)
 		goto done2;
 
 	rd.valid      = ewah_new();
@@ -3877,9 +3879,9 @@ struct untracked_cache *read_untracked_extension(const void *data, unsigned long
 	rd.data	      = next;
 	rd.end	      = end;
 	rd.index      = 0;
-	ALLOC_ARRAY(rd.ucd, len);
+	ALLOC_ARRAY(rd.ucd, varint_len);
 
-	if (read_one_dir(&uc->root, &rd) || rd.index != len)
+	if (read_one_dir(&uc->root, &rd) || rd.index != varint_len)
 		goto done;
 
 	next = rd.data;
diff --git a/read-cache.c b/read-cache.c
index 06ad74db228..41b44148b1e 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1807,7 +1807,7 @@ static struct cache_entry *create_from_disk(struct mem_pool *ce_mem_pool,
 
 	if (expand_name_field) {
 		const unsigned char *cp = (const unsigned char *)name;
-		size_t strip_len, previous_len;
+		uint64_t strip_len, previous_len;
 
 		/* If we're at the beginning of a block, ignore the previous name */
 		strip_len = decode_varint(&cp);
@@ -2655,8 +2655,10 @@ static int ce_write_entry(struct hashfile *f, struct cache_entry *ce,
 		hashwrite(f, ce->name, len);
 		hashwrite(f, padding, align_padding_size(size, len));
 	} else {
-		int common, to_remove, prefix_size;
+		int common, to_remove;
+		uint8_t prefix_size;
 		unsigned char to_remove_vi[16];
+
 		for (common = 0;
 		     (common < previous_name->len &&
 		      ce->name[common] &&
diff --git a/varint.c b/varint.c
index 409c4977a1e..03cd54416b6 100644
--- a/varint.c
+++ b/varint.c
@@ -1,11 +1,11 @@
 #include "git-compat-util.h"
 #include "varint.h"
 
-uintmax_t decode_varint(const unsigned char **bufp)
+uint64_t decode_varint(const unsigned char **bufp)
 {
 	const unsigned char *buf = *bufp;
 	unsigned char c = *buf++;
-	uintmax_t val = c & 127;
+	uint64_t val = c & 127;
 	while (c & 128) {
 		val += 1;
 		if (!val || MSB(val, 7))
@@ -17,7 +17,7 @@ uintmax_t decode_varint(const unsigned char **bufp)
 	return val;
 }
 
-int encode_varint(uintmax_t value, unsigned char *buf)
+uint8_t encode_varint(uint64_t value, unsigned char *buf)
 {
 	unsigned char varint[16];
 	unsigned pos = sizeof(varint) - 1;
diff --git a/varint.h b/varint.h
index f78bb0ca528..eb401935bd2 100644
--- a/varint.h
+++ b/varint.h
@@ -1,7 +1,7 @@
 #ifndef VARINT_H
 #define VARINT_H
 
-int encode_varint(uintmax_t, unsigned char *);
-uintmax_t decode_varint(const unsigned char **);
+uint8_t encode_varint(uint64_t, unsigned char *);
+uint64_t decode_varint(const unsigned char **);
 
 #endif /* VARINT_H */

-- 
2.51.0.618.g983fd99d29.dirty

Re: [PATCH v7 5/9] varint: use explicit width for integers

[Kristoffer Haugsbakk]

On Thu, Sep 25, 2025, at 08:30, Patrick Steinhardt wrote:
> The varint subsystem currently uses implcit widths for integers. On the

s/implcit/implicit/

> one hand we use `uintmax_t` for the actual value. On the other hand, we
> use `int` for the length of the encoded varint.
>
> Both of these have known maximum vaules, as we only support at most 16

s/vaules/values/

> bytes when encoding varints. Thus, we know that we won't ever exceed
> `uint64_t` for the actual value and `uint8_t` for the prefix length.
>[snip]

Re: [PATCH v7 5/9] varint: use explicit width for integers

[Ezekiel Newren]

On Tue, Sep 30, 2025 at 7:34 AM Kristoffer Haugsbakk
<kristofferhaugsbakk@fastmail.com> wrote:
>
> On Thu, Sep 25, 2025, at 08:30, Patrick Steinhardt wrote:
> > The varint subsystem currently uses implcit widths for integers. On the
>
> s/implcit/implicit/
>
> > one hand we use `uintmax_t` for the actual value. On the other hand, we
> > use `int` for the length of the encoded varint.
> >
> > Both of these have known maximum vaules, as we only support at most 16
>
> s/vaules/values/

Other than the typos this looks good.

Re: [PATCH v7 5/9] varint: use explicit width for integers

[Patrick Steinhardt]

On Wed, Oct 01, 2025 at 11:22:44AM -0600, Ezekiel Newren wrote:
> On Tue, Sep 30, 2025 at 7:34 AM Kristoffer Haugsbakk
> <kristofferhaugsbakk@fastmail.com> wrote:
> >
> > On Thu, Sep 25, 2025, at 08:30, Patrick Steinhardt wrote:
> > > The varint subsystem currently uses implcit widths for integers. On the
> >
> > s/implcit/implicit/
> >
> > > one hand we use `uintmax_t` for the actual value. On the other hand, we
> > > use `int` for the length of the encoded varint.
> > >
> > > Both of these have known maximum vaules, as we only support at most 16
> >
> > s/vaules/values/
> 
> Other than the typos this looks good.

Thanks, both of you! I'll send another (hopefully the last) iteration
now. Guess we'll now have to decide whether we want to try this Rust
experiment or not.

Patrick

[PATCH v7 6/9] varint: reimplement as test balloon for Rust

[Patrick Steinhardt]

Implement a trivial test balloon for our Rust build infrastructure by
reimplementing the "varint.c" subsystem in Rust. This subsystem is
chosen because it is trivial to convert and because it doesn't have any
dependencies to other components of Git.

If support for Rust is enabled, we stop compiling "varint.c" and instead
compile and use "src/varint.rs".

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 Makefile        |  3 ++
 meson.build     |  5 +++-
 src/lib.rs      |  1 +
 src/meson.build |  1 +
 src/varint.rs   | 92 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 101 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 31e79342e1d..2a7fc5cb1f3 100644
--- a/Makefile
+++ b/Makefile
@@ -1307,7 +1307,9 @@ LIB_OBJS += urlmatch.o
 LIB_OBJS += usage.o
 LIB_OBJS += userdiff.o
 LIB_OBJS += utf8.o
+ifndef WITH_RUST
 LIB_OBJS += varint.o
+endif
 LIB_OBJS += version.o
 LIB_OBJS += versioncmp.o
 LIB_OBJS += walker.o
@@ -1499,6 +1501,7 @@ CLAR_TEST_OBJS += $(UNIT_TEST_DIR)/unit-test.o
 UNIT_TEST_OBJS += $(UNIT_TEST_DIR)/test-lib.o
 
 RUST_SOURCES += src/lib.rs
+RUST_SOURCES += src/varint.rs
 
 GIT-VERSION-FILE: FORCE
 	@OLD=$$(cat $@ 2>/dev/null || :) && \
diff --git a/meson.build b/meson.build
index 234a9e9d6fd..37dfa286017 100644
--- a/meson.build
+++ b/meson.build
@@ -522,7 +522,6 @@ libgit_sources = [
   'usage.c',
   'userdiff.c',
   'utf8.c',
-  'varint.c',
   'version.c',
   'versioncmp.c',
   'walker.c',
@@ -1707,6 +1706,10 @@ rust_option = get_option('rust').disable_auto_if(not cargo.found())
 if rust_option.allowed()
   subdir('src')
   libgit_c_args += '-DWITH_RUST'
+else
+  libgit_sources += [
+    'varint.c',
+  ]
 endif
 
 libgit = declare_dependency(
diff --git a/src/lib.rs b/src/lib.rs
index e69de29bb2d..9da70d8b57d 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -0,0 +1 @@
+pub mod varint;
diff --git a/src/meson.build b/src/meson.build
index c8d874b2106..25b9ad5a147 100644
--- a/src/meson.build
+++ b/src/meson.build
@@ -1,5 +1,6 @@
 libgit_rs_sources = [
   'lib.rs',
+  'varint.rs',
 ]
 
 # Unfortunately we must use a wrapper command to move the output file into the
diff --git a/src/varint.rs b/src/varint.rs
new file mode 100644
index 00000000000..6e610bdd8e0
--- /dev/null
+++ b/src/varint.rs
@@ -0,0 +1,92 @@
+#[no_mangle]
+pub unsafe extern "C" fn decode_varint(bufp: *mut *const u8) -> u64 {
+    let mut buf = *bufp;
+    let mut c = *buf;
+    let mut val = u64::from(c & 127);
+
+    buf = buf.add(1);
+
+    while (c & 128) != 0 {
+        val = val.wrapping_add(1);
+        if val == 0 || val.leading_zeros() < 7 {
+            return 0; // overflow
+        }
+
+        c = *buf;
+        buf = buf.add(1);
+
+        val = (val << 7) + u64::from(c & 127);
+    }
+
+    *bufp = buf;
+    val
+}
+
+#[no_mangle]
+pub unsafe extern "C" fn encode_varint(value: u64, buf: *mut u8) -> u8 {
+    let mut varint: [u8; 16] = [0; 16];
+    let mut pos = varint.len() - 1;
+
+    varint[pos] = (value & 127) as u8;
+
+    let mut value = value >> 7;
+    while value != 0 {
+        pos -= 1;
+        value -= 1;
+        varint[pos] = 128 | (value & 127) as u8;
+        value >>= 7;
+    }
+
+    if !buf.is_null() {
+        std::ptr::copy_nonoverlapping(varint.as_ptr().add(pos), buf, varint.len() - pos);
+    }
+
+    (varint.len() - pos) as u8
+}
+
+#[cfg(test)]
+mod tests {
+    use super::*;
+
+    #[test]
+    fn test_decode_varint() {
+        unsafe {
+            assert_eq!(decode_varint(&mut [0x00].as_slice().as_ptr()), 0);
+            assert_eq!(decode_varint(&mut [0x01].as_slice().as_ptr()), 1);
+            assert_eq!(decode_varint(&mut [0x7f].as_slice().as_ptr()), 127);
+            assert_eq!(decode_varint(&mut [0x80, 0x00].as_slice().as_ptr()), 128);
+            assert_eq!(decode_varint(&mut [0x80, 0x01].as_slice().as_ptr()), 129);
+            assert_eq!(decode_varint(&mut [0x80, 0x7f].as_slice().as_ptr()), 255);
+
+            // Overflows are expected to return 0.
+            assert_eq!(decode_varint(&mut [0x88; 16].as_slice().as_ptr()), 0);
+        }
+    }
+
+    #[test]
+    fn test_encode_varint() {
+        unsafe {
+            let mut varint: [u8; 16] = [0; 16];
+
+            assert_eq!(encode_varint(0, std::ptr::null_mut()), 1);
+
+            assert_eq!(encode_varint(0, varint.as_mut_slice().as_mut_ptr()), 1);
+            assert_eq!(varint, [0; 16]);
+
+            assert_eq!(encode_varint(10, varint.as_mut_slice().as_mut_ptr()), 1);
+            assert_eq!(varint, [10, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+
+            assert_eq!(encode_varint(127, varint.as_mut_slice().as_mut_ptr()), 1);
+            assert_eq!(varint, [127, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+
+            assert_eq!(encode_varint(128, varint.as_mut_slice().as_mut_ptr()), 2);
+            assert_eq!(varint, [128, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+
+            assert_eq!(encode_varint(129, varint.as_mut_slice().as_mut_ptr()), 2);
+            assert_eq!(varint, [128, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+
+            assert_eq!(encode_varint(255, varint.as_mut_slice().as_mut_ptr()), 2);
+            assert_eq!(varint, [128, 127, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+        }
+    }
+}

-- 
2.51.0.618.g983fd99d29.dirty

Re: [PATCH v7 6/9] varint: reimplement as test balloon for Rust

[Ezekiel Newren]

On Thu, Sep 25, 2025 at 12:30 AM Patrick Steinhardt <ps@pks.im> wrote:
>  Makefile        |  3 ++
>  meson.build     |  5 +++-
>  src/lib.rs      |  1 +
>  src/meson.build |  1 +
>  src/varint.rs   | 92 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  5 files changed, 101 insertions(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index 31e79342e1d..2a7fc5cb1f3 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1307,7 +1307,9 @@ LIB_OBJS += urlmatch.o
>  LIB_OBJS += usage.o
>  LIB_OBJS += userdiff.o
>  LIB_OBJS += utf8.o
> +ifndef WITH_RUST
>  LIB_OBJS += varint.o
> +endif
>  LIB_OBJS += version.o
>  LIB_OBJS += versioncmp.o
>  LIB_OBJS += walker.o
> @@ -1499,6 +1501,7 @@ CLAR_TEST_OBJS += $(UNIT_TEST_DIR)/unit-test.o
>  UNIT_TEST_OBJS += $(UNIT_TEST_DIR)/test-lib.o
>
>  RUST_SOURCES += src/lib.rs
> +RUST_SOURCES += src/varint.rs
>
>  GIT-VERSION-FILE: FORCE
>         @OLD=$$(cat $@ 2>/dev/null || :) && \
> diff --git a/meson.build b/meson.build
> index 234a9e9d6fd..37dfa286017 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -522,7 +522,6 @@ libgit_sources = [
>    'usage.c',
>    'userdiff.c',
>    'utf8.c',
> -  'varint.c',
>    'version.c',
>    'versioncmp.c',
>    'walker.c',
> @@ -1707,6 +1706,10 @@ rust_option = get_option('rust').disable_auto_if(not cargo.found())
>  if rust_option.allowed()
>    subdir('src')
>    libgit_c_args += '-DWITH_RUST'
> +else
> +  libgit_sources += [
> +    'varint.c',
> +  ]
>  endif
>
>  libgit = declare_dependency(
> diff --git a/src/lib.rs b/src/lib.rs
> index e69de29bb2d..9da70d8b57d 100644
> --- a/src/lib.rs
> +++ b/src/lib.rs
> @@ -0,0 +1 @@
> +pub mod varint;
> diff --git a/src/meson.build b/src/meson.build
> index c8d874b2106..25b9ad5a147 100644
> --- a/src/meson.build
> +++ b/src/meson.build
> @@ -1,5 +1,6 @@
>  libgit_rs_sources = [
>    'lib.rs',
> +  'varint.rs',
>  ]
>
>  # Unfortunately we must use a wrapper command to move the output file into the
> diff --git a/src/varint.rs b/src/varint.rs
> new file mode 100644
> index 00000000000..6e610bdd8e0
> --- /dev/null
> +++ b/src/varint.rs
> @@ -0,0 +1,92 @@
> +#[no_mangle]
> +pub unsafe extern "C" fn decode_varint(bufp: *mut *const u8) -> u64 {
> +    let mut buf = *bufp;
> +    let mut c = *buf;
> +    let mut val = u64::from(c & 127);
> +
> +    buf = buf.add(1);
> +
> +    while (c & 128) != 0 {
> +        val = val.wrapping_add(1);
> +        if val == 0 || val.leading_zeros() < 7 {
> +            return 0; // overflow
> +        }
> +
> +        c = *buf;
> +        buf = buf.add(1);
> +
> +        val = (val << 7) + u64::from(c & 127);
> +    }
> +
> +    *bufp = buf;
> +    val
> +}
> +
> +#[no_mangle]
> +pub unsafe extern "C" fn encode_varint(value: u64, buf: *mut u8) -> u8 {
> +    let mut varint: [u8; 16] = [0; 16];
> +    let mut pos = varint.len() - 1;
> +
> +    varint[pos] = (value & 127) as u8;
> +
> +    let mut value = value >> 7;
> +    while value != 0 {
> +        pos -= 1;
> +        value -= 1;
> +        varint[pos] = 128 | (value & 127) as u8;
> +        value >>= 7;
> +    }
> +
> +    if !buf.is_null() {
> +        std::ptr::copy_nonoverlapping(varint.as_ptr().add(pos), buf, varint.len() - pos);
> +    }
> +
> +    (varint.len() - pos) as u8
> +}
> +
> +#[cfg(test)]
> +mod tests {
> +    use super::*;
> +
> +    #[test]
> +    fn test_decode_varint() {
> +        unsafe {
> +            assert_eq!(decode_varint(&mut [0x00].as_slice().as_ptr()), 0);
> +            assert_eq!(decode_varint(&mut [0x01].as_slice().as_ptr()), 1);
> +            assert_eq!(decode_varint(&mut [0x7f].as_slice().as_ptr()), 127);
> +            assert_eq!(decode_varint(&mut [0x80, 0x00].as_slice().as_ptr()), 128);
> +            assert_eq!(decode_varint(&mut [0x80, 0x01].as_slice().as_ptr()), 129);
> +            assert_eq!(decode_varint(&mut [0x80, 0x7f].as_slice().as_ptr()), 255);
> +
> +            // Overflows are expected to return 0.
> +            assert_eq!(decode_varint(&mut [0x88; 16].as_slice().as_ptr()), 0);
> +        }
> +    }
> +
> +    #[test]
> +    fn test_encode_varint() {
> +        unsafe {
> +            let mut varint: [u8; 16] = [0; 16];
> +
> +            assert_eq!(encode_varint(0, std::ptr::null_mut()), 1);
> +
> +            assert_eq!(encode_varint(0, varint.as_mut_slice().as_mut_ptr()), 1);
> +            assert_eq!(varint, [0; 16]);
> +
> +            assert_eq!(encode_varint(10, varint.as_mut_slice().as_mut_ptr()), 1);
> +            assert_eq!(varint, [10, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
> +
> +            assert_eq!(encode_varint(127, varint.as_mut_slice().as_mut_ptr()), 1);
> +            assert_eq!(varint, [127, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
> +
> +            assert_eq!(encode_varint(128, varint.as_mut_slice().as_mut_ptr()), 2);
> +            assert_eq!(varint, [128, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
> +
> +            assert_eq!(encode_varint(129, varint.as_mut_slice().as_mut_ptr()), 2);
> +            assert_eq!(varint, [128, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
> +
> +            assert_eq!(encode_varint(255, varint.as_mut_slice().as_mut_ptr()), 2);
> +            assert_eq!(varint, [128, 127, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
> +        }
> +    }
> +}

Looks good.

Re: [PATCH v7 6/9] varint: reimplement as test balloon for Rust

[Junio C Hamano]

Ezekiel Newren <ezekielnewren@gmail.com> writes:

> On Thu, Sep 25, 2025 at 12:30 AM Patrick Steinhardt <ps@pks.im> wrote:
>>  Makefile        |  3 ++
>>  meson.build     |  5 +++-
>>  src/lib.rs      |  1 +
>>  src/meson.build |  1 +
>>  src/varint.rs   | 92 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>  5 files changed, 101 insertions(+), 1 deletion(-)
>...
>
> Looks good.

Thanks.

[PATCH v7 7/9] BreakingChanges: announce Rust becoming mandatory

[Patrick Steinhardt]

Over the last couple of years the appetite for bringing Rust into the
codebase has grown significantly across the developer base. Introducing
Rust is a major change though and has ramifications for the whole
ecosystem:

  - Some platforms have a Rust toolchain available, but have not yet
    integrated it into their build infrastructure.

  - Some platforms don't have any support for Rust at all.

  - Some platforms may have to figure out how to fit Rust into their
    bootstrapping sequence.

Due to this, and given that Git is a critical piece of infrastructure
for the whole industry, we cannot just introduce such a heavyweight
dependency without doing our due diligence.

Instead, preceding commits have introduced a test balloon into our build
infrastructure that convert one tiny subsystem to use Rust. For now,
using Rust to build that subsystem is entirely optional -- if no Rust
support is available, we continue to use the C implementation. This test
balloon has the intention to give distributions time and let them ease
into our adoption of Rust.

Having multiple implementations of the same subsystem is not sustainable
though, and the plan is to eventually be able to use Rust freely all
across our codebase. As such, there is the intent to make Rust become a
mandatory part of our build process.

Add an announcement to our breaking changes that Rust will become
mandatory in Git 3.0. A (very careful and non-binding) estimate might be
that this major release might be released in the second half of next
year, which should give distributors enough time to prepare for the
change.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 Documentation/BreakingChanges.adoc | 45 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/Documentation/BreakingChanges.adoc b/Documentation/BreakingChanges.adoc
index f8d2eba061..c21f902134 100644
--- a/Documentation/BreakingChanges.adoc
+++ b/Documentation/BreakingChanges.adoc
@@ -165,6 +165,51 @@ A prerequisite for this change is that the ecosystem is ready to support the
 "reftable" format. Most importantly, alternative implementations of Git like
 JGit, libgit2 and Gitoxide need to support it.
 
+* Git will require Rust as a mandatory part of the build process. While Git
+  already started to adopt Rust in Git 2.49, all parts written in Rust are
+  optional for the time being. This includes:
++
+  ** The Rust wrapper around libgit.a that is part of "contrib/" and which has
+     been introduced in Git 2.49.
+  ** Subsystems that have an alternative implementation in Rust to test
+     interoperability between our C and Rust codebase.
+  ** Newly written features that are not mission critical for a fully functional
+     Git client.
++
+These changes are meant as test balloons to allow distributors of Git to prepare
+for Rust becoming a mandatory part of the build process. There will be multiple
+milestones for the introduction of Rust:
++
+--
+1. Initially, with Git 2.52, support for Rust will be auto-detected by Meson and
+   disabled in our Makefile so that the project can sort out the initial
+   infrastructure.
+2. In Git 2.53, both build systems will default-enable support for Rust.
+   Consequently, builds will break by default if Rust is not available on the
+   build host. The use of Rust can still be explicitly disabled via build
+   flags.
+3. In Git 3.0, the build options will be removed and support for Rust is
+   mandatory.
+--
++
+You can explicitly ask both Meson and our Makefile-based system to enable Rust
+by saying `meson configure -Drust=enabled` and `make WITH_RUST=YesPlease`,
+respectively.
++
+The Git project will declare the last version before Git 3.0 to be a long-term
+support release. This long-term release will receive important bug fixes for at
+least four release cycles and security fixes for six release cycles. The Git
+project will hand over maintainership of the long-term release to distributors
+in case they need to extend the life of that long-term release even further.
+Details of how this long-term release will be handed over to the community will
+be discussed once the Git project decides to stop officially supporting it.
++
+We will evaluate the impact on downstream distributions before making Rust
+mandatory in Git 3.0. If we see that the impact on downstream distributions
+would be significant, we may decide to defer this change to a subsequent minor
+release. This evaluation will also take into account our own experience with
+how painful it is to keep Rust an optional component.
+
 === Removals
 
 * Support for grafting commits has long been superseded by git-replace(1).

-- 
2.51.0.618.g983fd99d29.dirty

[PATCH v7 8/9] ci: convert "pedantic" job into full build with breaking changes

[Patrick Steinhardt]

The "pedantic" CI job is building on Fedora with `DEVOPTS=pedantic`.
This build flag doesn't do anything anymore starting with 6a8cbc41ba
(developer: enable pedantic by default, 2021-09-03), where we have
flipped the default so that developers have to opt-out of pedantic
builds via the "no-pedantic" option. As such, all this job really does
is to do a normal build on Fedora, which isn't all that interesting.

Convert that job into a full build-and-test job that uses Meson with
breaking changes enabled. This plugs two gaps:

  - We now test on another distro that we didn't run tests on
    beforehand.

  - We verify that breaking changes work as expected with Meson.

Furthermore, in a subsequent commit we'll modify both jobs that use
breaking changes to also enable Rust. By converting the Fedora job to
use Meson, we ensure that we test our Rust build infrastructure for both
build systems.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 .github/workflows/main.yml |  4 ++--
 .gitlab-ci.yml             |  4 ++--
 ci/install-dependencies.sh |  6 +++++-
 ci/run-build-and-tests.sh  | 29 ++++++++---------------------
 4 files changed, 17 insertions(+), 26 deletions(-)

diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index d122e79415..393ea4d1cc 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -379,6 +379,8 @@ jobs:
         - jobname: linux-breaking-changes
           cc: gcc
           image: ubuntu:rolling
+        - jobname: fedora-breaking-changes-meson
+          image: fedora:latest
         - jobname: linux-leaks
           image: ubuntu:rolling
           cc: gcc
@@ -396,8 +398,6 @@ jobs:
         # Supported until 2025-04-02.
         - jobname: linux32
           image: i386/ubuntu:focal
-        - jobname: pedantic
-          image: fedora:latest
         # A RHEL 8 compatible distro.  Supported until 2029-05-31.
         - jobname: almalinux-8
           image: almalinux:8
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index af10ebb59a..4248506909 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -45,6 +45,8 @@ test:linux:
       - jobname: linux-breaking-changes
         image: ubuntu:20.04
         CC: gcc
+      - jobname: fedora-breaking-changes-meson
+        image: fedora:latest
       - jobname: linux-TEST-vars
         image: ubuntu:20.04
         CC: gcc
@@ -58,8 +60,6 @@ test:linux:
       - jobname: linux-asan-ubsan
         image: ubuntu:rolling
         CC: clang
-      - jobname: pedantic
-        image: fedora:latest
       - jobname: linux-musl-meson
         image: alpine:latest
       - jobname: linux32
diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh
index d061a47293..35bd05b85b 100755
--- a/ci/install-dependencies.sh
+++ b/ci/install-dependencies.sh
@@ -30,8 +30,12 @@ alpine-*)
 		bash cvs gnupg perl-cgi perl-dbd-sqlite perl-io-tty >/dev/null
 	;;
 fedora-*|almalinux-*)
+	case "$jobname" in
+	*-meson)
+		MESON_DEPS="meson ninja";;
+	esac
 	dnf -yq update >/dev/null &&
-	dnf -yq install shadow-utils sudo make gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null
+	dnf -yq install shadow-utils sudo make pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel $MESON_DEPS >/dev/null
 	;;
 ubuntu-*|i386/ubuntu-*|debian-*)
 	# Required so that apt doesn't wait for user input on certain packages.
diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index 01823fd0f1..3680446649 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -5,12 +5,11 @@
 
 . ${0%/*}/lib.sh
 
-run_tests=t
-
 case "$jobname" in
-linux-breaking-changes)
+fedora-breaking-changes-musl|linux-breaking-changes)
 	export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
 	export WITH_BREAKING_CHANGES=YesPlease
+	MESONFLAGS="$MESONFLAGS -Dbreaking_changes=true"
 	;;
 linux-TEST-vars)
 	export OPENSSL_SHA1_UNSAFE=YesPlease
@@ -36,12 +35,6 @@ linux-sha256)
 linux-reftable|linux-reftable-leaks|osx-reftable)
 	export GIT_TEST_DEFAULT_REF_FORMAT=reftable
 	;;
-pedantic)
-	# Don't run the tests; we only care about whether Git can be
-	# built.
-	export DEVOPTS=pedantic
-	run_tests=
-	;;
 esac
 
 case "$jobname" in
@@ -54,21 +47,15 @@ case "$jobname" in
 		-Dtest_output_directory="${TEST_OUTPUT_DIRECTORY:-$(pwd)/t}" \
 		$MESONFLAGS
 	group "Build" meson compile -C build --
-	if test -n "$run_tests"
-	then
-		group "Run tests" meson test -C build --print-errorlogs --test-args="$GIT_TEST_OPTS" || (
-			./t/aggregate-results.sh "${TEST_OUTPUT_DIRECTORY:-t}/test-results"
-			handle_failed_tests
-		)
-	fi
+	group "Run tests" meson test -C build --print-errorlogs --test-args="$GIT_TEST_OPTS" || (
+		./t/aggregate-results.sh "${TEST_OUTPUT_DIRECTORY:-t}/test-results"
+		handle_failed_tests
+	)
 	;;
 *)
 	group Build make
-	if test -n "$run_tests"
-	then
-		group "Run tests" make test ||
-		handle_failed_tests
-	fi
+	group "Run tests" make test ||
+	handle_failed_tests
 	;;
 esac
 

-- 
2.51.0.618.g983fd99d29.dirty

[PATCH v7 9/9] ci: enable Rust for breaking-changes jobs

[Patrick Steinhardt]

Enable Rust for our breaking-changes jobs so that we can verify that the
build infrastructure and the converted Rust subsystems work as expected.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 ci/install-dependencies.sh | 4 ++--
 ci/run-build-and-tests.sh  | 2 ++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh
index 35bd05b85b..0d3aa496fc 100755
--- a/ci/install-dependencies.sh
+++ b/ci/install-dependencies.sh
@@ -35,7 +35,7 @@ fedora-*|almalinux-*)
 		MESON_DEPS="meson ninja";;
 	esac
 	dnf -yq update >/dev/null &&
-	dnf -yq install shadow-utils sudo make pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel $MESON_DEPS >/dev/null
+	dnf -yq install shadow-utils sudo make pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel $MESON_DEPS cargo >/dev/null
 	;;
 ubuntu-*|i386/ubuntu-*|debian-*)
 	# Required so that apt doesn't wait for user input on certain packages.
@@ -62,7 +62,7 @@ ubuntu-*|i386/ubuntu-*|debian-*)
 		make libssl-dev libcurl4-openssl-dev libexpat-dev wget sudo default-jre \
 		tcl tk gettext zlib1g-dev perl-modules liberror-perl libauthen-sasl-perl \
 		libemail-valid-perl libio-pty-perl libio-socket-ssl-perl libnet-smtp-ssl-perl libdbd-sqlite3-perl libcgi-pm-perl \
-		libsecret-1-dev libpcre2-dev meson ninja-build pkg-config \
+		libsecret-1-dev libpcre2-dev meson ninja-build pkg-config cargo \
 		${CC_PACKAGE:-${CC:-gcc}} $PYTHON_PACKAGE
 
 	case "$distro" in
diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index 3680446649..c718bd101a 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -9,7 +9,9 @@ case "$jobname" in
 fedora-breaking-changes-musl|linux-breaking-changes)
 	export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
 	export WITH_BREAKING_CHANGES=YesPlease
+	export WITH_RUST=YesPlease
 	MESONFLAGS="$MESONFLAGS -Dbreaking_changes=true"
+	MESONFLAGS="$MESONFLAGS -Drust=enabled"
 	;;
 linux-TEST-vars)
 	export OPENSSL_SHA1_UNSAFE=YesPlease

-- 
2.51.0.618.g983fd99d29.dirty

Re: [PATCH v7 0/9] Introduce Rust and announce that it will become mandatory

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

> Hi,
>
> this small patch series introduces Rust into the core of Git. This patch
> series is designed as a test balloon, similar to how we introduced test
> balloons for C99 features in the past. The goal is threefold:
>
>   - Give us some time to experiment with Rust and introduce proper build
>     infrastructure.
>
>   - Give distributors time to ease into the new toolchain requirements.
>     Introducing Rust is impossible for some platforms and hard for
>     others.
>
>   - Announce that Git 3.0 will make Rust a mandatory part of our build
>     infrastructure.
>
> The test balloon itself is quite uninteresting: I've chosen to convert
> the "varint.c" subsystem, mostly because it is trivial and does not have
> any dependencies. But it does allow us to verify that C to Rust interop
> works as expected, and to play around with tooling. All tests pass with
> the "varint.rs" implementation.
>
> For now, the series only contains support for Meson. If we agree to go
> down this route I'll also introduce support for Rust into our Makefiles
> at a later point in time.
>
> Furthermore missing is additional tooling:
>
>   - At least one CI job to verify that Rust builds and works as
>     expected.
>
>   - Tooling and CI jobs to ensure that we have consistent formatting via
>     `cargo format`.
>
> And probably lots more. As said, the entire goal is for us to have an
> easy playground that we can experiment on and develop the infrastructure
> incrementally without yet having to commit to anything.
>
> I'm mostly splitting out the topic of introducing Rust from the larger
> series that introduce it into xdiff so that we can focus more on the
> actual process of introducing Rust into Git and less on the potential
> features that we want to build on top of it.
> ...
> Changes in v7:
>   - Rename "git" crate to "gitcore".
>   - Some word smithing for the breaking changes doc.
>   - Punt on the exact details of how we hand over maintenance of the LTS
>     release to the community. This is something we can decide on in the
>     future.
>   - Link to v6: https://lore.kernel.org/r/20250923-b4-pks-rust-breaking-change-v6-0-59076fee486a@pks.im

OK, I see that this is with minimum changes relative to earlier
editions (like clarifying in BreakingChanges the release number in
which we started toying with Rust, and renamibng <libgit> to
<libgitcore>).  Hopefully we are getting at the end of the tunnel?

If I recall the coordination discussion correctly, when people are
happy with this series, Ezekiel's stuff (not the "xdiff clean-up"
that is to improve/adjust code that is purely in C without any Rust
component, which can independently advance without waiting for any
of these) will be rebuilt on top.

Will replace; I am hoping to hear positive reactions as well as
"here we want to improve it this way" comments.

Thanks.

Re: [PATCH v7 0/9] Introduce Rust and announce that it will become mandatory

[Ezekiel Newren]

On Thu, Sep 25, 2025 at 10:35 AM Junio C Hamano <gitster@pobox.com> wrote:
> If I recall the coordination discussion correctly, when people are
> happy with this series, Ezekiel's stuff (not the "xdiff clean-up"
> that is to improve/adjust code that is purely in C without any Rust
> component, which can independently advance without waiting for any
> of these) will be rebuilt on top.

Your understanding is correct. I've dropped my "Introduce Rust" patch
series in favor of Patrick's. Once Patrick's stuff gets merged I'll
work on rebasing my Rust stuff on top.

Aside from a few typos, this patch series looks good to me.

[PATCH v8 0/9] Introduce Rust and announce that it will become mandatory

[Patrick Steinhardt]

Hi,

this small patch series introduces Rust into the core of Git. This patch
series is designed as a test balloon, similar to how we introduced test
balloons for C99 features in the past. The goal is threefold:

  - Give us some time to experiment with Rust and introduce proper build
    infrastructure.

  - Give distributors time to ease into the new toolchain requirements.
    Introducing Rust is impossible for some platforms and hard for
    others.

  - Announce that Git 3.0 will make Rust a mandatory part of our build
    infrastructure.

The test balloon itself is quite uninteresting: I've chosen to convert
the "varint.c" subsystem, mostly because it is trivial and does not have
any dependencies. But it does allow us to verify that C to Rust interop
works as expected, and to play around with tooling. All tests pass with
the "varint.rs" implementation.

For now, the series only contains support for Meson. If we agree to go
down this route I'll also introduce support for Rust into our Makefiles
at a later point in time.

Furthermore missing is additional tooling:

  - At least one CI job to verify that Rust builds and works as
    expected.

  - Tooling and CI jobs to ensure that we have consistent formatting via
    `cargo format`.

And probably lots more. As said, the entire goal is for us to have an
easy playground that we can experiment on and develop the infrastructure
incrementally without yet having to commit to anything.

I'm mostly splitting out the topic of introducing Rust from the larger
series that introduce it into xdiff so that we can focus more on the
actual process of introducing Rust into Git and less on the potential
features that we want to build on top of it.

Changes in v2:
  - Introduce support for building the Rust library via our Makefile.
  - Introduce a '-DWITH_RUST' define. This define is used to print
    whether or not Git is built with Rust via `git version
    --build-options`.
  - Adjust Meson to not depend on v1.9.0 and newer anymore.
  - Introduce a roadmap into our BreakingChanges document to explain how
    we'll iterate towards mandatory Rust support.
  - Rework the Fedora job to do a full compile-and-test run with Meson
    and breaking changes enabled.
  - Adapt our breaking-changes jobs to enable Rust support.
  - Link to v1: https://lore.kernel.org/r/20250904-b4-pks-rust-breaking-change-v1-0-3af1d25e0be9@pks.im

Changes in v3:
  - Reorder all uses of `WITH_RUST` after the include of "config.mak".
  - Add a test to verify overflow behaviour in Rust and explicitly use
    `add_wrapping()`.
  - Use explicit dependencies for the Rust library in our Makefile.
  - Fix Alma Linux CI job.
  - Stop tying maintenance of our LTS release to the availability of
    gcc-rs.
  - Add a fallback to Meson to use cargo directly.
  - I've fixed the Rust edition to 2018 for now. This is intentionally
    conservative so that we might be able to use Rust 1.49. For now, we
    don't have any reason to use a newer edition, either. So let's take
    the oldest version we can live with for now and then bump it as
    required.
  - Link to v2: https://lore.kernel.org/r/20250905-b4-pks-rust-breaking-change-v2-0-6939cbf4a0b8@pks.im

Changes in v4:
  - Convert "varint.c" to use explicit integer width so that we don't
    need to use C types in Rust.
  - Adapt Meson to unconditionally use Cargo.
  - Don't use the unstable `--out-dir` option in Cargo. Instead, we
    resort to a wrapper script in Meson.
  - Shorten the timeline a bit to drop the extra step that ties Rust
    support to `-Dbreaking_changes=true`. This accelerates the timeline
    until distros are made forcibly aware of the upcoming changes in
    Rust.
  - Link to v3: https://lore.kernel.org/r/20250908-b4-pks-rust-breaking-change-v3-0-1cd7189fed3b@pks.im

Changes in v5:
  - Fix indentation in the BreakingChanges document.
  - Fix a commit message typo.
  - Include "Cargo.lock" in the `make clean` target again.
  - Link to v4: https://lore.kernel.org/r/20250910-b4-pks-rust-breaking-change-v4-0-4a63fc69278d@pks.im

Changes in v6:
  - Give attribution to Ezekiel for kickstarting the Rust adoption
    again. I'm happy to change how I do the attribution.
  - Fix "varint.rs" to use `u64` instead of `usize`. Issues like these
    will eventually be catched by cbindgen.
  - Adapt the breaking changes document to mention that we already have
    Rust in our tree starting with Git 2.49.
  - Mention that we won't blindly make Rust mandatory, but consider the
    impact on downstream distributions.
  - Slightly reword how we'll handle LTS maintainership. This probably
    still is an ongoing discussion.
  - Link to v5: https://lore.kernel.org/r/20250915-b4-pks-rust-breaking-change-v5-0-dc3a32fbb216@pks.im

Changes in v7:
  - Rename "git" crate to "gitcore".
  - Some word smithing for the breaking changes doc.
  - Punt on the exact details of how we hand over maintenance of the LTS
    release to the community. This is something we can decide on in the
    future.
  - Link to v6: https://lore.kernel.org/r/20250923-b4-pks-rust-breaking-change-v6-0-59076fee486a@pks.im

Changes in v8:
  - Some final typo fixes.
  - Link to v7: https://lore.kernel.org/r/20250925-b4-pks-rust-breaking-change-v7-0-4e49dcb904d5@pks.im

Thanks!

Patrick

---
Patrick Steinhardt (9):
      meson: add infrastructure to build internal Rust library
      Makefile: reorder sources after includes
      Makefile: introduce infrastructure to build internal Rust library
      help: report on whether or not Rust is enabled
      varint: use explicit width for integers
      varint: reimplement as test balloon for Rust
      BreakingChanges: announce Rust becoming mandatory
      ci: convert "pedantic" job into full build with breaking changes
      ci: enable Rust for breaking-changes jobs

 .github/workflows/main.yml         |   4 +-
 .gitignore                         |   2 +
 .gitlab-ci.yml                     |   4 +-
 Cargo.toml                         |   9 ++
 Documentation/BreakingChanges.adoc |  45 ++++++++
 Makefile                           | 214 ++++++++++++++++++++++---------------
 ci/install-dependencies.sh         |   8 +-
 ci/run-build-and-tests.sh          |  31 ++----
 dir.c                              |  18 ++--
 help.c                             |   6 ++
 meson.build                        |  15 ++-
 meson_options.txt                  |   2 +
 read-cache.c                       |   6 +-
 shared.mak                         |   1 +
 src/cargo-meson.sh                 |  32 ++++++
 src/lib.rs                         |   1 +
 src/meson.build                    |  41 +++++++
 src/varint.rs                      |  92 ++++++++++++++++
 varint.c                           |   6 +-
 varint.h                           |   4 +-
 20 files changed, 410 insertions(+), 131 deletions(-)

Range-diff versus v7:

 1:  3f916bebd4 =  1:  bf7b33291d meson: add infrastructure to build internal Rust library
 2:  ed849dcfed =  2:  59e7879c63 Makefile: reorder sources after includes
 3:  955f262ef5 =  3:  635cebc0a6 Makefile: introduce infrastructure to build internal Rust library
 4:  7a90192b5a =  4:  43b50563cc help: report on whether or not Rust is enabled
 5:  9365a78efd !  5:  37d03d7774 varint: use explicit width for integers
    @@ Metadata
      ## Commit message ##
         varint: use explicit width for integers
     
    -    The varint subsystem currently uses implcit widths for integers. On the
    +    The varint subsystem currently uses implicit widths for integers. On the
         one hand we use `uintmax_t` for the actual value. On the other hand, we
         use `int` for the length of the encoded varint.
     
    -    Both of these have known maximum vaules, as we only support at most 16
    +    Both of these have known maximum values, as we only support at most 16
         bytes when encoding varints. Thus, we know that we won't ever exceed
         `uint64_t` for the actual value and `uint8_t` for the prefix length.
     
 6:  e7e0621b68 =  6:  0d265f9675 varint: reimplement as test balloon for Rust
 7:  8d8e9cb8a8 =  7:  a6e0d668f0 BreakingChanges: announce Rust becoming mandatory
 8:  07dc8171ac =  8:  79470835fd ci: convert "pedantic" job into full build with breaking changes
 9:  708a0d3c67 =  9:  67f8dea13f ci: enable Rust for breaking-changes jobs

---
base-commit: 2462961280690837670d997bde64bd4ebf8ae66d
change-id: 20250904-b4-pks-rust-breaking-change-7167d9d3e37d

[PATCH v8 1/9] meson: add infrastructure to build internal Rust library

[Patrick Steinhardt]

Add the infrastructure into Meson to build an internal Rust library.
Building the Rust parts of Git are for now entirely optional, as they
are mostly intended as a test balloon for both Git developers, but also
for distributors of Git. So for now, they may contain:

  - New features that are not mission critical to Git and that users can
    easily live without.

  - Alternative implementations of small subsystems.

If these test balloons are successful, we will eventually make Rust a
mandatory dependency for our build process in Git 3.0.

The availability of a Rust toolchain will be auto-detected by Meson at
setup time. This behaviour can be tweaked via the `-Drust=` feature
toggle.

Next to the linkable Rust library, also wire up tests that can be
executed via `meson test`. This allows us to use the native unit testing
capabilities of Rust.

Note that the Rust edition is currently set to 2018. This edition is
supported by Rust 1.49, which is the target for the upcoming gcc-rs
backend. For now we don't use any features of Rust that would require a
newer version, so settling on this old version makes sense so that
gcc-rs may become an alternative backend for compiling Git. If we _do_
want to introduce features that were added in more recent editions of
Rust though we should reevaluate that choice.

Inspired-by: Ezekiel Newren <ezekielnewren@gmail.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 Cargo.toml         |  9 +++++++++
 meson.build        | 10 +++++++++-
 meson_options.txt  |  2 ++
 src/cargo-meson.sh | 32 ++++++++++++++++++++++++++++++++
 src/lib.rs         |  0
 src/meson.build    | 40 ++++++++++++++++++++++++++++++++++++++++
 6 files changed, 92 insertions(+), 1 deletion(-)

diff --git a/Cargo.toml b/Cargo.toml
new file mode 100644
index 00000000000..45c9b34981a
--- /dev/null
+++ b/Cargo.toml
@@ -0,0 +1,9 @@
+[package]
+name = "gitcore"
+version = "0.1.0"
+edition = "2018"
+
+[lib]
+crate-type = ["staticlib"]
+
+[dependencies]
diff --git a/meson.build b/meson.build
index e8ec0eca165..234a9e9d6fd 100644
--- a/meson.build
+++ b/meson.build
@@ -220,7 +220,7 @@ project('git', 'c',
   # learned to define __STDC_VERSION__ with C11 and later. We thus require
   # GNU C99 and fall back to C11. Meson only learned to handle the fallback
   # with version 1.3.0, so on older versions we use GNU C99 unconditionally.
-  default_options: meson.version().version_compare('>=1.3.0') ? ['c_std=gnu99,c11'] : ['c_std=gnu99'],
+  default_options: meson.version().version_compare('>=1.3.0') ? ['rust_std=2018', 'c_std=gnu99,c11'] : ['rust_std=2018', 'c_std=gnu99'],
 )
 
 fs = import('fs')
@@ -1702,6 +1702,13 @@ version_def_h = custom_target(
 )
 libgit_sources += version_def_h
 
+cargo = find_program('cargo', dirs: program_path, native: true, required: get_option('rust'))
+rust_option = get_option('rust').disable_auto_if(not cargo.found())
+if rust_option.allowed()
+  subdir('src')
+  libgit_c_args += '-DWITH_RUST'
+endif
+
 libgit = declare_dependency(
   link_with: static_library('git',
     sources: libgit_sources,
@@ -2239,6 +2246,7 @@ summary({
   'pcre2': pcre2,
   'perl': perl_features_enabled,
   'python': target_python.found(),
+  'rust': rust_option.allowed(),
 }, section: 'Auto-detected features', bool_yn: true)
 
 summary({
diff --git a/meson_options.txt b/meson_options.txt
index 1668f260a18..143dee9237c 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -71,6 +71,8 @@ option('zlib_backend', type: 'combo', choices: ['auto', 'zlib', 'zlib-ng'], valu
 # Build tweaks.
 option('breaking_changes', type: 'boolean', value: false,
   description: 'Enable upcoming breaking changes.')
+option('rust', type: 'feature', value: 'auto',
+  description: 'Enable building with Rust.')
 option('macos_use_homebrew_gettext', type: 'boolean', value: true,
   description: 'Use gettext from Homebrew instead of the slightly-broken system-provided one.')
 
diff --git a/src/cargo-meson.sh b/src/cargo-meson.sh
new file mode 100755
index 00000000000..99400986d93
--- /dev/null
+++ b/src/cargo-meson.sh
@@ -0,0 +1,32 @@
+#!/bin/sh
+
+if test "$#" -lt 2
+then
+	exit 1
+fi
+
+SOURCE_DIR="$1"
+BUILD_DIR="$2"
+BUILD_TYPE=debug
+
+shift 2
+
+for arg
+do
+	case "$arg" in
+	--release)
+		BUILD_TYPE=release;;
+	esac
+done
+
+cargo build --lib --quiet --manifest-path="$SOURCE_DIR/Cargo.toml" --target-dir="$BUILD_DIR" "$@"
+RET=$?
+if test $RET -ne 0
+then
+	exit $RET
+fi
+
+if ! cmp "$BUILD_DIR/$BUILD_TYPE/libgitcore.a" "$BUILD_DIR/libgitcore.a" >/dev/null 2>&1
+then
+	cp "$BUILD_DIR/$BUILD_TYPE/libgitcore.a" "$BUILD_DIR/libgitcore.a"
+fi
diff --git a/src/lib.rs b/src/lib.rs
new file mode 100644
index 00000000000..e69de29bb2d
diff --git a/src/meson.build b/src/meson.build
new file mode 100644
index 00000000000..c8d874b2106
--- /dev/null
+++ b/src/meson.build
@@ -0,0 +1,40 @@
+libgit_rs_sources = [
+  'lib.rs',
+]
+
+# Unfortunately we must use a wrapper command to move the output file into the
+# current build directory. This can fixed once `cargo build --artifact-dir`
+# stabilizes. See https://github.com/rust-lang/cargo/issues/6790 for that
+# effort.
+cargo_command = [
+  shell,
+  meson.current_source_dir() / 'cargo-meson.sh',
+  meson.project_source_root(),
+  meson.current_build_dir(),
+]
+if get_option('buildtype') == 'release'
+  cargo_command += '--release'
+endif
+
+libgit_rs = custom_target('git_rs',
+  input: libgit_rs_sources + [
+    meson.project_source_root() / 'Cargo.toml',
+  ],
+  output: 'libgitcore.a',
+  command: cargo_command,
+)
+libgit_dependencies += declare_dependency(link_with: libgit_rs)
+
+if get_option('tests')
+  test('rust', cargo,
+    args: [
+      'test',
+      '--manifest-path',
+      meson.project_source_root() / 'Cargo.toml',
+      '--target-dir',
+      meson.current_build_dir() / 'target',
+    ],
+    timeout: 0,
+    protocol: 'rust',
+  )
+endif

-- 
2.51.0.700.g236ee7b076.dirty

[PATCH v8 2/9] Makefile: reorder sources after includes

[Patrick Steinhardt]

In an upcoming change we'll make some of the sources compile
conditionally based on whether or not `WITH_RUST` is defined. To let
developers specify that flag in their "config.mak" we'll thus have to
reorder our sources so that they come after the include of that file.

Do so.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 Makefile | 176 +++++++++++++++++++++++++++++++--------------------------------
 1 file changed, 88 insertions(+), 88 deletions(-)

diff --git a/Makefile b/Makefile
index 555b7f4dc3..7e52625d75 100644
--- a/Makefile
+++ b/Makefile
@@ -919,6 +919,94 @@ LIB_FILE = libgit.a
 XDIFF_LIB = xdiff/lib.a
 REFTABLE_LIB = reftable/libreftable.a
 
+# xdiff and reftable libs may in turn depend on what is in libgit.a
+GITLIBS = common-main.o $(LIB_FILE) $(XDIFF_LIB) $(REFTABLE_LIB) $(LIB_FILE)
+EXTLIBS =
+
+GIT_USER_AGENT = git/$(GIT_VERSION)
+
+ifeq ($(wildcard sha1collisiondetection/lib/sha1.h),sha1collisiondetection/lib/sha1.h)
+DC_SHA1_SUBMODULE = auto
+endif
+
+# Set CFLAGS, LDFLAGS and other *FLAGS variables. These might be
+# tweaked by config.* below as well as the command-line, both of
+# which'll override these defaults.
+# Older versions of GCC may require adding "-std=gnu99" at the end.
+CFLAGS = -g -O2 -Wall
+LDFLAGS =
+CC_LD_DYNPATH = -Wl,-rpath,
+BASIC_CFLAGS = -I.
+BASIC_LDFLAGS =
+
+# library flags
+ARFLAGS = rcs
+PTHREAD_CFLAGS =
+
+# For the 'sparse' target
+SPARSE_FLAGS ?= -std=gnu99 -D__STDC_NO_VLA__
+SP_EXTRA_FLAGS =
+
+# For informing GIT-BUILD-OPTIONS of the SANITIZE=leak,address targets
+SANITIZE_LEAK =
+SANITIZE_ADDRESS =
+
+# For the 'coccicheck' target
+SPATCH_INCLUDE_FLAGS = --all-includes
+SPATCH_FLAGS =
+SPATCH_TEST_FLAGS =
+
+# If *.o files are present, have "coccicheck" depend on them, with
+# COMPUTE_HEADER_DEPENDENCIES this will speed up the common-case of
+# only needing to re-generate coccicheck results for the users of a
+# given API if it's changed, and not all files in the project. If
+# COMPUTE_HEADER_DEPENDENCIES=no this will be unset too.
+SPATCH_USE_O_DEPENDENCIES = YesPlease
+
+# Set SPATCH_CONCAT_COCCI to concatenate the contrib/cocci/*.cocci
+# files into a single contrib/cocci/ALL.cocci before running
+# "coccicheck".
+#
+# Pros:
+#
+# - Speeds up a one-shot run of "make coccicheck", as we won't have to
+#   parse *.[ch] files N times for the N *.cocci rules
+#
+# Cons:
+#
+# - Will make incremental development of *.cocci slower, as
+#   e.g. changing strbuf.cocci will re-run all *.cocci.
+#
+# - Makes error and performance analysis harder, as rules will be
+#   applied from a monolithic ALL.cocci, rather than
+#   e.g. strbuf.cocci. To work around this either undefine this, or
+#   generate a specific patch, e.g. this will always use strbuf.cocci,
+#   not ALL.cocci:
+#
+#	make contrib/coccinelle/strbuf.cocci.patch
+SPATCH_CONCAT_COCCI = YesPlease
+
+# Rebuild 'coccicheck' if $(SPATCH), its flags etc. change
+TRACK_SPATCH_DEFINES =
+TRACK_SPATCH_DEFINES += $(SPATCH)
+TRACK_SPATCH_DEFINES += $(SPATCH_INCLUDE_FLAGS)
+TRACK_SPATCH_DEFINES += $(SPATCH_FLAGS)
+TRACK_SPATCH_DEFINES += $(SPATCH_TEST_FLAGS)
+GIT-SPATCH-DEFINES: FORCE
+	@FLAGS='$(TRACK_SPATCH_DEFINES)'; \
+	    if test x"$$FLAGS" != x"`cat GIT-SPATCH-DEFINES 2>/dev/null`" ; then \
+		echo >&2 "    * new spatch flags"; \
+		echo "$$FLAGS" >GIT-SPATCH-DEFINES; \
+            fi
+
+include config.mak.uname
+-include config.mak.autogen
+-include config.mak
+
+ifdef DEVELOPER
+include config.mak.dev
+endif
+
 GENERATED_H += command-list.h
 GENERATED_H += config-list.h
 GENERATED_H += hook-list.h
@@ -1387,94 +1475,6 @@ CLAR_TEST_OBJS += $(UNIT_TEST_DIR)/unit-test.o
 
 UNIT_TEST_OBJS += $(UNIT_TEST_DIR)/test-lib.o
 
-# xdiff and reftable libs may in turn depend on what is in libgit.a
-GITLIBS = common-main.o $(LIB_FILE) $(XDIFF_LIB) $(REFTABLE_LIB) $(LIB_FILE)
-EXTLIBS =
-
-GIT_USER_AGENT = git/$(GIT_VERSION)
-
-ifeq ($(wildcard sha1collisiondetection/lib/sha1.h),sha1collisiondetection/lib/sha1.h)
-DC_SHA1_SUBMODULE = auto
-endif
-
-# Set CFLAGS, LDFLAGS and other *FLAGS variables. These might be
-# tweaked by config.* below as well as the command-line, both of
-# which'll override these defaults.
-# Older versions of GCC may require adding "-std=gnu99" at the end.
-CFLAGS = -g -O2 -Wall
-LDFLAGS =
-CC_LD_DYNPATH = -Wl,-rpath,
-BASIC_CFLAGS = -I.
-BASIC_LDFLAGS =
-
-# library flags
-ARFLAGS = rcs
-PTHREAD_CFLAGS =
-
-# For the 'sparse' target
-SPARSE_FLAGS ?= -std=gnu99 -D__STDC_NO_VLA__
-SP_EXTRA_FLAGS =
-
-# For informing GIT-BUILD-OPTIONS of the SANITIZE=leak,address targets
-SANITIZE_LEAK =
-SANITIZE_ADDRESS =
-
-# For the 'coccicheck' target
-SPATCH_INCLUDE_FLAGS = --all-includes
-SPATCH_FLAGS =
-SPATCH_TEST_FLAGS =
-
-# If *.o files are present, have "coccicheck" depend on them, with
-# COMPUTE_HEADER_DEPENDENCIES this will speed up the common-case of
-# only needing to re-generate coccicheck results for the users of a
-# given API if it's changed, and not all files in the project. If
-# COMPUTE_HEADER_DEPENDENCIES=no this will be unset too.
-SPATCH_USE_O_DEPENDENCIES = YesPlease
-
-# Set SPATCH_CONCAT_COCCI to concatenate the contrib/cocci/*.cocci
-# files into a single contrib/cocci/ALL.cocci before running
-# "coccicheck".
-#
-# Pros:
-#
-# - Speeds up a one-shot run of "make coccicheck", as we won't have to
-#   parse *.[ch] files N times for the N *.cocci rules
-#
-# Cons:
-#
-# - Will make incremental development of *.cocci slower, as
-#   e.g. changing strbuf.cocci will re-run all *.cocci.
-#
-# - Makes error and performance analysis harder, as rules will be
-#   applied from a monolithic ALL.cocci, rather than
-#   e.g. strbuf.cocci. To work around this either undefine this, or
-#   generate a specific patch, e.g. this will always use strbuf.cocci,
-#   not ALL.cocci:
-#
-#	make contrib/coccinelle/strbuf.cocci.patch
-SPATCH_CONCAT_COCCI = YesPlease
-
-# Rebuild 'coccicheck' if $(SPATCH), its flags etc. change
-TRACK_SPATCH_DEFINES =
-TRACK_SPATCH_DEFINES += $(SPATCH)
-TRACK_SPATCH_DEFINES += $(SPATCH_INCLUDE_FLAGS)
-TRACK_SPATCH_DEFINES += $(SPATCH_FLAGS)
-TRACK_SPATCH_DEFINES += $(SPATCH_TEST_FLAGS)
-GIT-SPATCH-DEFINES: FORCE
-	@FLAGS='$(TRACK_SPATCH_DEFINES)'; \
-	    if test x"$$FLAGS" != x"`cat GIT-SPATCH-DEFINES 2>/dev/null`" ; then \
-		echo >&2 "    * new spatch flags"; \
-		echo "$$FLAGS" >GIT-SPATCH-DEFINES; \
-            fi
-
-include config.mak.uname
--include config.mak.autogen
--include config.mak
-
-ifdef DEVELOPER
-include config.mak.dev
-endif
-
 GIT-VERSION-FILE: FORCE
 	@OLD=$$(cat $@ 2>/dev/null || :) && \
 	$(call version_gen,"$(shell pwd)",GIT-VERSION-FILE.in,$@) && \

-- 
2.51.0.700.g236ee7b076.dirty

[PATCH v8 3/9] Makefile: introduce infrastructure to build internal Rust library

[Patrick Steinhardt]

Introduce infrastructure to build the internal Rust library. This
mirrors the infrastructure we have added to Meson in the preceding
commit. Developers can enable the infrastructure by passing the new
`WITH_RUST` build toggle.

Inspired-by: Ezekiel Newren <ezekielnewren@gmail.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 .gitignore |  2 ++
 Makefile   | 37 +++++++++++++++++++++++++++++++++++++
 shared.mak |  1 +
 3 files changed, 40 insertions(+)

diff --git a/.gitignore b/.gitignore
index 1803023427..0833453cf6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,4 +1,6 @@
 /fuzz_corpora
+/target/
+/Cargo.lock
 /GIT-BUILD-DIR
 /GIT-BUILD-OPTIONS
 /GIT-CFLAGS
diff --git a/Makefile b/Makefile
index 7e52625d75..31e79342e1 100644
--- a/Makefile
+++ b/Makefile
@@ -483,6 +483,14 @@ include shared.mak
 # Define LIBPCREDIR=/foo/bar if your PCRE header and library files are
 # in /foo/bar/include and /foo/bar/lib directories.
 #
+# == Optional Rust support ==
+#
+# Define WITH_RUST if you want to include features and subsystems written in
+# Rust into Git. For now, Rust is still an optional feature of the build
+# process. With Git 3.0 though, Rust will always be enabled.
+#
+# Building Rust code requires Cargo.
+#
 # == SHA-1 and SHA-256 defines ==
 #
 # === SHA-1 backend ===
@@ -683,6 +691,7 @@ OBJECTS =
 OTHER_PROGRAMS =
 PROGRAM_OBJS =
 PROGRAMS =
+RUST_SOURCES =
 EXCLUDED_PROGRAMS =
 SCRIPT_PERL =
 SCRIPT_PYTHON =
@@ -918,6 +927,11 @@ TEST_SHELL_PATH = $(SHELL_PATH)
 LIB_FILE = libgit.a
 XDIFF_LIB = xdiff/lib.a
 REFTABLE_LIB = reftable/libreftable.a
+ifdef DEBUG
+RUST_LIB = target/debug/libgitcore.a
+else
+RUST_LIB = target/release/libgitcore.a
+endif
 
 # xdiff and reftable libs may in turn depend on what is in libgit.a
 GITLIBS = common-main.o $(LIB_FILE) $(XDIFF_LIB) $(REFTABLE_LIB) $(LIB_FILE)
@@ -943,6 +957,15 @@ BASIC_LDFLAGS =
 ARFLAGS = rcs
 PTHREAD_CFLAGS =
 
+# Rust flags
+CARGO_ARGS =
+ifndef V
+CARGO_ARGS += --quiet
+endif
+ifndef DEBUG
+CARGO_ARGS += --release
+endif
+
 # For the 'sparse' target
 SPARSE_FLAGS ?= -std=gnu99 -D__STDC_NO_VLA__
 SP_EXTRA_FLAGS =
@@ -1475,6 +1498,8 @@ CLAR_TEST_OBJS += $(UNIT_TEST_DIR)/unit-test.o
 
 UNIT_TEST_OBJS += $(UNIT_TEST_DIR)/test-lib.o
 
+RUST_SOURCES += src/lib.rs
+
 GIT-VERSION-FILE: FORCE
 	@OLD=$$(cat $@ 2>/dev/null || :) && \
 	$(call version_gen,"$(shell pwd)",GIT-VERSION-FILE.in,$@) && \
@@ -1504,6 +1529,11 @@ endif
 ALL_CFLAGS = $(DEVELOPER_CFLAGS) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_APPEND)
 ALL_LDFLAGS = $(LDFLAGS) $(LDFLAGS_APPEND)
 
+ifdef WITH_RUST
+BASIC_CFLAGS += -DWITH_RUST
+GITLIBS += $(RUST_LIB)
+endif
+
 ifdef SANITIZE
 SANITIZERS := $(foreach flag,$(subst $(comma),$(space),$(SANITIZE)),$(flag))
 BASIC_CFLAGS += -fsanitize=$(SANITIZE) -fno-sanitize-recover=$(SANITIZE)
@@ -2918,6 +2948,12 @@ scalar$X: scalar.o GIT-LDFLAGS $(GITLIBS)
 $(LIB_FILE): $(LIB_OBJS)
 	$(QUIET_AR)$(RM) $@ && $(AR) $(ARFLAGS) $@ $^
 
+$(RUST_LIB): Cargo.toml $(RUST_SOURCES)
+	$(QUIET_CARGO)cargo build $(CARGO_ARGS)
+
+.PHONY: rust
+rust: $(RUST_LIB)
+
 $(XDIFF_LIB): $(XDIFF_OBJS)
 	$(QUIET_AR)$(RM) $@ && $(AR) $(ARFLAGS) $@ $^
 
@@ -3768,6 +3804,7 @@ clean: profile-clean coverage-clean cocciclean
 	$(RM) $(FUZZ_PROGRAMS)
 	$(RM) $(SP_OBJ)
 	$(RM) $(HCC)
+	$(RM) -r Cargo.lock target/
 	$(RM) version-def.h
 	$(RM) -r $(dep_dirs) $(compdb_dir) compile_commands.json
 	$(RM) $(test_bindir_programs)
diff --git a/shared.mak b/shared.mak
index 5c7bc94785..0e7492076e 100644
--- a/shared.mak
+++ b/shared.mak
@@ -56,6 +56,7 @@ ifndef V
 	QUIET_MKDIR_P_PARENT  = @echo '   ' MKDIR -p $(@D);
 
 ## Used in "Makefile"
+	QUIET_CARGO    = @echo '   ' CARGO $@;
 	QUIET_CC       = @echo '   ' CC $@;
 	QUIET_AR       = @echo '   ' AR $@;
 	QUIET_LINK     = @echo '   ' LINK $@;

-- 
2.51.0.700.g236ee7b076.dirty

[PATCH v8 4/9] help: report on whether or not Rust is enabled

[Patrick Steinhardt]

We're about to introduce support for Rust into the core of Git, where
some (trivial) subsystems are converted to Rust. These subsystems will
also retain a C implementation though as Rust is not yet mandatory.
Consequently, it now becomes possible for a Git version to have bugs
that are specific to whether or not it is built with Rust support
overall.

Expose information about whether or not Git was built with Rust via our
build info. This means that both `git version --build-options`, but also
`git bugreport` will now expose that bit of information. Hopefully, this
should make it easier for us to discover any Rust-specific issues.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 help.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/help.c b/help.c
index bb20498cfd..5854dd4a7e 100644
--- a/help.c
+++ b/help.c
@@ -791,6 +791,12 @@ void get_version_info(struct strbuf *buf, int show_build_options)
 		strbuf_addf(buf, "shell-path: %s\n", SHELL_PATH);
 		/* NEEDSWORK: also save and output GIT-BUILD_OPTIONS? */
 
+#if defined WITH_RUST
+		strbuf_addstr(buf, "rust: enabled\n");
+#else
+		strbuf_addstr(buf, "rust: disabled\n");
+#endif
+
 		if (fsmonitor_ipc__is_supported())
 			strbuf_addstr(buf, "feature: fsmonitor--daemon\n");
 #if defined LIBCURL_VERSION

-- 
2.51.0.700.g236ee7b076.dirty

[PATCH v8 5/9] varint: use explicit width for integers

[Patrick Steinhardt]

The varint subsystem currently uses implicit widths for integers. On the
one hand we use `uintmax_t` for the actual value. On the other hand, we
use `int` for the length of the encoded varint.

Both of these have known maximum values, as we only support at most 16
bytes when encoding varints. Thus, we know that we won't ever exceed
`uint64_t` for the actual value and `uint8_t` for the prefix length.

Refactor the code to use explicit widths. Besides making the logic
platform-independent, it also makes our life a bit easier in the next
commit, where we reimplement "varint.c" in Rust.

Suggested-by: Ezekiel Newren <ezekielnewren@gmail.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 dir.c        | 18 ++++++++++--------
 read-cache.c |  6 ++++--
 varint.c     |  6 +++---
 varint.h     |  4 ++--
 4 files changed, 19 insertions(+), 15 deletions(-)

diff --git a/dir.c b/dir.c
index 71108ac79b7..0a67a99cb3d 100644
--- a/dir.c
+++ b/dir.c
@@ -3579,7 +3579,8 @@ static void write_one_dir(struct untracked_cache_dir *untracked,
 	struct stat_data stat_data;
 	struct strbuf *out = &wd->out;
 	unsigned char intbuf[16];
-	unsigned int intlen, value;
+	unsigned int value;
+	uint8_t intlen;
 	int i = wd->index++;
 
 	/*
@@ -3632,7 +3633,7 @@ void write_untracked_extension(struct strbuf *out, struct untracked_cache *untra
 	struct ondisk_untracked_cache *ouc;
 	struct write_data wd;
 	unsigned char varbuf[16];
-	int varint_len;
+	uint8_t varint_len;
 	const unsigned hashsz = the_hash_algo->rawsz;
 
 	CALLOC_ARRAY(ouc, 1);
@@ -3738,7 +3739,7 @@ static int read_one_dir(struct untracked_cache_dir **untracked_,
 	struct untracked_cache_dir ud, *untracked;
 	const unsigned char *data = rd->data, *end = rd->end;
 	const unsigned char *eos;
-	unsigned int value;
+	uint64_t value;
 	int i;
 
 	memset(&ud, 0, sizeof(ud));
@@ -3830,7 +3831,8 @@ struct untracked_cache *read_untracked_extension(const void *data, unsigned long
 	struct read_data rd;
 	const unsigned char *next = data, *end = (const unsigned char *)data + sz;
 	const char *ident;
-	int ident_len;
+	uint64_t ident_len;
+	uint64_t varint_len;
 	ssize_t len;
 	const char *exclude_per_dir;
 	const unsigned hashsz = the_hash_algo->rawsz;
@@ -3867,8 +3869,8 @@ struct untracked_cache *read_untracked_extension(const void *data, unsigned long
 	if (next >= end)
 		goto done2;
 
-	len = decode_varint(&next);
-	if (next > end || len == 0)
+	varint_len = decode_varint(&next);
+	if (next > end || varint_len == 0)
 		goto done2;
 
 	rd.valid      = ewah_new();
@@ -3877,9 +3879,9 @@ struct untracked_cache *read_untracked_extension(const void *data, unsigned long
 	rd.data	      = next;
 	rd.end	      = end;
 	rd.index      = 0;
-	ALLOC_ARRAY(rd.ucd, len);
+	ALLOC_ARRAY(rd.ucd, varint_len);
 
-	if (read_one_dir(&uc->root, &rd) || rd.index != len)
+	if (read_one_dir(&uc->root, &rd) || rd.index != varint_len)
 		goto done;
 
 	next = rd.data;
diff --git a/read-cache.c b/read-cache.c
index 06ad74db228..41b44148b1e 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1807,7 +1807,7 @@ static struct cache_entry *create_from_disk(struct mem_pool *ce_mem_pool,
 
 	if (expand_name_field) {
 		const unsigned char *cp = (const unsigned char *)name;
-		size_t strip_len, previous_len;
+		uint64_t strip_len, previous_len;
 
 		/* If we're at the beginning of a block, ignore the previous name */
 		strip_len = decode_varint(&cp);
@@ -2655,8 +2655,10 @@ static int ce_write_entry(struct hashfile *f, struct cache_entry *ce,
 		hashwrite(f, ce->name, len);
 		hashwrite(f, padding, align_padding_size(size, len));
 	} else {
-		int common, to_remove, prefix_size;
+		int common, to_remove;
+		uint8_t prefix_size;
 		unsigned char to_remove_vi[16];
+
 		for (common = 0;
 		     (common < previous_name->len &&
 		      ce->name[common] &&
diff --git a/varint.c b/varint.c
index 409c4977a1e..03cd54416b6 100644
--- a/varint.c
+++ b/varint.c
@@ -1,11 +1,11 @@
 #include "git-compat-util.h"
 #include "varint.h"
 
-uintmax_t decode_varint(const unsigned char **bufp)
+uint64_t decode_varint(const unsigned char **bufp)
 {
 	const unsigned char *buf = *bufp;
 	unsigned char c = *buf++;
-	uintmax_t val = c & 127;
+	uint64_t val = c & 127;
 	while (c & 128) {
 		val += 1;
 		if (!val || MSB(val, 7))
@@ -17,7 +17,7 @@ uintmax_t decode_varint(const unsigned char **bufp)
 	return val;
 }
 
-int encode_varint(uintmax_t value, unsigned char *buf)
+uint8_t encode_varint(uint64_t value, unsigned char *buf)
 {
 	unsigned char varint[16];
 	unsigned pos = sizeof(varint) - 1;
diff --git a/varint.h b/varint.h
index f78bb0ca528..eb401935bd2 100644
--- a/varint.h
+++ b/varint.h
@@ -1,7 +1,7 @@
 #ifndef VARINT_H
 #define VARINT_H
 
-int encode_varint(uintmax_t, unsigned char *);
-uintmax_t decode_varint(const unsigned char **);
+uint8_t encode_varint(uint64_t, unsigned char *);
+uint64_t decode_varint(const unsigned char **);
 
 #endif /* VARINT_H */

-- 
2.51.0.700.g236ee7b076.dirty

[PATCH v8 6/9] varint: reimplement as test balloon for Rust

[Patrick Steinhardt]

Implement a trivial test balloon for our Rust build infrastructure by
reimplementing the "varint.c" subsystem in Rust. This subsystem is
chosen because it is trivial to convert and because it doesn't have any
dependencies to other components of Git.

If support for Rust is enabled, we stop compiling "varint.c" and instead
compile and use "src/varint.rs".

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 Makefile        |  3 ++
 meson.build     |  5 +++-
 src/lib.rs      |  1 +
 src/meson.build |  1 +
 src/varint.rs   | 92 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 101 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 31e79342e1d..2a7fc5cb1f3 100644
--- a/Makefile
+++ b/Makefile
@@ -1307,7 +1307,9 @@ LIB_OBJS += urlmatch.o
 LIB_OBJS += usage.o
 LIB_OBJS += userdiff.o
 LIB_OBJS += utf8.o
+ifndef WITH_RUST
 LIB_OBJS += varint.o
+endif
 LIB_OBJS += version.o
 LIB_OBJS += versioncmp.o
 LIB_OBJS += walker.o
@@ -1499,6 +1501,7 @@ CLAR_TEST_OBJS += $(UNIT_TEST_DIR)/unit-test.o
 UNIT_TEST_OBJS += $(UNIT_TEST_DIR)/test-lib.o
 
 RUST_SOURCES += src/lib.rs
+RUST_SOURCES += src/varint.rs
 
 GIT-VERSION-FILE: FORCE
 	@OLD=$$(cat $@ 2>/dev/null || :) && \
diff --git a/meson.build b/meson.build
index 234a9e9d6fd..37dfa286017 100644
--- a/meson.build
+++ b/meson.build
@@ -522,7 +522,6 @@ libgit_sources = [
   'usage.c',
   'userdiff.c',
   'utf8.c',
-  'varint.c',
   'version.c',
   'versioncmp.c',
   'walker.c',
@@ -1707,6 +1706,10 @@ rust_option = get_option('rust').disable_auto_if(not cargo.found())
 if rust_option.allowed()
   subdir('src')
   libgit_c_args += '-DWITH_RUST'
+else
+  libgit_sources += [
+    'varint.c',
+  ]
 endif
 
 libgit = declare_dependency(
diff --git a/src/lib.rs b/src/lib.rs
index e69de29bb2d..9da70d8b57d 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -0,0 +1 @@
+pub mod varint;
diff --git a/src/meson.build b/src/meson.build
index c8d874b2106..25b9ad5a147 100644
--- a/src/meson.build
+++ b/src/meson.build
@@ -1,5 +1,6 @@
 libgit_rs_sources = [
   'lib.rs',
+  'varint.rs',
 ]
 
 # Unfortunately we must use a wrapper command to move the output file into the
diff --git a/src/varint.rs b/src/varint.rs
new file mode 100644
index 00000000000..6e610bdd8e0
--- /dev/null
+++ b/src/varint.rs
@@ -0,0 +1,92 @@
+#[no_mangle]
+pub unsafe extern "C" fn decode_varint(bufp: *mut *const u8) -> u64 {
+    let mut buf = *bufp;
+    let mut c = *buf;
+    let mut val = u64::from(c & 127);
+
+    buf = buf.add(1);
+
+    while (c & 128) != 0 {
+        val = val.wrapping_add(1);
+        if val == 0 || val.leading_zeros() < 7 {
+            return 0; // overflow
+        }
+
+        c = *buf;
+        buf = buf.add(1);
+
+        val = (val << 7) + u64::from(c & 127);
+    }
+
+    *bufp = buf;
+    val
+}
+
+#[no_mangle]
+pub unsafe extern "C" fn encode_varint(value: u64, buf: *mut u8) -> u8 {
+    let mut varint: [u8; 16] = [0; 16];
+    let mut pos = varint.len() - 1;
+
+    varint[pos] = (value & 127) as u8;
+
+    let mut value = value >> 7;
+    while value != 0 {
+        pos -= 1;
+        value -= 1;
+        varint[pos] = 128 | (value & 127) as u8;
+        value >>= 7;
+    }
+
+    if !buf.is_null() {
+        std::ptr::copy_nonoverlapping(varint.as_ptr().add(pos), buf, varint.len() - pos);
+    }
+
+    (varint.len() - pos) as u8
+}
+
+#[cfg(test)]
+mod tests {
+    use super::*;
+
+    #[test]
+    fn test_decode_varint() {
+        unsafe {
+            assert_eq!(decode_varint(&mut [0x00].as_slice().as_ptr()), 0);
+            assert_eq!(decode_varint(&mut [0x01].as_slice().as_ptr()), 1);
+            assert_eq!(decode_varint(&mut [0x7f].as_slice().as_ptr()), 127);
+            assert_eq!(decode_varint(&mut [0x80, 0x00].as_slice().as_ptr()), 128);
+            assert_eq!(decode_varint(&mut [0x80, 0x01].as_slice().as_ptr()), 129);
+            assert_eq!(decode_varint(&mut [0x80, 0x7f].as_slice().as_ptr()), 255);
+
+            // Overflows are expected to return 0.
+            assert_eq!(decode_varint(&mut [0x88; 16].as_slice().as_ptr()), 0);
+        }
+    }
+
+    #[test]
+    fn test_encode_varint() {
+        unsafe {
+            let mut varint: [u8; 16] = [0; 16];
+
+            assert_eq!(encode_varint(0, std::ptr::null_mut()), 1);
+
+            assert_eq!(encode_varint(0, varint.as_mut_slice().as_mut_ptr()), 1);
+            assert_eq!(varint, [0; 16]);
+
+            assert_eq!(encode_varint(10, varint.as_mut_slice().as_mut_ptr()), 1);
+            assert_eq!(varint, [10, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+
+            assert_eq!(encode_varint(127, varint.as_mut_slice().as_mut_ptr()), 1);
+            assert_eq!(varint, [127, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+
+            assert_eq!(encode_varint(128, varint.as_mut_slice().as_mut_ptr()), 2);
+            assert_eq!(varint, [128, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+
+            assert_eq!(encode_varint(129, varint.as_mut_slice().as_mut_ptr()), 2);
+            assert_eq!(varint, [128, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+
+            assert_eq!(encode_varint(255, varint.as_mut_slice().as_mut_ptr()), 2);
+            assert_eq!(varint, [128, 127, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
+        }
+    }
+}

-- 
2.51.0.700.g236ee7b076.dirty

[PATCH v8 7/9] BreakingChanges: announce Rust becoming mandatory

[Patrick Steinhardt]

Over the last couple of years the appetite for bringing Rust into the
codebase has grown significantly across the developer base. Introducing
Rust is a major change though and has ramifications for the whole
ecosystem:

  - Some platforms have a Rust toolchain available, but have not yet
    integrated it into their build infrastructure.

  - Some platforms don't have any support for Rust at all.

  - Some platforms may have to figure out how to fit Rust into their
    bootstrapping sequence.

Due to this, and given that Git is a critical piece of infrastructure
for the whole industry, we cannot just introduce such a heavyweight
dependency without doing our due diligence.

Instead, preceding commits have introduced a test balloon into our build
infrastructure that convert one tiny subsystem to use Rust. For now,
using Rust to build that subsystem is entirely optional -- if no Rust
support is available, we continue to use the C implementation. This test
balloon has the intention to give distributions time and let them ease
into our adoption of Rust.

Having multiple implementations of the same subsystem is not sustainable
though, and the plan is to eventually be able to use Rust freely all
across our codebase. As such, there is the intent to make Rust become a
mandatory part of our build process.

Add an announcement to our breaking changes that Rust will become
mandatory in Git 3.0. A (very careful and non-binding) estimate might be
that this major release might be released in the second half of next
year, which should give distributors enough time to prepare for the
change.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 Documentation/BreakingChanges.adoc | 45 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/Documentation/BreakingChanges.adoc b/Documentation/BreakingChanges.adoc
index f8d2eba061..c21f902134 100644
--- a/Documentation/BreakingChanges.adoc
+++ b/Documentation/BreakingChanges.adoc
@@ -165,6 +165,51 @@ A prerequisite for this change is that the ecosystem is ready to support the
 "reftable" format. Most importantly, alternative implementations of Git like
 JGit, libgit2 and Gitoxide need to support it.
 
+* Git will require Rust as a mandatory part of the build process. While Git
+  already started to adopt Rust in Git 2.49, all parts written in Rust are
+  optional for the time being. This includes:
++
+  ** The Rust wrapper around libgit.a that is part of "contrib/" and which has
+     been introduced in Git 2.49.
+  ** Subsystems that have an alternative implementation in Rust to test
+     interoperability between our C and Rust codebase.
+  ** Newly written features that are not mission critical for a fully functional
+     Git client.
++
+These changes are meant as test balloons to allow distributors of Git to prepare
+for Rust becoming a mandatory part of the build process. There will be multiple
+milestones for the introduction of Rust:
++
+--
+1. Initially, with Git 2.52, support for Rust will be auto-detected by Meson and
+   disabled in our Makefile so that the project can sort out the initial
+   infrastructure.
+2. In Git 2.53, both build systems will default-enable support for Rust.
+   Consequently, builds will break by default if Rust is not available on the
+   build host. The use of Rust can still be explicitly disabled via build
+   flags.
+3. In Git 3.0, the build options will be removed and support for Rust is
+   mandatory.
+--
++
+You can explicitly ask both Meson and our Makefile-based system to enable Rust
+by saying `meson configure -Drust=enabled` and `make WITH_RUST=YesPlease`,
+respectively.
++
+The Git project will declare the last version before Git 3.0 to be a long-term
+support release. This long-term release will receive important bug fixes for at
+least four release cycles and security fixes for six release cycles. The Git
+project will hand over maintainership of the long-term release to distributors
+in case they need to extend the life of that long-term release even further.
+Details of how this long-term release will be handed over to the community will
+be discussed once the Git project decides to stop officially supporting it.
++
+We will evaluate the impact on downstream distributions before making Rust
+mandatory in Git 3.0. If we see that the impact on downstream distributions
+would be significant, we may decide to defer this change to a subsequent minor
+release. This evaluation will also take into account our own experience with
+how painful it is to keep Rust an optional component.
+
 === Removals
 
 * Support for grafting commits has long been superseded by git-replace(1).

-- 
2.51.0.700.g236ee7b076.dirty

[PATCH v8 8/9] ci: convert "pedantic" job into full build with breaking changes

[Patrick Steinhardt]

The "pedantic" CI job is building on Fedora with `DEVOPTS=pedantic`.
This build flag doesn't do anything anymore starting with 6a8cbc41ba
(developer: enable pedantic by default, 2021-09-03), where we have
flipped the default so that developers have to opt-out of pedantic
builds via the "no-pedantic" option. As such, all this job really does
is to do a normal build on Fedora, which isn't all that interesting.

Convert that job into a full build-and-test job that uses Meson with
breaking changes enabled. This plugs two gaps:

  - We now test on another distro that we didn't run tests on
    beforehand.

  - We verify that breaking changes work as expected with Meson.

Furthermore, in a subsequent commit we'll modify both jobs that use
breaking changes to also enable Rust. By converting the Fedora job to
use Meson, we ensure that we test our Rust build infrastructure for both
build systems.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 .github/workflows/main.yml |  4 ++--
 .gitlab-ci.yml             |  4 ++--
 ci/install-dependencies.sh |  6 +++++-
 ci/run-build-and-tests.sh  | 29 ++++++++---------------------
 4 files changed, 17 insertions(+), 26 deletions(-)

diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index d122e79415..393ea4d1cc 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -379,6 +379,8 @@ jobs:
         - jobname: linux-breaking-changes
           cc: gcc
           image: ubuntu:rolling
+        - jobname: fedora-breaking-changes-meson
+          image: fedora:latest
         - jobname: linux-leaks
           image: ubuntu:rolling
           cc: gcc
@@ -396,8 +398,6 @@ jobs:
         # Supported until 2025-04-02.
         - jobname: linux32
           image: i386/ubuntu:focal
-        - jobname: pedantic
-          image: fedora:latest
         # A RHEL 8 compatible distro.  Supported until 2029-05-31.
         - jobname: almalinux-8
           image: almalinux:8
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index af10ebb59a..4248506909 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -45,6 +45,8 @@ test:linux:
       - jobname: linux-breaking-changes
         image: ubuntu:20.04
         CC: gcc
+      - jobname: fedora-breaking-changes-meson
+        image: fedora:latest
       - jobname: linux-TEST-vars
         image: ubuntu:20.04
         CC: gcc
@@ -58,8 +60,6 @@ test:linux:
       - jobname: linux-asan-ubsan
         image: ubuntu:rolling
         CC: clang
-      - jobname: pedantic
-        image: fedora:latest
       - jobname: linux-musl-meson
         image: alpine:latest
       - jobname: linux32
diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh
index d061a47293..35bd05b85b 100755
--- a/ci/install-dependencies.sh
+++ b/ci/install-dependencies.sh
@@ -30,8 +30,12 @@ alpine-*)
 		bash cvs gnupg perl-cgi perl-dbd-sqlite perl-io-tty >/dev/null
 	;;
 fedora-*|almalinux-*)
+	case "$jobname" in
+	*-meson)
+		MESON_DEPS="meson ninja";;
+	esac
 	dnf -yq update >/dev/null &&
-	dnf -yq install shadow-utils sudo make gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null
+	dnf -yq install shadow-utils sudo make pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel $MESON_DEPS >/dev/null
 	;;
 ubuntu-*|i386/ubuntu-*|debian-*)
 	# Required so that apt doesn't wait for user input on certain packages.
diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index 01823fd0f1..3680446649 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -5,12 +5,11 @@
 
 . ${0%/*}/lib.sh
 
-run_tests=t
-
 case "$jobname" in
-linux-breaking-changes)
+fedora-breaking-changes-musl|linux-breaking-changes)
 	export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
 	export WITH_BREAKING_CHANGES=YesPlease
+	MESONFLAGS="$MESONFLAGS -Dbreaking_changes=true"
 	;;
 linux-TEST-vars)
 	export OPENSSL_SHA1_UNSAFE=YesPlease
@@ -36,12 +35,6 @@ linux-sha256)
 linux-reftable|linux-reftable-leaks|osx-reftable)
 	export GIT_TEST_DEFAULT_REF_FORMAT=reftable
 	;;
-pedantic)
-	# Don't run the tests; we only care about whether Git can be
-	# built.
-	export DEVOPTS=pedantic
-	run_tests=
-	;;
 esac
 
 case "$jobname" in
@@ -54,21 +47,15 @@ case "$jobname" in
 		-Dtest_output_directory="${TEST_OUTPUT_DIRECTORY:-$(pwd)/t}" \
 		$MESONFLAGS
 	group "Build" meson compile -C build --
-	if test -n "$run_tests"
-	then
-		group "Run tests" meson test -C build --print-errorlogs --test-args="$GIT_TEST_OPTS" || (
-			./t/aggregate-results.sh "${TEST_OUTPUT_DIRECTORY:-t}/test-results"
-			handle_failed_tests
-		)
-	fi
+	group "Run tests" meson test -C build --print-errorlogs --test-args="$GIT_TEST_OPTS" || (
+		./t/aggregate-results.sh "${TEST_OUTPUT_DIRECTORY:-t}/test-results"
+		handle_failed_tests
+	)
 	;;
 *)
 	group Build make
-	if test -n "$run_tests"
-	then
-		group "Run tests" make test ||
-		handle_failed_tests
-	fi
+	group "Run tests" make test ||
+	handle_failed_tests
 	;;
 esac
 

-- 
2.51.0.700.g236ee7b076.dirty

[PATCH v8 9/9] ci: enable Rust for breaking-changes jobs

[Patrick Steinhardt]

Enable Rust for our breaking-changes jobs so that we can verify that the
build infrastructure and the converted Rust subsystems work as expected.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 ci/install-dependencies.sh | 4 ++--
 ci/run-build-and-tests.sh  | 2 ++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh
index 35bd05b85b..0d3aa496fc 100755
--- a/ci/install-dependencies.sh
+++ b/ci/install-dependencies.sh
@@ -35,7 +35,7 @@ fedora-*|almalinux-*)
 		MESON_DEPS="meson ninja";;
 	esac
 	dnf -yq update >/dev/null &&
-	dnf -yq install shadow-utils sudo make pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel $MESON_DEPS >/dev/null
+	dnf -yq install shadow-utils sudo make pkg-config gcc findutils diffutils perl python3 gawk gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel $MESON_DEPS cargo >/dev/null
 	;;
 ubuntu-*|i386/ubuntu-*|debian-*)
 	# Required so that apt doesn't wait for user input on certain packages.
@@ -62,7 +62,7 @@ ubuntu-*|i386/ubuntu-*|debian-*)
 		make libssl-dev libcurl4-openssl-dev libexpat-dev wget sudo default-jre \
 		tcl tk gettext zlib1g-dev perl-modules liberror-perl libauthen-sasl-perl \
 		libemail-valid-perl libio-pty-perl libio-socket-ssl-perl libnet-smtp-ssl-perl libdbd-sqlite3-perl libcgi-pm-perl \
-		libsecret-1-dev libpcre2-dev meson ninja-build pkg-config \
+		libsecret-1-dev libpcre2-dev meson ninja-build pkg-config cargo \
 		${CC_PACKAGE:-${CC:-gcc}} $PYTHON_PACKAGE
 
 	case "$distro" in
diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index 3680446649..c718bd101a 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -9,7 +9,9 @@ case "$jobname" in
 fedora-breaking-changes-musl|linux-breaking-changes)
 	export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
 	export WITH_BREAKING_CHANGES=YesPlease
+	export WITH_RUST=YesPlease
 	MESONFLAGS="$MESONFLAGS -Dbreaking_changes=true"
+	MESONFLAGS="$MESONFLAGS -Drust=enabled"
 	;;
 linux-TEST-vars)
 	export OPENSSL_SHA1_UNSAFE=YesPlease

-- 
2.51.0.700.g236ee7b076.dirty

Re: [PATCH v8 0/9] Introduce Rust and announce that it will become mandatory

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

> this small patch series introduces Rust into the core of Git. This patch
> series is designed as a test balloon, similar to how we introduced test
> balloons for C99 features in the past. The goal is threefold:
>
>   - Give us some time to experiment with Rust and introduce proper build
>     infrastructure.
>
>   - Give distributors time to ease into the new toolchain requirements.
>     Introducing Rust is impossible for some platforms and hard for
>     others.
>
>   - Announce that Git 3.0 will make Rust a mandatory part of our build
>     infrastructure.
>
> The test balloon itself is quite uninteresting: I've chosen to convert
> the "varint.c" subsystem, mostly because it is trivial and does not have
> any dependencies. But it does allow us to verify that C to Rust interop
> works as expected, and to play around with tooling. All tests pass with
> the "varint.rs" implementation.
>
> For now, the series only contains support for Meson. If we agree to go
> down this route I'll also introduce support for Rust into our Makefiles
> at a later point in time.

Keeping the initial part of the cover letter verbatim is a bit
confusing for those who have forgotten what they read in previous
iterations ;-) I think a more recent iterations did have Makefile
support, and this (hopefully final) one, too.

> Furthermore missing is additional tooling:
>
>   - At least one CI job to verify that Rust builds and works as
>     expected.
>
>   - Tooling and CI jobs to ensure that we have consistent formatting via
>     `cargo format`.
>
> And probably lots more. As said, the entire goal is for us to have an
> easy playground that we can experiment on and develop the infrastructure
> incrementally without yet having to commit to anything.
>
> I'm mostly splitting out the topic of introducing Rust from the larger
> series that introduce it into xdiff so that we can focus more on the
> actual process of introducing Rust into Git and less on the potential
> features that we want to build on top of it.

OK.

> Changes in v2:
> ...
> Changes in v3:
> ...
> Changes in v4:
> ...
> Changes in v5:
> ...
> Changes in v6:
> ...
> Changes in v7:
> ...
> Changes in v8:
>   - Some final typo fixes.
>   - Link to v7: https://lore.kernel.org/r/20250925-b4-pks-rust-breaking-change-v7-0-4e49dcb904d5@pks.im

Indeed.  I have a slight preference to see these "deltas" in reverse
order but it may be just me.  I can read backwards, especially if
each item is small ;-)

Thanks.

Re: [PATCH v8 0/9] Introduce Rust and announce that it will become mandatory

[Patrick Steinhardt]

On Thu, Oct 02, 2025 at 09:38:19AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> > Changes in v2:
> > ...
> > Changes in v3:
> > ...
> > Changes in v4:
> > ...
> > Changes in v5:
> > ...
> > Changes in v6:
> > ...
> > Changes in v7:
> > ...
> > Changes in v8:
> >   - Some final typo fixes.
> >   - Link to v7: https://lore.kernel.org/r/20250925-b4-pks-rust-breaking-change-v7-0-4e49dcb904d5@pks.im
> 
> Indeed.  I have a slight preference to see these "deltas" in reverse
> order but it may be just me.  I can read backwards, especially if
> each item is small ;-)

I can change that ordering going forward. I don't really mind it much
either way.

Patrick

Re: [PATCH v8 0/9] Introduce Rust and announce that it will become mandatory

[Ezekiel Newren]

On Thu, Oct 2, 2025 at 1:30 AM Patrick Steinhardt <ps@pks.im> wrote:
> Range-diff versus v7:
>
>  1:  3f916bebd4 =  1:  bf7b33291d meson: add infrastructure to build internal Rust library
>  2:  ed849dcfed =  2:  59e7879c63 Makefile: reorder sources after includes
>  3:  955f262ef5 =  3:  635cebc0a6 Makefile: introduce infrastructure to build internal Rust library
>  4:  7a90192b5a =  4:  43b50563cc help: report on whether or not Rust is enabled
>  5:  9365a78efd !  5:  37d03d7774 varint: use explicit width for integers
>     @@ Metadata
>       ## Commit message ##
>          varint: use explicit width for integers
>
>     -    The varint subsystem currently uses implcit widths for integers. On the
>     +    The varint subsystem currently uses implicit widths for integers. On the
>          one hand we use `uintmax_t` for the actual value. On the other hand, we
>          use `int` for the length of the encoded varint.
>
>     -    Both of these have known maximum vaules, as we only support at most 16
>     +    Both of these have known maximum values, as we only support at most 16
>          bytes when encoding varints. Thus, we know that we won't ever exceed
>          `uint64_t` for the actual value and `uint8_t` for the prefix length.
>
>  6:  e7e0621b68 =  6:  0d265f9675 varint: reimplement as test balloon for Rust
>  7:  8d8e9cb8a8 =  7:  a6e0d668f0 BreakingChanges: announce Rust becoming mandatory
>  8:  07dc8171ac =  8:  79470835fd ci: convert "pedantic" job into full build with breaking changes
>  9:  708a0d3c67 =  9:  67f8dea13f ci: enable Rust for breaking-changes jobs
>
> ---
> base-commit: 2462961280690837670d997bde64bd4ebf8ae66d
> change-id: 20250904-b4-pks-rust-breaking-change-7167d9d3e37d

I think it's ready to be merged.

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Sergey Fedorov]

This will be a disaster, please consider not making rust mandatory.
It will break git for all systems without rust, in effect killing not only possibility to use GitHub and other git-based services, but also breaking build systems, since many ports – and package managers – rely on git to fetch sources.
As for local version control, git could be replaced with some alternative (likely inferior, but at least that is not the end).
There is no replacement, AFAIK, for build systems and for git-based online services.

P. S. In case anyone wonders, this is personally relevant for me: I won’t be able to continue contributing to open-source anymore (at least certainly not like in past years) with git being unusable due to broken rust.

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Ezekiel Newren]

On Fri, Sep 19, 2025 at 11:36 AM Sergey Fedorov
<barracuda@macos-powerpc.org> wrote:
> This will be a disaster, please consider not making rust mandatory.
> It will break git for all systems without rust, in effect killing not only possibility to use GitHub and other git-based services, but also breaking build systems, since many ports – and package managers – rely on git to fetch sources.
> As for local version control, git could be replaced with some alternative (likely inferior, but at least that is not the end).
> There is no replacement, AFAIK, for build systems and for git-based online services.
>
> P. S. In case anyone wonders, this is personally relevant for me: I won’t be able to continue contributing to open-source anymore (at least certainly not like in past years) with git being unusable due to broken rust.

The mailing list has had extremely heated debates about this, and
there are many who would agree and disagree with you. So please try to
read my comment as a genuine interest in trying to understand your
situation. I would like to hear why making Rust mandatory would make
using and contributing to Git insurmountable. We know for sure that
NonStop currently does not support Rust at all, and that there are
problems with porting Rust to Gentoo, but I'd like to hear what OSes
and Architectures you use personally and professionally and why adding
Rust would be a bad idea. Is it corporate policy? Is it that the Rust
toolchain doesn't exist for your os/arch? Is it that Rust is a new
language and isn't as battle tested as C? Something else?

I believe that even "I don't know Rust and don't want to learn it."
would be a valid comment to add as well. I think the discussion of
Rust has been so hot because we (the Git community) don't understand
everyone's situations and how they'll be affected, and what could
possibly be done to address concerns.

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Collin Funk]

Ezekiel Newren <ezekielnewren@gmail.com> writes:

> On Fri, Sep 19, 2025 at 11:36 AM Sergey Fedorov
> <barracuda@macos-powerpc.org> wrote:
>> This will be a disaster, please consider not making rust mandatory.
>> It will break git for all systems without rust, in effect killing not only possibility to use GitHub and other git-based services, but also breaking build systems, since many ports – and package managers – rely on git to fetch sources.
>> As for local version control, git could be replaced with some alternative (likely inferior, but at least that is not the end).
>> There is no replacement, AFAIK, for build systems and for git-based online services.
>>
>> P. S. In case anyone wonders, this is personally relevant for me: I won’t be able to continue contributing to open-source anymore (at least certainly not like in past years) with git being unusable due to broken rust.
>
> The mailing list has had extremely heated debates about this, and
> there are many who would agree and disagree with you. So please try to
> read my comment as a genuine interest in trying to understand your
> situation. I would like to hear why making Rust mandatory would make
> using and contributing to Git insurmountable. We know for sure that
> NonStop currently does not support Rust at all, and that there are
> problems with porting Rust to Gentoo, but I'd like to hear what OSes
> and Architectures you use personally and professionally and why adding
> Rust would be a bad idea. Is it corporate policy? Is it that the Rust
> toolchain doesn't exist for your os/arch? Is it that Rust is a new
> language and isn't as battle tested as C? Something else?
>
> I believe that even "I don't know Rust and don't want to learn it."
> would be a valid comment to add as well. I think the discussion of
> Rust has been so hot because we (the Git community) don't understand
> everyone's situations and how they'll be affected, and what could
> possibly be done to address concerns.

Based on the domain of their email they use MacOS PowerPC. AFAIK LLVM
has not supported it for a long time.

Collin

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Florian Märkl]

> Ezekiel Newren <ezekielnewren@gmail.com> wrote:
> 
> I'd like to hear what OSes
> and Architectures you use personally and professionally and why adding
> Rust would be a bad idea.

To add some specific cases from my side as well, problematic platforms include
Mac OS X on ppc as well as OpenBSD/macppc (32-bit). Both of these are still
relevant, as OpenBSD is actively maintained on this architecture and Mac OS X
10.5 is supported by MacPorts, resulting in a system with modern tools that is
still able to run and debug certain legacy software.

In particular, in the Rizin project, we use both platforms regularly to test
our code for architecture and OS-specific bugs, and we also support them to run
Rizin itself for debugging and analyzing software there.

I do not advocate not adopting Rust because of the language itself, but I think
it is important to compare the maturity of the compiler and ecosystem to the
project that will strictly depend on it.

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Michael Orlitzky]

> We know for sure that NonStop currently does not support Rust at
> all, and that there are problems with porting Rust to Gentoo, but
> I'd like to hear what OSes and Architectures you use personally and
> professionally and why adding Rust would be a bad idea. Is it
> corporate policy? Is it that the Rust toolchain doesn't exist for
> your os/arch? Is it that Rust is a new language and isn't as battle
> tested as C? Something else?

There is no problem with supporting rust on Gentoo. Gentoo users build
from source, and rust is a problem for anyone who builds from
source. I'm writing this on a riscv/musl system. If there are no
binaries for your CPU/libc, let me tell you, it's not fun. And this is
like, my job. A normal person would be completely helpless.

Nevertheless, the arch support issues are secondary. I'm sure it's a
lot of fun for the people who are writing rust code to do cargo
updates in the two or three directories they work in all day. But I'm
not writing rust code, don't care what language git is written in, and
have hundreds of other packages to keep up-to-date on multiple
machines. I want to be able to use my package manager to do that
efficiently. You know, the main tangible benefit of using a linux
distribution.

But every distribution is "packaging" rust the same way. They're
bundling random old versions of crates in violation of their own
policies because the ecosystem is unstable and the tooling encourages
tight coupling. By requiring rust, you are require me to go back to
managing dependencies like I'm on Windows XP again. Git is the most
important program I use, but it's not more important than package
management itself.

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Sam James]

Michael Orlitzky <michael@orlitzky.com> writes:

>> We know for sure that NonStop currently does not support Rust at
>> all, and that there are problems with porting Rust to Gentoo, but
>> I'd like to hear what OSes and Architectures you use personally and
>> professionally and why adding Rust would be a bad idea. Is it
>> corporate policy? Is it that the Rust toolchain doesn't exist for
>> your os/arch? Is it that Rust is a new language and isn't as battle
>> tested as C? Something else?
>
> There is no problem with supporting rust on Gentoo. Gentoo users build
> from source, and rust is a problem for anyone who builds from
> source. I'm writing this on a riscv/musl system. If there are no
> binaries for your CPU/libc, let me tell you, it's not fun. And this is
> like, my job. A normal person would be completely helpless.
>

That is precisely the problem that Eli and I have been describing in
this thread (along with some more minor issues for Prefix to figure out,
and then missing arch support where Rust doesn't support it at all).

He is referencing issues we brought up earlier in the (various) threads,
not plucking it out of thin air.

> Nevertheless, the arch support issues are secondary. I'm sure it's a
> lot of fun for the people who are writing rust code to do cargo
> updates in the two or three directories they work in all day. But I'm
> not writing rust code, don't care what language git is written in, and
> have hundreds of other packages to keep up-to-date on multiple
> machines. I want to be able to use my package manager to do that
> efficiently. You know, the main tangible benefit of using a linux
> distribution.
>
> But every distribution is "packaging" rust the same way. They're
> bundling random old versions of crates in violation of their own
> policies because the ecosystem is unstable and the tooling encourages
> tight coupling. By requiring rust, you are require me to go back to
> managing dependencies like I'm on Windows XP again. Git is the most
> important program I use, but it's not more important than package
> management itself.

Indeed, this is all terrible, and I agree with you, of course.

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 3436 bytes --]

On 2025-09-22 at 15:59:49, Michael Orlitzky wrote:
> There is no problem with supporting rust on Gentoo. Gentoo users build
> from source, and rust is a problem for anyone who builds from
> source. I'm writing this on a riscv/musl system. If there are no
> binaries for your CPU/libc, let me tell you, it's not fun. And this is
> like, my job. A normal person would be completely helpless.

This is a problem with languages that bootstrap from earlier versions of
themselves.  It also happens with other, less common languages.  GHC (a
Haskell runtime) also has this problem and any distro that ships pandoc
has to deal with it.

It is certainly inconvenient, but there is mrustc to help the bootstrap
process.  Granted, it does not work everywhere yet, but it should also
not be too difficult to make it do so.

I do think the difficulty is worth it, though.  With Rust, we're going
to get code that is thread-safe and memory-safe by the virtue of the
fact that it compiles and that will allow us to have threading in more
parts of the code where it might benefit us.  I also cannot tell you how
many segfaults and null pointer dereferences I've written in Git (some
in the past week) that are just no longer possible with Rust.

As my proposal originally mentioned, there is enormous pressure from
governments, security professionals, and large companies to improve
memory safety, which I believe are legitimate concerns.  If we want Git
to continue to be used widely, then we need to address those issues and
Rust seems to be the best possible way to do that.  I don't think
continuing in C only is going to be viable long term.

> Nevertheless, the arch support issues are secondary. I'm sure it's a
> lot of fun for the people who are writing rust code to do cargo
> updates in the two or three directories they work in all day. But I'm
> not writing rust code, don't care what language git is written in, and
> have hundreds of other packages to keep up-to-date on multiple
> machines. I want to be able to use my package manager to do that
> efficiently. You know, the main tangible benefit of using a linux
> distribution.

I don't think this is going to happen as you anticipate it will.  My
original policy was to target Debian stable's release for a year after
the new Debian stable came out and that will make using many crates
nearly impossible.  We are going to have to be _extremely_ careful about
dependencies in general and the things we are likely to use are things
like bindgen and cbindgen, where typically an old version will work just
fine and which are already packaged in major distros.  We are not going
to be adding dependencies willy-nilly and running `cargo update` every
other day.

> But every distribution is "packaging" rust the same way. They're
> bundling random old versions of crates in violation of their own
> policies because the ecosystem is unstable and the tooling encourages
> tight coupling. By requiring rust, you are require me to go back to
> managing dependencies like I'm on Windows XP again. Git is the most
> important program I use, but it's not more important than package
> management itself.

I expect Debian already packages the crates that we need in acceptable
versions, and I assume other distros do as well, so I don't anticipate
this being a problem for us.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Sam James]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> On 2025-09-22 at 15:59:49, Michael Orlitzky wrote:
>> There is no problem with supporting rust on Gentoo. Gentoo users build
>> from source, and rust is a problem for anyone who builds from
>> source. I'm writing this on a riscv/musl system. If there are no
>> binaries for your CPU/libc, let me tell you, it's not fun. And this is
>> like, my job. A normal person would be completely helpless.
>
> This is a problem with languages that bootstrap from earlier versions of
> themselves.  It also happens with other, less common languages.  GHC (a
> Haskell runtime) also has this problem and any distro that ships pandoc
> has to deal with it.

Usually there's nothing too critical in such a language ;)

>
> It is certainly inconvenient, but there is mrustc to help the bootstrap
> process.  Granted, it does not work everywhere yet, but it should also
> not be too difficult to make it do so.
>
> I do think the difficulty is worth it, though.  With Rust, we're going
> to get code that is thread-safe and memory-safe by the virtue of the
> fact that it compiles and that will allow us to have threading in more
> parts of the code where it might benefit us.  I also cannot tell you how
> many segfaults and null pointer dereferences I've written in Git (some
> in the past week) that are just no longer possible with Rust.
>
> As my proposal originally mentioned, there is enormous pressure from
> governments, security professionals, and large companies to improve
> memory safety, which I believe are legitimate concerns.  If we want Git
> to continue to be used widely, then we need to address those issues and
> Rust seems to be the best possible way to do that.  I don't think
> continuing in C only is going to be viable long term.
>
>> Nevertheless, the arch support issues are secondary. I'm sure it's a
>> lot of fun for the people who are writing rust code to do cargo
>> updates in the two or three directories they work in all day. But I'm
>> not writing rust code, don't care what language git is written in, and
>> have hundreds of other packages to keep up-to-date on multiple
>> machines. I want to be able to use my package manager to do that
>> efficiently. You know, the main tangible benefit of using a linux
>> distribution.
>
> I don't think this is going to happen as you anticipate it will.  My
> original policy was to target Debian stable's release for a year after
> the new Debian stable came out and that will make using many crates
> nearly impossible.  We are going to have to be _extremely_ careful about
> dependencies in general and the things we are likely to use are things
> like bindgen and cbindgen, where typically an old version will work just
> fine and which are already packaged in major distros.  We are not going
> to be adding dependencies willy-nilly and running `cargo update` every
> other day.

That brings me significant comfort and I'm glad to hear it. I hope
others agree with your position on having significant restraint on the
use of external crates.

git has always been quite good about dependencies pre-Rust.

>
>> But every distribution is "packaging" rust the same way. They're
>> bundling random old versions of crates in violation of their own
>> policies because the ecosystem is unstable and the tooling encourages
>> tight coupling. By requiring rust, you are require me to go back to
>> managing dependencies like I'm on Windows XP again. Git is the most
>> important program I use, but it's not more important than package
>> management itself.
>
> I expect Debian already packages the crates that we need in acceptable
> versions, and I assume other distros do as well, so I don't anticipate
> this being a problem for us.

Yes, I expect on our end in Gentoo, that we'll probably need to use this
to finally migrate to a Debian-style handling of crates, though that's
not your problem.

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Patrick Steinhardt]

On Mon, Sep 22, 2025 at 10:47:03PM +0100, Sam James wrote:
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> > I don't think this is going to happen as you anticipate it will.  My
> > original policy was to target Debian stable's release for a year after
> > the new Debian stable came out and that will make using many crates
> > nearly impossible.  We are going to have to be _extremely_ careful about
> > dependencies in general and the things we are likely to use are things
> > like bindgen and cbindgen, where typically an old version will work just
> > fine and which are already packaged in major distros.  We are not going
> > to be adding dependencies willy-nilly and running `cargo update` every
> > other day.
> 
> That brings me significant comfort and I'm glad to hear it. I hope
> others agree with your position on having significant restraint on the
> use of external crates.
> 
> git has always been quite good about dependencies pre-Rust.

I certainly echo brian's sentiment here. Rust dependencies are easy to
use, but they are also one part that worries me quite significantly due
to multiple reasons:

  - Pulling in many dependencies opens us up for supply chain attacks.

  - Every single dependency is a source for vulnerabilities in general.
    We're already good enough in creating these ourselves.

  - Dependencies may have hard requirements on the Rust version,
    requiring us to bump the minimum required toolchain version.

  - In general, I'm not a fan of having even dozens of dependencies. It
    causes bloat and externalizes a bunch of knowledge.

So I think we should and need to be very conservative about adding any
new dependencies. There will be cases where it makes sense, but every
new dependency should be well-reasoned.

After this patch series lands, one of the next steps will also be to add
a policy for how we want to use Rust in the Git project. brian has
already written such a policy (see e.g. [1]), and it already mentions
that we'll need to be careful about adding dependencies. Might be worth
it to flesh that part out a bit more, but that's something we can
discuss at a later point.

Patrick

[1]: <6d065f550fe871cf010409f7bd2a63438cf52723.1756496539.git.gitgitgadget@gmail.com>

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Michael Orlitzky]

On Mon, 2025-09-22 at 21:35 +0000, brian m. carlson wrote:
> On 2025-09-22 at 15:59:49, Michael Orlitzky wrote:
> > There is no problem with supporting rust on Gentoo. Gentoo users build
> > from source, and rust is a problem for anyone who builds from
> > source. I'm writing this on a riscv/musl system. If there are no
> > binaries for your CPU/libc, let me tell you, it's not fun. And this is
> > like, my job. A normal person would be completely helpless.
> 
> This is a problem with languages that bootstrap from earlier versions of
> themselves.  It also happens with other, less common languages.  GHC (a
> Haskell runtime) also has this problem and any distro that ships pandoc
> has to deal with it.

Spectacular example.

In Gentoo we support the following arches: alpha, amd64, arm, arm64,
hppa, loong, m68k, mips, ppc, ppc64, riscv, s390, sparc, and x86. We
support both glibc and musl, for 23 arch/libc combinations (we don't
support musl on every arch).

Pandoc supports: amd64, arm64, ppc64, riscv and x86, but only on glibc.
That's 5 out of 23. If you're able to use GHC 9.2 released in 2021,
that is. Otherwise it's 0 out of 23. No one "has to deal with"
anything.

Coincidentally, I am one of only a few people to bootstrap a modern GHC
on riscv/musl:

  https://wiki.gentoo.org/wiki/User:Mjo/GHC_binary_packages

Knowing the amount of work involved, I can promise that if Git switched
to Haskell today, it would be our users who would have to deal with...
not having Git any more.

I agree completely when it comes to the benefits of static typing and
memory safety. (I've been writing Haskell for 15 years, after all.) But
for the time being, all of the cures are worse than the disease.

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Sergey Fedorov]

> but I'd like to hear what OSes and Architectures you use personally and professionally and why adding Rust would be a bad idea.

I am the maintainer of ports for Darwin on PowerPC systems (few past years in MacPorts and now in https://github.com/macos-powerpc/powerpc-ports fork) and contributor to GCC (gfortran). I have added the whole of current R ecosystem into MacPorts and a decent support for modern Fortran via FPM.

Those systems are still actively used, and thanks to GCC upstream support of powerpc-apple-darwin I have been able to keep our ports pretty much on par (occasionally ahead of) what modern macOS has at the moment. A lot of work has been done in past two-three years, including fixing/restoring support for ppc for several major langs/compilers (gfortran, MLton, SBCL, Ruby, OCaml, Idris2 etc.), build systems etc.

Git is essential for the version control, but also for the build systems of MacPorts and CMake. Since my powerpc ports rely on MacPorts infrastructure (there are 40k+ ports), I need a working Git for my workflow.

To be clear, I do not object to adding Rust optionally (as I would not against adding optional modules for any language), but making it mandatory, while Rust is still broken on a few, admittedly edge case, systems, hurts the open-source.

I agree with John Paul Adrian that once gccrs becomes properly usable, or otherwise gcc codegen in Rust acquires support for currently unsupported platforms, things will change.

P. S. I have contributed to mrustc, so it is not ideological. Though I do think that ability to bootstrap from source is strictly required for a compiler to be safe, and at the moment bootstrapping of Rust may not yet work for all supported platforms (at least it is not well-tested).

References:
https://github.com/rust-lang/rfcs/issues/1312
https://github.com/thepowersgang/mrustc/issues/300

Regards,
Sergey Fedorov
macos-powerpc.org

RE: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[rsbecker]

On September 20, 2025 4:30 Am, Sergey Fedorov wrote:
>> but I'd like to hear what OSes and Architectures you use personally and
>professionally and why adding Rust would be a bad idea.
>
>I am the maintainer of ports for Darwin on PowerPC systems (few past years
in
>MacPorts and now in https://github.com/macos-powerpc/powerpc-ports fork)
>and contributor to GCC (gfortran). I have added the whole of current R
ecosystem
>into MacPorts and a decent support for modern Fortran via FPM.
>
>Those systems are still actively used, and thanks to GCC upstream support
of
>powerpc-apple-darwin I have been able to keep our ports pretty much on par
>(occasionally ahead of) what modern macOS has at the moment. A lot of work
has
>been done in past two-three years, including fixing/restoring support for
ppc for
>several major langs/compilers (gfortran, MLton, SBCL, Ruby, OCaml, Idris2
etc.),
>build systems etc.
>
>Git is essential for the version control, but also for the build systems of
MacPorts
>and CMake. Since my powerpc ports rely on MacPorts infrastructure (there
are
>40k+ ports), I need a working Git for my workflow.
>
>To be clear, I do not object to adding Rust optionally (as I would not
against adding
>optional modules for any language), but making it mandatory, while Rust is
still
>broken on a few, admittedly edge case, systems, hurts the open-source.
>
>I agree with John Paul Adrian that once gccrs becomes properly usable, or
otherwise
>gcc codegen in Rust acquires support for currently unsupported platforms,
things
>will change.
>
>P. S. I have contributed to mrustc, so it is not ideological. Though I do
think that
>ability to bootstrap from source is strictly required for a compiler to be
safe, and at
>the moment bootstrapping of Rust may not yet work for all supported
platforms (at
>least it is not well-tested).
>
>References:
>https://github.com/rust-lang/rfcs/issues/1312
>https://github.com/thepowersgang/mrustc/issues/300

To clarify, gcc is not available on all platforms. The overlap where gcc is
supported
and Rust is support is likely high, but more, where gcc is not supported
then it is
highly unlikely that Rust is supported. mrustc is a difficult more that
requires gcc
even if that is not clearly stated - it does not build with c17, for
example. This
double requirement is making the probability of being able to continue to
support
git even less for me on NonStop. My team is working hard to push Rust
availability
and we realize that gccrs is an easier path, but those two are currently
outside
of our control because of complexities in the loader on NonStop.

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Ezekiel Newren]

On Sat, Sep 20, 2025 at 12:39 PM <rsbecker@nexbridge.com> wrote:
> To clarify, gcc is not available on all platforms. The overlap where gcc is
> supported and Rust is support is likely high, but more, where gcc is not
> supported then it is highly unlikely that Rust is supported. mrustc is a
> difficult more that requires gcc even if that is not clearly stated - it
> does not build with c17, for example. This double requirement is making the
> probability of being able to continue to support git even less for me on
> NonStop. My team is working hard to push Rust availability and we realize
> that gccrs is an easier path, but those two are currently outside of our
> control because of complexities in the loader on NonStop.

Is there a C compiler that works on NonStop and Linux? I ask because
I'm wondering if code from gccrs could help with augmenting that
compiler. From what I understand gccrs is written in C++17, but Rust's
native approach uses mrustc to bootstrap, and then the rest of the
Rust compiler is written in Rust. I don't have $500,000 to spare for
testing on real NonStop hardware, but if there was a C compiler that
worked on NonStop and Linux then there'd at least be the possibility
of people trying to make Rust work with it.

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Sam James]

Ezekiel Newren <ezekielnewren@gmail.com> writes:

> On Sat, Sep 20, 2025 at 12:39 PM <rsbecker@nexbridge.com> wrote:
>> To clarify, gcc is not available on all platforms. The overlap where gcc is
>> supported and Rust is support is likely high, but more, where gcc is not
>> supported then it is highly unlikely that Rust is supported. mrustc is a
>> difficult more that requires gcc even if that is not clearly stated - it
>> does not build with c17, for example. This double requirement is making the
>> probability of being able to continue to support git even less for me on
>> NonStop. My team is working hard to push Rust availability and we realize
>> that gccrs is an easier path, but those two are currently outside of our
>> control because of complexities in the loader on NonStop.
>
> Is there a C compiler that works on NonStop and Linux? I ask because
> I'm wondering if code from gccrs could help with augmenting that
> compiler. From what I understand gccrs is written in C++17, but Rust's
> native approach uses mrustc to bootstrap, and then the rest of the
> Rust compiler is written in Rust. I don't have $500,000 to spare for
> testing on real NonStop hardware, but if there was a C compiler that
> worked on NonStop and Linux then there'd at least be the possibility
> of people trying to make Rust work with it.

[Just some small technical notes, it doesn't need a reply.]

GCC defaults to C++17 but is written in C++14 (recently changed from
C++11). I think the gccrs people may have talked about whether they can
use C++17 to make some things easier (I suspect if they requested that,
it would be approved, at least I'd support it and argue in favour).

mrustc isn't part of any official Rust bootstrap path, Rust upstream
just use binaries. mrustc currently needs GCC for some trivial reasons
(like hardcoding some workarounds for bugs w/ GCC-specific flags). I
suspect it wouldn't be too hard to get it working with Clang. I don't
know how many extensions it relies on in general that may be common but
not in the standard.

But mrustc is written in C++, not C -- AFAIK NonStop has no C++ compiler.

RE: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[rsbecker]

On September 20, 2025 3:01 PM, Ezekiel Newren wrote:
>On Sat, Sep 20, 2025 at 12:39 PM <rsbecker@nexbridge.com> wrote:
>> To clarify, gcc is not available on all platforms. The overlap where
>> gcc is supported and Rust is support is likely high, but more, where
>> gcc is not supported then it is highly unlikely that Rust is
>> supported. mrustc is a difficult more that requires gcc even if that
>> is not clearly stated - it does not build with c17, for example. This
>> double requirement is making the probability of being able to continue
>> to support git even less for me on NonStop. My team is working hard to
>> push Rust availability and we realize that gccrs is an easier path,
>> but those two are currently outside of our control because of complexities in the
>loader on NonStop.
>
>Is there a C compiler that works on NonStop and Linux? I ask because I'm
>wondering if code from gccrs could help with augmenting that compiler. From what
>I understand gccrs is written in C++17, but Rust's native approach uses mrustc to
>bootstrap, and then the rest of the Rust compiler is written in Rust. I don't have
>$500,000 to spare for testing on real NonStop hardware, but if there was a C
>compiler that worked on NonStop and Linux then there'd at least be the possibility
>of people trying to make Rust work with it.

All I have is a C++17 compiler. gcc -std=c17 might work for compatibility on Linux but none
of the gcc extensions work.

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Ezekiel Newren]

On Sat, Sep 20, 2025 at 5:18 PM <rsbecker@nexbridge.com> wrote:
> All I have is a C++17 compiler. gcc -std=c17 might work for compatibility on Linux but none
> of the gcc extensions work.

What I meant was: Is there a compiler that can be compiled to both
NonStop and Linux. What is the name of the C++17 compiler that you use
on NonStop? Is there a Linux or Windows cross compiler that can target
NonStop?

RE: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[rsbecker]

On September 20, 2025 7:48 PM, Ezekiel Newren wrote:
>On Sat, Sep 20, 2025 at 5:18 PM <rsbecker@nexbridge.com> wrote:
>> All I have is a C++17 compiler. gcc -std=c17 might work for
>> compatibility on Linux but none of the gcc extensions work.
>
>What I meant was: Is there a compiler that can be compiled to both NonStop and
>Linux. What is the name of the C++17 compiler that you use on NonStop? Is there a
>Linux or Windows cross compiler that can target NonStop?

We have c99, c11, c17. The only Windows cross compiler is c99, but that requires
a license from HPE that I cannot provide. There are not non-commercial compilers
available that can be used to cross compile. Also, standard configure processing
does not work on Windows for NonStop.

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Ezekiel Newren]

On Sat, Sep 20, 2025 at 7:15 PM <rsbecker@nexbridge.com> wrote:
> >What I meant was: Is there a compiler that can be compiled to both NonStop and
> >Linux. What is the name of the C++17 compiler that you use on NonStop? Is there a
> >Linux or Windows cross compiler that can target NonStop?
>
> We have c99, c11, c17. The only Windows cross compiler is c99, but that requires
> a license from HPE that I cannot provide. There are not non-commercial compilers
> available that can be used to cross compile. Also, standard configure processing
> does not work on Windows for NonStop.

If C/C++ can be cross compiled from Windows to a NonStop target, then
why does Git need to run on NonStop itself? Why couldn't you use Git
on Windows and then copy the compiled executables to your NonStop
targets?

RE: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[rsbecker]

On September 20, 2025 9:24 PM, Ezekiel Newren wrote:
>On Sat, Sep 20, 2025 at 7:15 PM <rsbecker@nexbridge.com> wrote:
>> >What I meant was: Is there a compiler that can be compiled to both
>> >NonStop and Linux. What is the name of the C++17 compiler that you
>> >use on NonStop? Is there a Linux or Windows cross compiler that can target
>NonStop?
>>
>> We have c99, c11, c17. The only Windows cross compiler is c99, but
>> that requires a license from HPE that I cannot provide. There are not
>> non-commercial compilers available that can be used to cross compile.
>> Also, standard configure processing does not work on Windows for NonStop.
>
>If C/C++ can be cross compiled from Windows to a NonStop target, then why does
>Git need to run on NonStop itself? Why couldn't you use Git on Windows and then
>copy the compiled executables to your NonStop targets?

This is a much longer discussion. Windows is simply not a trusted platform. NonStop
is. Building on NonStop provides a virus free/malware free container that passes audit
requirements for financial transactions that cannot be demonstrated on Windows. I
have customers who refuse all attempts at building anything on NonStop.

In addition, production control cannot be done from windows. There is more to
life than Dev in DevSecOps, which is the only thing Windows builds gives you. Unless
git runs on NonStop, production artifacts (scripts, configuration, deployed objects)
cannot be audited and controlled.

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Ezekiel Newren]

On Sat, Sep 20, 2025 at 9:18 PM <rsbecker@nexbridge.com> wrote:
> This is a much longer discussion. Windows is simply not a trusted platform. NonStop
> is. Building on NonStop provides a virus free/malware free container that passes audit
> requirements for financial transactions that cannot be demonstrated on Windows. I
> have customers who refuse all attempts at building anything on NonStop.
>
> In addition, production control cannot be done from windows. There is more to
> life than Dev in DevSecOps, which is the only thing Windows builds gives you. Unless
> git runs on NonStop, production artifacts (scripts, configuration, deployed objects)
> cannot be audited and controlled.

Can linux cross compile to NonStop? If so, would Linux be able to pass
audit requirements?

It seems like this might be a first mover problem. HPE NonStop doesn't
want to support Rust because no one is demanding it from them, but
engineers don't ask for it (or rather, aren't heard) because HPE
NonStop refuses to support it. I'll bet NonStop doesn't support Git
because why would they pay for it when you're doing it for them for
free. and now people are talking about adding Rust to Git which means
Git won't work on NonStop and then something breaks and management
screams at you to "fix it", but you can't because their policy forbade
you from using the tools that would allow you to "fix it".

Am I telling the story right?

RE: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[rsbecker]

On September 21, 2025 12:49 PM, Ezekiel Newren wrote:
>On Sat, Sep 20, 2025 at 9:18 PM <rsbecker@nexbridge.com> wrote:
>> This is a much longer discussion. Windows is simply not a trusted
>> platform. NonStop is. Building on NonStop provides a virus
>> free/malware free container that passes audit requirements for
>> financial transactions that cannot be demonstrated on Windows. I have
>customers who refuse all attempts at building anything on NonStop.
>>
>> In addition, production control cannot be done from windows. There is
>> more to life than Dev in DevSecOps, which is the only thing Windows
>> builds gives you. Unless git runs on NonStop, production artifacts
>> (scripts, configuration, deployed objects) cannot be audited and controlled.
>
>Can linux cross compile to NonStop? If so, would Linux be able to pass audit
>requirements?
>
>It seems like this might be a first mover problem. HPE NonStop doesn't want to
>support Rust because no one is demanding it from them, but engineers don't ask
>for it (or rather, aren't heard) because HPE NonStop refuses to support it. I'll bet
>NonStop doesn't support Git because why would they pay for it when you're doing
>it for them for free. and now people are talking about adding Rust to Git which
>means Git won't work on NonStop and then something breaks and management
>screams at you to "fix it", but you can't because their policy forbade you from using
>the tools that would allow you to "fix it".
>
>Am I telling the story right?

Not really no. There is momentum for Rust on NonStop. It just takes time to get
budget for the effort. After getting budget, it takes time for the port. I am likely to
have some involvement in that, one way or another. NonStop does support git,
mostly through my ongoing efforts and they do use it extensively. This really is a
crucial application and the NonStop team does understand the implications. The
problem is that everything takes time, more than git is allowing in this case. I cannot
disclose more than that.

Yes, people are screaming at me to fix it, which is not easy. The policy is not the
Problem, but the technical limitations are. It is not a surprise, because I was involved
In the POSIX effort when it was first introduced on NonStop, not that many "in the know"
Listened to my concerns, which are now having significant consequences.

I am still working all possible angles to see that git stays relevant, and appreciate
any and all help from any source.

Randall "The Reluctant Prophet" Becker

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Ezekiel Newren]

On Sun, Sep 21, 2025 at 5:07 PM <rsbecker@nexbridge.com> wrote:
> Not really no. There is momentum for Rust on NonStop. It just takes time to get
> budget for the effort. After getting budget, it takes time for the port. I am likely to
> have some involvement in that, one way or another. NonStop does support git,
> mostly through my ongoing efforts and they do use it extensively. This really is a
> crucial application and the NonStop team does understand the implications. The
> problem is that everything takes time, more than git is allowing in this case. I cannot
> disclose more than that.

Ah, thank you for correcting me.

> Yes, people are screaming at me to fix it, which is not easy. The policy is not the
> Problem, but the technical limitations are. It is not a surprise, because I was involved
> In the POSIX effort when it was first introduced on NonStop, not that many "in the know"
> Listened to my concerns, which are now having significant consequences.

I think you've mentioned threading as a major technical hurdle for
Rust and GCC somewhere else on the mailing list (correct me if I'm
wrong). That's why I've worked very hard on single threaded only
translations. Also, I've been targeting Rust version 1.63.0 because
that's what debian requires and so my local Rust development is locked
to that version. I've managed to translate a huge amount of xdiff to
Rust using no Cargo dependencies. I figure if I keep my Rust adoption
effort as bare bones as possible that'll make it easier for NonStop to
catch up to Git's Rust bare minimum requirement. I have been talking
about adding cbindgen which pulls in like 40+ dependencies, but that's
a different case because its only purpose is to generate C header
files from parsed Rust files. I can write my Rust in a way that
cbindgen can be disabled and the generated header files can be checked
into Git or acquired somewhere else.

I have 2 questions for you.
What parts of Rust do you think will be easy to port?
What parts of Rust do you think will be difficult to port?

RE: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[rsbecker]

On September 21, 2025 7:42 PM, Ezekiel Newren wrote:
>On Sun, Sep 21, 2025 at 5:07 PM <rsbecker@nexbridge.com> wrote:
>> Not really no. There is momentum for Rust on NonStop. It just takes
>> time to get budget for the effort. After getting budget, it takes time
>> for the port. I am likely to have some involvement in that, one way or
>> another. NonStop does support git, mostly through my ongoing efforts
>> and they do use it extensively. This really is a crucial application
>> and the NonStop team does understand the implications. The problem is
>> that everything takes time, more than git is allowing in this case. I cannot disclose
>more than that.
>
>Ah, thank you for correcting me.
>
>> Yes, people are screaming at me to fix it, which is not easy. The
>> policy is not the Problem, but the technical limitations are. It is
>> not a surprise, because I was involved In the POSIX effort when it was first
>introduced on NonStop, not that many "in the know"
>> Listened to my concerns, which are now having significant consequences.
>
>I think you've mentioned threading as a major technical hurdle for Rust and GCC
>somewhere else on the mailing list (correct me if I'm wrong). That's why I've worked
>very hard on single threaded only translations. Also, I've been targeting Rust version
>1.63.0 because that's what debian requires and so my local Rust development is
>locked to that version. I've managed to translate a huge amount of xdiff to Rust
>using no Cargo dependencies. I figure if I keep my Rust adoption effort as bare
>bones as possible that'll make it easier for NonStop to catch up to Git's Rust bare
>minimum requirement. I have been talking about adding cbindgen which pulls in like
>40+ dependencies, but that's a different case because its only purpose is to generate
>C header files from parsed Rust files. I can write my Rust in a way that cbindgen can
>be disabled and the generated header files can be checked into Git or acquired
>somewhere else.
>
>I have 2 questions for you.
>What parts of Rust do you think will be easy to port?
>What parts of Rust do you think will be difficult to port?

I will ask the team member who are doing this port for their opinion.

Easy: NonStop is POSIX and has C17, so anything compatible with that should
not be difficult.
Hard: Anything that depends on assumptions that gcc works 100% on the
platform are hard and have to be worked around, so porting mrustc is considered
hard on that basis. Our first attempt at porting that did not go well as we have to
reconstruct the build options, at the very least, from scratch, while not strictly
difficult, it is always time consuming to figure out the intention.