We missed the cut-off for Rust by default in 2.53, but we still can enable it by default for 2.54, so update our breaking changes document accordingly.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
---
 Documentation/BreakingChanges.adoc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Older versions of Rust on Linux, such as that used in Debian 11 in our CI, require linking against libdl. Were we linking with Cargo, this would be included automatically, but since we're not, explicitly set it in the system-specific config.

This library is part of libc, so linking against it if it happens to be unnecessary will add no dependencies to the resulting binary. In addition, it is provided by both glibc and musl, so it should be portable to almost all Linux systems.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
---
 config.mak.uname | 1 +
 1 file changed, 1 insertion(+)

Our breaking changes document said that we would enable Rust support by default in Git 2.53, while still leaving the ability for it to be disabled. Unfortunately, we forgot to do that and my time machine is broken right now, so this series sets it up for Git 2.54.

CI remains passing on GitHub Actions in v2.

Changes since v1:

* Move Cargo declaration to src/meson.rs.
* Add a Meson build without Rust.
* Remove `-Drust=enabled` for Meson, which is no longer needed.

brian m. carlson (4):
  docs: update version with default Rust support
  ci: install cargo on Alpine
  Linux: link against libdl
  Enable Rust by default

 Documentation/BreakingChanges.adoc |  2 +-
 Makefile                           | 10 +++++-----
 ci/install-dependencies.sh         |  2 +-
 ci/lib.sh                          |  3 +++
 ci/run-build-and-tests.sh          |  6 ++++--
 config.mak.uname                   |  1 +
 meson.build                        |  3 +--
 meson_options.txt                  |  2 +-
 src/meson.build                    |  1 +
 9 files changed, 18 insertions(+), 12 deletions(-)

Our breaking changes document says that we'll enable Rust by default in Git 2.54. Adjust the Makefile to switch the option from WITH_RUST to NO_RUST to enable it by default and update the help text accordingly. Similarly, for Meson, enable the option by default and do not automatically disable it if Cargo is missing, since the goal is to help users find where they are likely to have problems in the future.

Update our CI tests to swap out the single Linux job with Rust to a single job without, both for Makefile and Meson. Similarly, update the Windows Makefile job to not use Rust, while the Meson job (which does not build with ci/lib.sh) will default to having it enabled.

Move the check for Cargo in the Meson build because it is no longer needed in the main script.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
---
 Makefile                  | 10 +++++-----
 ci/lib.sh                 |  3 +++
 ci/run-build-and-tests.sh |  6 ++++--
 meson.build               |  3 +--
 meson_options.txt         |  2 +-
 src/meson.build           |  1 +
 6 files changed, 15 insertions(+), 10 deletions(-)

We'll make Rust the default in a future commit, so be sure to install Cargo (which will also install Rust) to prepare for that case.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
---
 ci/install-dependencies.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

On 4/9/2026 6:44 PM, brian m. carlson wrote:

I'm glad you're remembering to help us follow through on this promise.

However, I'm worried that we shouldn't do this change during the rc window for 2.54.0. Perhaps we could get a small patch that updates the docs to say "we really mean 2.55.0" that lands in the 2.54.0 release, and then we merge the requirements for the build in the first batch after the release.

This would give us a full release cycle to simmer with the requirement instead of slipping it in for the last rc.

Thanks, -Stolee

Derrick Stolee <stolee@gmail.com> writes:

Yes, let's do that.

I thought that leaving a bit of wiggle room like this:

  2. In Git 2.55 (or later, if the codebase and the world is not yet ready by then),
     both build systems will default-enable support for Rust.

might not be a bad idea, but during the -rc period, simpler the better.

----- >8 -----
Subject: rust: we are way beyond 2.53

Earlier we timelined that we'd tune our build procedures to build with Rust by default in Git 2.53, but we are already in prerelease freeze for 2.54 now. Update the BreakingChanges document to delay it until Git 2.55 (slated for the end of June 2026).

Noticed-by: brian m. carlson <sandals@crustytoothpaste.net>
Helped-by: Derrick Stolee <stolee@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/BreakingChanges.adoc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

On 4/10/2026 10:52 AM, Junio C Hamano wrote:

This patch LGTM and safe to add within the release window.

Thanks, -Stolee

On 4/9/2026 6:44 PM, brian m. carlson wrote:

The discussion about how to handle the 2.54.0/2.55.0 release details seems to have concluded, so I went to review the series more carefully.

If we take Junio's patch instead of this series's patch 1, then patches 2-4 look good.

I had some initial confusion about patch 4's references to Rust being "optional" and it helps to know that there is a mechanism to _opt out_ of Rust builds. So the real conclusion is that we're moving from an opt-in system to an opt-out system. This is a nice way to make progress relatively safely.

Thanks, -Stolee

On 2026-04-10 at 13:02:13, Derrick Stolee wrote:

This was actually sent out just before rc0, but Patrick requested some changes in v1. (I forgot to thread it to the previous version, unfortunately.) I would like to have it in 2.54 if we can because I suspect 2.55 will be the last release before 3.0, so that doesn't give much time for people to update and adjust if there are problems.

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

Huh? I actually was hoping that we would tag 2.95 when everybody feels that 3.0 is on the horizon, and if we are lucky jump directly to 3.0 (while leaving us room to issue 4 extra 2.XX releases if the timeline turns out to be too aggressve after we got such an agreement and 2.95 turns out to be premature).

You are saying that we'd skip 2.56 and jump directly to 3.0 at the end of September? I do not recall seeing any discussion, let alone a concensus (rough or not) with such a short timeframe.

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

Proudly saying "It was sent before rc0", as if that gave community plenty of time to adjust, is not something I was expecting to hear.

"This is expected to be a big impact change, so I am sending it before -rc0 of this cycle, so that it can be in the first batch that graduates to 'master' for the next cycle" would have been a lot more understandable, though.

This, and other small things like writev() topic, reminds me what I've been wondering for some time about our development process.

We have been operating this way:

 - There are 6 to 8 weeks of period, during which at any time
   anybody can send in any random changes, and as soon as a rough
   consensus is reached that it is a good idea, a topic is merged to
   'next' and after spending a week there merged down to 'master'.

 - There is a "cut-off" time at -rc1.  After that we go into
   "regression fix only" prerelease freeze.  We typically do an -rc2
   and the final after that, and this process typically takes 2.5
   weeks.

This forces topics that are apparently (even though in retrospect it only was superficially) good topic that came late to spend too little time to make the cut-off time.

I wonder if we should do this a bit differently.

We may want to have a mechanism to sift topics (as they come in) into "architecturally important high impact" changes and the rest by community concensus. We require that the former be kept in 'next' until the final release, unless they mature before '-rc0'.

Essentially, '-rc0'would become the new cut-off time for these high impact topics, while '-rc1' will be the cut-off for the rest.

And we move '-rc0' way before '-rc1'. Perhaps to week 3 or 4 of the cycle, from the current week 6 to 8. Currently "rc0" is no more than "we happen to have accumulated these random topics during this cycle and this is a preview", which is boring, but we can reframe it as "there may be more smaller topics coming, but all architecturally important high impact changes in the upcoming release are in here and no more will be added until the final release." preview. If you are not in the mainstream (you are on a minority platform, or your workflow is pecurilar, or you depend on some third-party tools on top of Git, etc., etc.), this is the version to test and report breakages in, to make sure that the next release won't hurt you.

Would that improve the process and allow us to experiment with larger changes early in the cycle, with plenty time to correct course, allowing us scramble less at the last minute during the prerelease freeze period?

I dunno.

On 2026-04-10 at 21:13:42, Junio C Hamano wrote:

This change was announced on the list and in the documentation, so its appearance should not be a surprise.

I didn't realize that I was sending it directly before -rc0 because I'm not usually very attuned to the timeframe in between releases, to be honest. I usually send patches as my schedule allows and I try to fix anything I've broken relatively quickly and even faster in the -rc period, and I generally let you decide how and when to merge them.

In this particular case, I merely remembered that it was something we committed to because I actually was looking at the BreakingChanges document for other reasons, so I sent a patch as soon as possible. That just happened to be right before -rc0. Had I remembered earlier, I would of course have sent the patch earlier. It appears, however, that we all had a memory lapse in this case and I do apologize for my part in that.

I don't have a strong opinion here and if you prefer, we can defer to 2.55. I agree that would be less risky at this point in the release cycle and, of course, you are the maintainer.

I have been operating under the assumption that Git 3.0 is destined for September 2026 based on the discussions we had at the September 2024 Contributors' Summit in Berlin where we said 1–2 years, as well as other discussions on the list, and that is the message I have been communicating to other people and projects[0]. I am fully aware that that date might slip due to various reasons[1], but I do very much want to get as many things set up as possible so people can test and there will be fewer surprises, which was of course the reason for sending in this series. I imagine, for instance, that Debian might ship a WITH_BREAKING_CHANGES version in experimental for testing to find all the exciting things that will break (of which I am aware of quite a few). (I will suggest that to them shortly.)

[0] This is true in both my personal and professional roles. [1] Although I am unable to be more specific, let us just say that I am endeavouring to do everything I can such that the date does not slip for any reasons within my control.

What I recall having seen suggested on the list is that we were thinking one of the 2.5x releases would be the last release before 3.0 (I think maybe somewhere in the Rust discussion), but I don't think we actually discussed it in any detail. We did definitely discuss the 1–2 year timeframe at the September 2024 Berlin Contributor Summit, though, which has been my guide for getting things ready for Git 3.0.

I think your proposal here sounds more sensible, though, and possibly nicer for downstreams since 2.95 reads more like "getting ready for 3.0" than 2.55.

Anyway, we should probably start a separate thread to discuss plans for the 3.0 release and what we think is missing for that. That would be more discoverable than hiding it here.