[PATCH v2 0/4] Enable Rust by default

[PATCH v2 0/4] Enable Rust by default

[brian m. carlson]

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

[PATCH v2 1/4] docs: update version with default Rust support

[brian m. carlson]

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

diff --git a/Documentation/BreakingChanges.adoc b/Documentation/BreakingChanges.adoc
index f814450d2f..510ed98b65 100644
--- a/Documentation/BreakingChanges.adoc
+++ b/Documentation/BreakingChanges.adoc
@@ -190,7 +190,7 @@ 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.
+2. In Git 2.54, 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.

[PATCH v2 2/4] ci: install cargo on Alpine

[brian m. carlson]

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

diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh
index c55441d9df..10c3530d1a 100755
--- a/ci/install-dependencies.sh
+++ b/ci/install-dependencies.sh
@@ -29,7 +29,7 @@ alpine-*)
 	apk add --update shadow sudo meson ninja-build gcc libc-dev curl-dev openssl-dev expat-dev gettext \
 		zlib-ng-dev pcre2-dev python3 musl-libintl perl-utils ncurses \
 		apache2 apache2-http2 apache2-proxy apache2-ssl apache2-webdav apr-util-dbd_sqlite3 \
-		bash cvs gnupg perl-cgi perl-dbd-sqlite perl-io-tty >/dev/null
+		bash cvs gnupg perl-cgi perl-dbd-sqlite perl-io-tty cargo >/dev/null
 	;;
 fedora-*|almalinux-*)
 	case "$jobname" in

[PATCH v2 3/4] Linux: link against libdl

[brian m. carlson]

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(+)

diff --git a/config.mak.uname b/config.mak.uname
index ccb3f71881..7aab56c590 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -63,6 +63,7 @@ ifeq ($(uname_S),Linux)
 	PROCFS_EXECUTABLE_PATH = /proc/self/exe
 	HAVE_PLATFORM_PROCINFO = YesPlease
 	COMPAT_OBJS += compat/linux/procinfo.o
+	EXTLIBS += -ldl
 	# centos7/rhel7 provides gcc 4.8.5 and zlib 1.2.7.
         ifneq ($(findstring .el7.,$(uname_R)),)
 		BASIC_CFLAGS += -std=c99

[PATCH v2 4/4] Enable Rust by default

[brian m. carlson]

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

diff --git a/Makefile b/Makefile
index 5d22394c2e..945adb9aa5 100644
--- a/Makefile
+++ b/Makefile
@@ -498,9 +498,9 @@ include shared.mak
 #
 # == 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.
+# Define NO_RUST if you want to disable features and subsystems written in Rust
+# from being compiled 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.
 #
@@ -1351,7 +1351,7 @@ LIB_OBJS += urlmatch.o
 LIB_OBJS += usage.o
 LIB_OBJS += userdiff.o
 LIB_OBJS += utf8.o
-ifndef WITH_RUST
+ifdef NO_RUST
 LIB_OBJS += varint.o
 endif
 LIB_OBJS += version.o
@@ -1590,7 +1590,7 @@ endif
 ALL_CFLAGS = $(DEVELOPER_CFLAGS) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_APPEND)
 ALL_LDFLAGS = $(LDFLAGS) $(LDFLAGS_APPEND)
 
-ifdef WITH_RUST
+ifndef NO_RUST
 BASIC_CFLAGS += -DWITH_RUST
 GITLIBS += $(RUST_LIB)
 ifeq ($(uname_S),Windows)
diff --git a/ci/lib.sh b/ci/lib.sh
index 42a2b6a318..1cfc8c6efc 100755
--- a/ci/lib.sh
+++ b/ci/lib.sh
@@ -372,6 +372,9 @@ linux-asan-ubsan)
 osx-meson)
 	MESONFLAGS="$MESONFLAGS -Dcredential_helpers=osxkeychain"
 	;;
+windows-*)
+	export NO_RUST=UnfortunatelyYes
+	;;
 esac
 
 MAKEFLAGS="$MAKEFLAGS CC=${CC:-cc}"
diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index 28cfe730ee..e2d783d90b 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -8,11 +8,12 @@
 export TEST_CONTRIB_TOO=yes
 
 case "$jobname" in
+linux-musl-meson)
+	MESONFLAGS="$MESONFLAGS -Drust=disabled"
+	;;
 fedora-breaking-changes-musl|linux-breaking-changes)
 	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
@@ -30,6 +31,7 @@ linux-TEST-vars)
 	export GIT_TEST_PACK_USE_BITMAP_BOUNDARY_TRAVERSAL=1
 	;;
 linux-clang)
+	export NO_RUST=UnfortunatelyYes
 	export GIT_TEST_DEFAULT_HASH=sha1
 	;;
 linux-sha256)
diff --git a/meson.build b/meson.build
index 8309942d18..deff129cf6 100644
--- a/meson.build
+++ b/meson.build
@@ -1745,8 +1745,7 @@ 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())
+rust_option = get_option('rust')
 if rust_option.allowed()
   subdir('src')
   libgit_c_args += '-DWITH_RUST'
diff --git a/meson_options.txt b/meson_options.txt
index 659cbb218f..80a8025f20 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -77,7 +77,7 @@ 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',
+option('rust', type: 'feature', value: 'enabled',
   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/meson.build b/src/meson.build
index 45739957b4..41a4b231e6 100644
--- a/src/meson.build
+++ b/src/meson.build
@@ -29,6 +29,7 @@ libgit_rs = custom_target('git_rs',
 )
 libgit_dependencies += declare_dependency(link_with: libgit_rs)
 
+cargo = find_program('cargo', dirs: program_path, native: true, required: get_option('rust'))
 if get_option('tests')
   test('rust', cargo,
     args: [

Re: [PATCH v2 0/4] Enable Rust by default

[Derrick Stolee]

On 4/9/2026 6:44 PM, brian m. carlson wrote:
> 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.

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

Re*: [PATCH v2 0/4] Enable Rust by default

[Junio C Hamano]

Derrick Stolee <stolee@gmail.com> writes:

> On 4/9/2026 6:44 PM, brian m. carlson wrote:
>> 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.
>
> 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.

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

diff --git c/Documentation/BreakingChanges.adoc w/Documentation/BreakingChanges.adoc
index f814450d2f..af59c43f42 100644
--- c/Documentation/BreakingChanges.adoc
+++ w/Documentation/BreakingChanges.adoc
@@ -190,7 +190,7 @@ 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.
+2. In Git 2.55, 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.

Re: Re*: [PATCH v2 0/4] Enable Rust by default

[Derrick Stolee]

On 4/10/2026 10:52 AM, Junio C Hamano wrote:
> 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(-)
> 
> diff --git c/Documentation/BreakingChanges.adoc w/Documentation/BreakingChanges.adoc
> index f814450d2f..af59c43f42 100644
> --- c/Documentation/BreakingChanges.adoc
> +++ w/Documentation/BreakingChanges.adoc
> @@ -190,7 +190,7 @@ 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.
> +2. In Git 2.55, 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.

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

Thanks,
-Stolee

Re: [PATCH v2 0/4] Enable Rust by default

[Derrick Stolee]

On 4/9/2026 6:44 PM, brian m. carlson wrote:
> 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.
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

Re: [PATCH v2 0/4] Enable Rust by default

[brian m. carlson]

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

On 2026-04-10 at 13:02:13, Derrick Stolee 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.

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 (they/them)
Toronto, Ontario, CA

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

Re: [PATCH v2 0/4] Enable Rust by default

[Junio C Hamano]

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

> On 2026-04-10 at 13:02:13, Derrick Stolee 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.
>
> 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.

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.

Re: [PATCH v2 0/4] Enable Rust by default

[Junio C Hamano]

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

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

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.

Re: [PATCH v2 0/4] Enable Rust by default

[brian m. carlson]

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

On 2026-04-10 at 21:13:42, Junio C Hamano wrote:
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> 
> > 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.)
> 
> 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 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.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

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

Re: [PATCH v2 0/4] Enable Rust by default

[brian m. carlson]

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

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

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.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

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