# [RFC PATCH 0/4] doc: move BreakingChanges to a manpage 15 messages from 2026-09-28 to 2026-10-04. Participants: kristofferhaugsbakk@fastmail.com, Patrick Steinhardt, Kristoffer Haugsbakk, Junio C Hamano. Thread: https://gitlist.dev/t/66404 ## kristofferhaugsbakk@fastmail.com, 2026-09-28 10:41 Subject: [RFC PATCH 0/4] doc: move BreakingChanges to a manpage Message-ID: ``` From: Kristoffer Haugsbakk Topic name: kh/doc-gitbreaking-changes7 Topic summary: Move BreakingChanges document to a manpage for easier visibility. Users are the ones who are impacted by breaking changes. Certainly much more than Git developers who are already plugged in to the development channels that discuss the trajectory of the project. Advertizing the planned breaking changes to all users will help the whole Git community prepare. [1/4] doc: transform breaking changes doc to a manpage [2/4] doc: gitbreaking-changes: replace msg-ids with URLs [3/4] doc: gitbreaking-changes: add note about living document [4/4] doc: git: mention gitbreaking-changes(7) Documentation/BreakingChanges.adoc | 360 +---------------------- Documentation/Makefile | 1 + Documentation/git.adoc | 5 +- Documentation/gitbreaking-changes.adoc | 387 +++++++++++++++++++++++++ Documentation/meson.build | 1 + command-list.txt | 1 + 6 files changed, 395 insertions(+), 360 deletions(-) create mode 100644 Documentation/gitbreaking-changes.adoc base-commit: 0f8e75abebff0877cae681a3d5ff31ac47f54220 -- 2.55.0.793.gc667de3f2c5 ``` ## kristofferhaugsbakk@fastmail.com, 2026-09-28 10:41 Subject: [RFC PATCH 1/4] doc: transform breaking changes doc to a manpage Message-ID: In-Reply-To: ``` From: Kristoffer Haugsbakk The breaking changes document is not a regular Git documentation page. That means that you cannot navigate to the doc with git(1), i.e. with: git help BreakingChanges You instead have to download the Git project source. Or go to git-scm.com.[1] Then you get this disclaimer:[2] This information is specific to the Git project Please note that this information is only relevant to you if you plan on contributing to the Git project itself. It is in no shape or form required reading for regular Git users. But this document is relevant to *all* Git users. Everyone should have as easy access to it as the other doc and guide pages. To that end, let’s move the text to a manpage. But keep the old page, just linking to the new one. (We wouldn’t want to break any readers.) Just do the minimal changes for the new format. Also demote the first section to the second level, i.e. make “Introduction” the same level as “Procedure’. † 1: https://git-scm.com/docs/BreakingChanges.html † 2: Which I first mentioned in 098230f7 (you-still-use-that??: help the user help themselves, 2025-09-17), footnote #1. Signed-off-by: Kristoffer Haugsbakk --- Documentation/BreakingChanges.adoc | 360 +---------------------- Documentation/Makefile | 1 + Documentation/gitbreaking-changes.adoc | 378 +++++++++++++++++++++++++ Documentation/meson.build | 1 + 4 files changed, 381 insertions(+), 359 deletions(-) create mode 100644 Documentation/gitbreaking-changes.adoc diff --git a/Documentation/BreakingChanges.adoc b/Documentation/BreakingChanges.adoc index 73bb939359c..d35850a08e4 100644 --- a/Documentation/BreakingChanges.adoc +++ b/Documentation/BreakingChanges.adoc @@ -1,359 +1 @@ -= Upcoming breaking changes - -The Git project aims to ensure backwards compatibility to the best extent -possible. Minor releases will not break backwards compatibility unless there is -a very strong reason to do so, like for example a security vulnerability. - -Regardless of that, due to the age of the Git project, it is only natural to -accumulate a backlog of backwards-incompatible changes that will eventually be -required to keep the project aligned with a changing world. These changes fall -into several categories: - -* Changes to long established defaults. -* Concepts that have been replaced with a superior design. -* Concepts, commands, configuration or options that have been lacking in major - ways and that cannot be fixed and which will thus be removed without any - replacement. - -Explicitly not included in this list are fixes to minor bugs that may cause a -change in user-visible behavior. - -The Git project irregularly releases breaking versions that deliberately break -backwards compatibility with older versions. This is done to ensure that Git -remains relevant, safe and maintainable going forward. The release cadence of -breaking versions is typically measured in multiple years. We had the following -major breaking releases in the past: - -* Git 1.6.0, released in August 2008. -* Git 2.0, released in May 2014. - -We use . release numbers these days, starting from Git 2.0. For -future releases, our plan is to increment in the release number when we -make the next breaking release. Before Git 2.0, the release numbers were -1.. with the intention to increment for "usual" breaking -releases, reserving the jump to Git 2.0 for really large backward-compatibility -breaking changes. - -The intent of this document is to track upcoming deprecations for future -breaking releases. Furthermore, this document also tracks what will _not_ be -deprecated. This is done such that the outcome of discussions document both -when the discussion favors deprecation, but also when it rejects a deprecation. - -Items should have a clear summary of the reasons why we do or do not want to -make the described change that can be easily understood without having to read -the mailing list discussions. If there are alternatives to the changed feature, -those alternatives should be pointed out to our users. - -All items should be accompanied by references to relevant mailing list threads -where the deprecation was discussed. These references use message-IDs, which -can visited via - - https://lore.kernel.org/git/$message_id/ - -to see the message and its surrounding discussion. Such a reference is there to -make it easier for you to find how the project reached consensus on the -described item back then. - -This is a living document as the environment surrounding the project changes -over time. If circumstances change, an earlier decision to deprecate or change -something may need to be revisited from time to time. So do not take items on -this list to mean "it is settled, do not waste our time bringing it up again". - -== Procedure - -Discussing the desire to make breaking changes, declaring that breaking -changes are made at a certain version boundary, and recording these -decisions in this document, are necessary but not sufficient. -Because such changes are expected to be numerous, and the design and -implementation of them are expected to span over time, they have to -be deployable trivially at such a version boundary, prepared over long -time. - -The breaking changes MUST be guarded with the a compile-time switch, -WITH_BREAKING_CHANGES, to help this process. When built with it, -the resulting Git binary together with its documentation would -behave as if these breaking changes slated for the next big version -boundary are already in effect. We also have a CI job to exercise -the work-in-progress version of Git with these breaking changes. - - -== Git 3.0 - -The following subsections document upcoming breaking changes for Git 3.0. There -is no planned release date for this breaking version yet. - -Proposed changes and removals only include items which are "ready" to be done. -In other words, this is not supposed to be a wishlist of features that should -be changed to or replaced in case the alternative was implemented already. - -=== Changes - -* The default hash function for new repositories will be changed from "sha1" - to "sha256". SHA-1 has been deprecated by NIST in 2011 and is nowadays - recommended against in FIPS 140-2 and similar certifications. Furthermore, - there are practical attacks on SHA-1 that weaken its cryptographic properties: -+ - ** The SHAppening (2015). The first demonstration of a practical attack - against SHA-1 with 2^57 operations. - ** SHAttered (2017). Generation of two valid PDF files with 2^63 operations. - ** Birthday-Near-Collision (2019). This attack allows for chosen prefix - attacks with 2^68 operations. - ** Shambles (2020). This attack allows for chosen prefix attacks with 2^63 - operations. -+ -While we have protections in place against known attacks, it is expected -that more attacks against SHA-1 will be found by future research. Paired -with the ever-growing capability of hardware, it is only a matter of time -before SHA-1 will be considered broken completely. We want to be prepared -and will thus change the default hash algorithm to "sha256" for newly -initialized repositories. -+ -An important requirement for this change is that the ecosystem is ready to -support the "sha256" object format. This includes popular Git libraries, -applications and forges. -+ -There is no plan to deprecate the "sha1" object format at this point in time. -+ -Cf. <2f5de416-04ba-c23d-1e0b-83bb655829a7@zombino.com>, -<20170223155046.e7nxivfwqqoprsqj@LykOS.localdomain>, -. - -* The default storage format for references in newly created repositories will - be changed from "files" to "reftable". The "reftable" format provides - multiple advantages over the "files" format: -+ - ** It is impossible to store two references that only differ in casing on - case-insensitive filesystems with the "files" format. This issue is common - on Windows and macOS platforms. As the "reftable" backend does not use - filesystem paths to encode reference names this problem goes away. - ** Similarly, macOS normalizes path names that contain unicode characters, - which has the consequence that you cannot store two names with unicode - characters that are encoded differently with the "files" backend. Again, - this is not an issue with the "reftable" backend. - ** Deleting references with the "files" backend requires Git to rewrite the - complete "packed-refs" file. In large repositories with many references - this file can easily be dozens of megabytes in size, in extreme cases it - may be gigabytes. The "reftable" backend uses tombstone markers for - deleted references and thus does not have to rewrite all of its data. - ** Repository housekeeping with the "files" backend typically performs - all-into-one repacks of references. This can be quite expensive, and - consequently housekeeping is a tradeoff between the number of loose - references that accumulate and slow down operations that read references, - and compressing those loose references into the "packed-refs" file. The - "reftable" backend uses geometric compaction after every write, which - amortizes costs and ensures that the backend is always in a - well-maintained state. - ** Operations that write multiple references at once are not atomic with the - "files" backend. Consequently, Git may see in-between states when it reads - references while a reference transaction is in the process of being - committed to disk. - ** Writing many references at once is slow with the "files" backend because - every reference is created as a separate file. The "reftable" backend - significantly outperforms the "files" backend by multiple orders of - magnitude. - ** The reftable backend uses a binary format with prefix compression for - reference names. As a result, the format uses less space compared to the - "packed-refs" file. -+ -Users that get immediate benefit from the "reftable" backend could continue to -opt-in to the "reftable" format manually by setting the "init.defaultRefFormat" -config. But defaults matter, and we think that overall users will have a better -experience with less platform-specific quirks when they use the new backend by -default. -+ -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. - -* In new repositories, the default branch name will be `main`. We have been - warning that the default name will change since 675704c74dd (init: - provide useful advice about init.defaultBranch, 2020-12-11). The new name - matches the default branch name used in new repositories by many of the - big Git forges. - -* 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.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. -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. - -* The default value of `safe.bareRepository` will change from `all` to - `explicit`. It is all too easy for an attacker to trick a user into cloning a - repository that contains an embedded bare repository with malicious hooks - configured. If the user enters that subdirectory and runs any Git command, Git - discovers the bare repository and the hooks fire. The user does not even need - to run a Git command explicitly: many shell prompts run `git status` in the - background to display branch and dirty state information, and `git status` in - turn may invoke the fsmonitor hook if so configured, making the user - vulnerable the moment they `cd` into the directory. The `safe.bareRepository` - configuration variable was introduced in 8959555cee (setup_git_directory(): - add an owner check for the top-level directory, 2022-03-02) with a default of - `all` to preserve backwards compatibility. -+ -Changing the default to `explicit` means that Git will refuse to work with bare -repositories that are discovered implicitly by walking up the directory tree. -Bare repositories specified explicitly via the `--git-dir` command-line option -or the `GIT_DIR` environment variable continue to work regardless of this -setting. Repositories that look like a `.git` directory, a worktree, or a -submodule directory are also unaffected. -+ -Users who rely on implicit discovery of bare repositories can restore the -previous behavior by setting `safe.bareRepository=all` in their global or -system configuration. - -=== Removals - -* Support for grafting commits has long been superseded by git-replace(1). - Grafts are inferior to replacement refs: -+ - ** Grafts are a local-only mechanism and cannot be shared across - repositories. - ** Grafts can lead to hard-to-diagnose problems when transferring objects - between repositories. -+ -The grafting mechanism has been marked as outdated since e650d0643b (docs: mark -info/grafts as outdated, 2014-03-05) and will be removed. -+ -Cf. <20140304174806.GA11561@sigill.intra.peff.net>. - -* The git-pack-redundant(1) command can be used to remove redundant pack files. - The subcommand is unusably slow and the reason why nobody reports it as a - performance bug is suspected to be the absence of users. We have nominated - the command for removal and have started to emit a user-visible warning in - c3b58472be (pack-redundant: gauge the usage before proposing its removal, - 2020-08-25) whenever the command is executed. -+ -So far there was a single complaint about somebody still using the command, but -that complaint did not cause us to reverse course. On the contrary, we have -doubled down on the deprecation and starting with 4406522b76 (pack-redundant: -escalate deprecation warning to an error, 2023-03-23), the command dies unless -the user passes the `--i-still-use-this` option. -+ -There have not been any subsequent complaints, so this command will finally be -removed. -+ -Cf. , - , - <20230323204047.GA9290@coredump.intra.peff.net>, - -* Support for storing shorthands for remote URLs in "$GIT_COMMON_DIR/branches/" - and "$GIT_COMMON_DIR/remotes/" has been long superseded by storing remotes in - the repository configuration. -+ -The mechanism has originally been introduced in f170e4b39d ([PATCH] fetch/pull: -short-hand notation for remote repositories., 2005-07-16) and was superseded by -6687f8fea2 ([PATCH] Use .git/remote/origin, not .git/branches/origin., -2005-08-20), where we switched from ".git/branches/" to ".git/remotes/". That -commit already mentions an upcoming deprecation of the ".git/branches/" -directory, and starting with a1d4aa7424 (Add repository-layout document., -2005-09-01) we have also marked this layout as deprecated. Eventually we also -started to migrate away from ".git/remotes/" in favor of config-based remotes, -and we have marked the directory as legacy in 3d3d282146 (Documentation: -Grammar correction, wording fixes and cleanup, 2011-08-23) -+ -As our documentation mentions, these directories are unlikely to be used in -modern repositories and most users aren't even aware of these mechanisms. They -have been deprecated for almost 20 years and 14 years respectively, and we are -not aware of any active users that have complained about this deprecation. -Furthermore, the ".git/branches/" directory is nowadays misleadingly named and -may cause confusion as "branches" are almost exclusively used in the context of -references. -+ -These features will be removed. - -* Support for "--stdin" option in the "name-rev" command was - deprecated (and hidden from the documentation) in the Git 2.40 - timeframe, in preference to its synonym "--annotate-stdin". Git 3.0 - removes the support for "--stdin" altogether. - -* The git-whatchanged(1) command has outlived its usefulness more than - 10 years ago, and takes more keystrokes to type than its rough - equivalent `git log --raw`. We have nominated the command for - removal, have changed the command to refuse to work unless the - `--i-still-use-this` option is given, and asked the users to report - when they do so. -+ -The command will be removed. - -* Support for `core.commentString=auto` has been deprecated and will - be removed in Git 3.0. -+ -cf. - -* Support for `core.preferSymlinkRefs=true` has been deprecated and will be - removed in Git 3.0. Writing symbolic refs as symbolic links will be phased - out in favor of using plain files using the textual representation of - symbolic refs. -+ -Symbolic references were initially always stored as a symbolic link. This was -changed in 9b143c6e15 (Teach update-ref about a symbolic ref stored in a -textfile., 2005-09-25), where a new textual symref format was introduced to -store those symbolic refs in a plain file. In 9f0bb90d16 -(core.prefersymlinkrefs: use symlinks for .git/HEAD, 2006-05-02), the Git -project switched the default to use the textual symrefs in favor of symbolic -links. -+ -The migration away from symbolic links has happened almost 20 years ago by now, -and there is no known reason why one should prefer them nowadays. Furthermore, -symbolic links are not supported on some platforms. -+ -Note that only the writing side for such symbolic links is deprecated. Reading -such symbolic links is still supported for now. - -== Superseded features that will not be deprecated - -Some features have gained newer replacements that aim to improve the design in -certain ways. The fact that there is a replacement does not automatically mean -that the old way of doing things will eventually be removed. This section tracks -those features with newer alternatives. - -* The features git-checkout(1) offers are covered by the pair of commands - git-restore(1) and git-switch(1). Because the use of git-checkout(1) is still - widespread, and it is not expected that this will change anytime soon, all - three commands will stay. -+ -This decision may get revisited in case we ever figure out that there are -almost no users of any of the commands anymore. -+ -Cf. , -, -<112b6568912a6de6672bf5592c3a718e@manjaro.org>. +This document as been moved to linkgit:gitbreaking-changes[7]. diff --git a/Documentation/Makefile b/Documentation/Makefile index f8dea4b3953..8b0390ac0fc 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -49,6 +49,7 @@ MAN5_TXT += gitprotocol-v2.adoc MAN5_TXT += gitrepository-layout.adoc MAN5_TXT += gitweb.conf.adoc +MAN7_TXT += gitbreaking-changes.adoc MAN7_TXT += gitcli.adoc MAN7_TXT += gitcore-tutorial.adoc MAN7_TXT += gitcredentials.adoc diff --git a/Documentation/gitbreaking-changes.adoc b/Documentation/gitbreaking-changes.adoc new file mode 100644 index 00000000000..c6b974b6d8c --- /dev/null +++ b/Documentation/gitbreaking-changes.adoc @@ -0,0 +1,378 @@ +gitbreaking-changes(7) +====================== + +NAME +---- +gitbreaking-changes - Breaking changes for upcoming Git 3.0 + +SYNOPSIS +-------- +* + +DESCRIPTION +----------- +* + +== Introduction: Upcoming breaking changes + +The Git project aims to ensure backwards compatibility to the best extent +possible. Minor releases will not break backwards compatibility unless there is +a very strong reason to do so, like for example a security vulnerability. + +Regardless of that, due to the age of the Git project, it is only natural to +accumulate a backlog of backwards-incompatible changes that will eventually be +required to keep the project aligned with a changing world. These changes fall +into several categories: + +* Changes to long established defaults. +* Concepts that have been replaced with a superior design. +* Concepts, commands, configuration or options that have been lacking in major + ways and that cannot be fixed and which will thus be removed without any + replacement. + +Explicitly not included in this list are fixes to minor bugs that may cause a +change in user-visible behavior. + +The Git project irregularly releases breaking versions that deliberately break +backwards compatibility with older versions. This is done to ensure that Git +remains relevant, safe and maintainable going forward. The release cadence of +breaking versions is typically measured in multiple years. We had the following +major breaking releases in the past: + +* Git 1.6.0, released in August 2008. +* Git 2.0, released in May 2014. + +We use . release numbers these days, starting from Git 2.0. For +future releases, our plan is to increment in the release number when we +make the next breaking release. Before Git 2.0, the release numbers were +1.. with the intention to increment for "usual" breaking +releases, reserving the jump to Git 2.0 for really large backward-compatibility +breaking changes. + +The intent of this document is to track upcoming deprecations for future +breaking releases. Furthermore, this document also tracks what will _not_ be +deprecated. This is done such that the outcome of discussions document both +when the discussion favors deprecation, but also when it rejects a deprecation. + +Items should have a clear summary of the reasons why we do or do not want to +make the described change that can be easily understood without having to read +the mailing list discussions. If there are alternatives to the changed feature, +those alternatives should be pointed out to our users. + +All items should be accompanied by references to relevant mailing list threads +where the deprecation was discussed. These references use message-IDs, which +can visited via + + https://lore.kernel.org/git/$message_id/ + +to see the message and its surrounding discussion. Such a reference is there to +make it easier for you to find how the project reached consensus on the +described item back then. + +This is a living document as the environment surrounding the project changes +over time. If circumstances change, an earlier decision to deprecate or change +something may need to be revisited from time to time. So do not take items on +this list to mean "it is settled, do not waste our time bringing it up again". + +== Procedure + +Discussing the desire to make breaking changes, declaring that breaking +changes are made at a certain version boundary, and recording these +decisions in this document, are necessary but not sufficient. +Because such changes are expected to be numerous, and the design and +implementation of them are expected to span over time, they have to +be deployable trivially at such a version boundary, prepared over long +time. + +The breaking changes MUST be guarded with the a compile-time switch, +WITH_BREAKING_CHANGES, to help this process. When built with it, +the resulting Git binary together with its documentation would +behave as if these breaking changes slated for the next big version +boundary are already in effect. We also have a CI job to exercise +the work-in-progress version of Git with these breaking changes. + + +== Git 3.0 + +The following subsections document upcoming breaking changes for Git 3.0. There +is no planned release date for this breaking version yet. + +Proposed changes and removals only include items which are "ready" to be done. +In other words, this is not supposed to be a wishlist of features that should +be changed to or replaced in case the alternative was implemented already. + +=== Changes + +* The default hash function for new repositories will be changed from "sha1" + to "sha256". SHA-1 has been deprecated by NIST in 2011 and is nowadays + recommended against in FIPS 140-2 and similar certifications. Furthermore, + there are practical attacks on SHA-1 that weaken its cryptographic properties: ++ + ** The SHAppening (2015). The first demonstration of a practical attack + against SHA-1 with 2^57 operations. + ** SHAttered (2017). Generation of two valid PDF files with 2^63 operations. + ** Birthday-Near-Collision (2019). This attack allows for chosen prefix + attacks with 2^68 operations. + ** Shambles (2020). This attack allows for chosen prefix attacks with 2^63 + operations. ++ +While we have protections in place against known attacks, it is expected +that more attacks against SHA-1 will be found by future research. Paired +with the ever-growing capability of hardware, it is only a matter of time +before SHA-1 will be considered broken completely. We want to be prepared +and will thus change the default hash algorithm to "sha256" for newly +initialized repositories. ++ +An important requirement for this change is that the ecosystem is ready to +support the "sha256" object format. This includes popular Git libraries, +applications and forges. ++ +There is no plan to deprecate the "sha1" object format at this point in time. ++ +Cf. <2f5de416-04ba-c23d-1e0b-83bb655829a7@zombino.com>, +<20170223155046.e7nxivfwqqoprsqj@LykOS.localdomain>, +. + +* The default storage format for references in newly created repositories will + be changed from "files" to "reftable". The "reftable" format provides + multiple advantages over the "files" format: ++ + ** It is impossible to store two references that only differ in casing on + case-insensitive filesystems with the "files" format. This issue is common + on Windows and macOS platforms. As the "reftable" backend does not use + filesystem paths to encode reference names this problem goes away. + ** Similarly, macOS normalizes path names that contain unicode characters, + which has the consequence that you cannot store two names with unicode + characters that are encoded differently with the "files" backend. Again, + this is not an issue with the "reftable" backend. + ** Deleting references with the "files" backend requires Git to rewrite the + complete "packed-refs" file. In large repositories with many references + this file can easily be dozens of megabytes in size, in extreme cases it + may be gigabytes. The "reftable" backend uses tombstone markers for + deleted references and thus does not have to rewrite all of its data. + ** Repository housekeeping with the "files" backend typically performs + all-into-one repacks of references. This can be quite expensive, and + consequently housekeeping is a tradeoff between the number of loose + references that accumulate and slow down operations that read references, + and compressing those loose references into the "packed-refs" file. The + "reftable" backend uses geometric compaction after every write, which + amortizes costs and ensures that the backend is always in a + well-maintained state. + ** Operations that write multiple references at once are not atomic with the + "files" backend. Consequently, Git may see in-between states when it reads + references while a reference transaction is in the process of being + committed to disk. + ** Writing many references at once is slow with the "files" backend because + every reference is created as a separate file. The "reftable" backend + significantly outperforms the "files" backend by multiple orders of + magnitude. + ** The reftable backend uses a binary format with prefix compression for + reference names. As a result, the format uses less space compared to the + "packed-refs" file. ++ +Users that get immediate benefit from the "reftable" backend could continue to +opt-in to the "reftable" format manually by setting the "init.defaultRefFormat" +config. But defaults matter, and we think that overall users will have a better +experience with less platform-specific quirks when they use the new backend by +default. ++ +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. + +* In new repositories, the default branch name will be `main`. We have been + warning that the default name will change since 675704c74dd (init: + provide useful advice about init.defaultBranch, 2020-12-11). The new name + matches the default branch name used in new repositories by many of the + big Git forges. + +* 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.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. +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. + +* The default value of `safe.bareRepository` will change from `all` to + `explicit`. It is all too easy for an attacker to trick a user into cloning a + repository that contains an embedded bare repository with malicious hooks + configured. If the user enters that subdirectory and runs any Git command, Git + discovers the bare repository and the hooks fire. The user does not even need + to run a Git command explicitly: many shell prompts run `git status` in the + background to display branch and dirty state information, and `git status` in + turn may invoke the fsmonitor hook if so configured, making the user + vulnerable the moment they `cd` into the directory. The `safe.bareRepository` + configuration variable was introduced in 8959555cee (setup_git_directory(): + add an owner check for the top-level directory, 2022-03-02) with a default of + `all` to preserve backwards compatibility. ++ +Changing the default to `explicit` means that Git will refuse to work with bare +repositories that are discovered implicitly by walking up the directory tree. +Bare repositories specified explicitly via the `--git-dir` command-line option +or the `GIT_DIR` environment variable continue to work regardless of this +setting. Repositories that look like a `.git` directory, a worktree, or a +submodule directory are also unaffected. ++ +Users who rely on implicit discovery of bare repositories can restore the +previous behavior by setting `safe.bareRepository=all` in their global or +system configuration. + +=== Removals + +* Support for grafting commits has long been superseded by git-replace(1). + Grafts are inferior to replacement refs: ++ + ** Grafts are a local-only mechanism and cannot be shared across + repositories. + ** Grafts can lead to hard-to-diagnose problems when transferring objects + between repositories. ++ +The grafting mechanism has been marked as outdated since e650d0643b (docs: mark +info/grafts as outdated, 2014-03-05) and will be removed. ++ +Cf. <20140304174806.GA11561@sigill.intra.peff.net>. + +* The git-pack-redundant(1) command can be used to remove redundant pack files. + The subcommand is unusably slow and the reason why nobody reports it as a + performance bug is suspected to be the absence of users. We have nominated + the command for removal and have started to emit a user-visible warning in + c3b58472be (pack-redundant: gauge the usage before proposing its removal, + 2020-08-25) whenever the command is executed. ++ +So far there was a single complaint about somebody still using the command, but +that complaint did not cause us to reverse course. On the contrary, we have +doubled down on the deprecation and starting with 4406522b76 (pack-redundant: +escalate deprecation warning to an error, 2023-03-23), the command dies unless +the user passes the `--i-still-use-this` option. ++ +There have not been any subsequent complaints, so this command will finally be +removed. ++ +Cf. , + , + <20230323204047.GA9290@coredump.intra.peff.net>, + +* Support for storing shorthands for remote URLs in "$GIT_COMMON_DIR/branches/" + and "$GIT_COMMON_DIR/remotes/" has been long superseded by storing remotes in + the repository configuration. ++ +The mechanism has originally been introduced in f170e4b39d ([PATCH] fetch/pull: +short-hand notation for remote repositories., 2005-07-16) and was superseded by +6687f8fea2 ([PATCH] Use .git/remote/origin, not .git/branches/origin., +2005-08-20), where we switched from ".git/branches/" to ".git/remotes/". That +commit already mentions an upcoming deprecation of the ".git/branches/" +directory, and starting with a1d4aa7424 (Add repository-layout document., +2005-09-01) we have also marked this layout as deprecated. Eventually we also +started to migrate away from ".git/remotes/" in favor of config-based remotes, +and we have marked the directory as legacy in 3d3d282146 (Documentation: +Grammar correction, wording fixes and cleanup, 2011-08-23) ++ +As our documentation mentions, these directories are unlikely to be used in +modern repositories and most users aren't even aware of these mechanisms. They +have been deprecated for almost 20 years and 14 years respectively, and we are +not aware of any active users that have complained about this deprecation. +Furthermore, the ".git/branches/" directory is nowadays misleadingly named and +may cause confusion as "branches" are almost exclusively used in the context of +references. ++ +These features will be removed. + +* Support for "--stdin" option in the "name-rev" command was + deprecated (and hidden from the documentation) in the Git 2.40 + timeframe, in preference to its synonym "--annotate-stdin". Git 3.0 + removes the support for "--stdin" altogether. + +* The git-whatchanged(1) command has outlived its usefulness more than + 10 years ago, and takes more keystrokes to type than its rough + equivalent `git log --raw`. We have nominated the command for + removal, have changed the command to refuse to work unless the + `--i-still-use-this` option is given, and asked the users to report + when they do so. ++ +The command will be removed. + +* Support for `core.commentString=auto` has been deprecated and will + be removed in Git 3.0. ++ +cf. + +* Support for `core.preferSymlinkRefs=true` has been deprecated and will be + removed in Git 3.0. Writing symbolic refs as symbolic links will be phased + out in favor of using plain files using the textual representation of + symbolic refs. ++ +Symbolic references were initially always stored as a symbolic link. This was +changed in 9b143c6e15 (Teach update-ref about a symbolic ref stored in a +textfile., 2005-09-25), where a new textual symref format was introduced to +store those symbolic refs in a plain file. In 9f0bb90d16 +(core.prefersymlinkrefs: use symlinks for .git/HEAD, 2006-05-02), the Git +project switched the default to use the textual symrefs in favor of symbolic +links. ++ +The migration away from symbolic links has happened almost 20 years ago by now, +and there is no known reason why one should prefer them nowadays. Furthermore, +symbolic links are not supported on some platforms. ++ +Note that only the writing side for such symbolic links is deprecated. Reading +such symbolic links is still supported for now. + +== Superseded features that will not be deprecated + +Some features have gained newer replacements that aim to improve the design in +certain ways. The fact that there is a replacement does not automatically mean +that the old way of doing things will eventually be removed. This section tracks +those features with newer alternatives. + +* The features git-checkout(1) offers are covered by the pair of commands + git-restore(1) and git-switch(1). Because the use of git-checkout(1) is still + widespread, and it is not expected that this will change anytime soon, all + three commands will stay. ++ +This decision may get revisited in case we ever figure out that there are +almost no users of any of the commands anymore. ++ +Cf. , +, +<112b6568912a6de6672bf5592c3a718e@manjaro.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/meson.build b/Documentation/meson.build index f4854f802d4..af436b2d5e9 100644 --- a/Documentation/meson.build +++ b/Documentation/meson.build @@ -192,6 +192,7 @@ manpages = { 'gitweb.conf.adoc' : 5, # Category 7. + 'gitbreaking-changes.adoc' : 7, 'gitcli.adoc' : 7, 'gitcore-tutorial.adoc' : 7, 'gitcredentials.adoc' : 7, -- 2.55.0.793.gc667de3f2c5 ``` ## kristofferhaugsbakk@fastmail.com, 2026-09-28 10:41 Subject: [RFC PATCH 2/4] doc: gitbreaking-changes: replace msg-ids with URLs Message-ID: In-Reply-To: ``` From: Kristoffer Haugsbakk This document has used msg-ids to reference emails since its inception.[1] This makes the text a bit more terse, and is perhaps also convenient for people who can use msg-ids to link to messages in their inbox. But we should consider how convenient this is for people in general, now that this is a more public-facing page (see previous commit). And I suspect that most people will be forced to paste the msg-id according to the described URL template: https://lore.kernel.org/git/$message_id/ Let’s instead replace all of the msg-ids with complete links. That way everyone can jump right to the discussions. † 1: 57ec9254 (docs: introduce document to announce breaking changes, 2024-06-14) Note that we have to URL encode two msg-ids: CAKvOHKAFXQwt4D8yUCCkf_TQL79mYaJ=KAKhtpDNTvHJFuX1NA@mail.gmail.com CA+EOSBncr=4a4d8n9xS4FNehyebpmX8JiUwCsXD47EQDE+DiUQ@mail.gmail.com Lore can handle them just fine, but asciidoctor(1) cannot. Signed-off-by: Kristoffer Haugsbakk --- Documentation/gitbreaking-changes.adoc | 33 +++++++++++++------------- 1 file changed, 16 insertions(+), 17 deletions(-) diff --git a/Documentation/gitbreaking-changes.adoc b/Documentation/gitbreaking-changes.adoc index c6b974b6d8c..9aba419efc9 100644 --- a/Documentation/gitbreaking-changes.adoc +++ b/Documentation/gitbreaking-changes.adoc @@ -59,15 +59,14 @@ make the described change that can be easily understood without having to read the mailing list discussions. If there are alternatives to the changed feature, those alternatives should be pointed out to our users. -All items should be accompanied by references to relevant mailing list threads -where the deprecation was discussed. These references use message-IDs, which -can visited via +All items should be accompanied by links to relevant mailing list threads +where the deprecation was discussed. These links use this format: https://lore.kernel.org/git/$message_id/ -to see the message and its surrounding discussion. Such a reference is there to -make it easier for you to find how the project reached consensus on the -described item back then. +I.e. they link to the `Message-ID` of the email on the mailing +list. These references are there to make it easier for you to find how +the project reached consensus on the described item back then. This is a living document as the environment surrounding the project changes over time. If circumstances change, an earlier decision to deprecate or change @@ -129,9 +128,9 @@ applications and forges. + There is no plan to deprecate the "sha1" object format at this point in time. + -Cf. <2f5de416-04ba-c23d-1e0b-83bb655829a7@zombino.com>, -<20170223155046.e7nxivfwqqoprsqj@LykOS.localdomain>, -. +Cf. https://lore.kernel.org/git/2f5de416-04ba-c23d-1e0b-83bb655829a7@zombino.com, +https://lore.kernel.org/git/20170223155046.e7nxivfwqqoprsqj@LykOS.localdomain, +https://lore.kernel.org/git/CA%2BEOSBncr%3D4a4d8n9xS4FNehyebpmX8JiUwCsXD47EQDE%2BDiUQ@mail.gmail.com/. * The default storage format for references in newly created repositories will be changed from "files" to "reftable". The "reftable" format provides @@ -268,7 +267,7 @@ system configuration. The grafting mechanism has been marked as outdated since e650d0643b (docs: mark info/grafts as outdated, 2014-03-05) and will be removed. + -Cf. <20140304174806.GA11561@sigill.intra.peff.net>. +Cf. https://lore.kernel.org/git/20140304174806.GA11561@sigill.intra.peff.net. * The git-pack-redundant(1) command can be used to remove redundant pack files. The subcommand is unusably slow and the reason why nobody reports it as a @@ -286,9 +285,9 @@ the user passes the `--i-still-use-this` option. There have not been any subsequent complaints, so this command will finally be removed. + -Cf. , - , - <20230323204047.GA9290@coredump.intra.peff.net>, +Cf. https://lore.kernel.org/git/xmqq1rjuz6n3.fsf_-_@gitster.c.googlers.com, +https://lore.kernel.org/git/CAKvOHKAFXQwt4D8yUCCkf_TQL79mYaJ%3DKAKhtpDNTvHJFuX1NA%40mail.gmail.com, +https://lore.kernel.org/git/20230323204047.GA9290@coredump.intra.peff.net, * Support for storing shorthands for remote URLs in "$GIT_COMMON_DIR/branches/" and "$GIT_COMMON_DIR/remotes/" has been long superseded by storing remotes in @@ -332,7 +331,7 @@ The command will be removed. * Support for `core.commentString=auto` has been deprecated and will be removed in Git 3.0. + -cf. +cf. https://lore.kernel.org/git/xmqqa59i45wc.fsf@gitster.g * Support for `core.preferSymlinkRefs=true` has been deprecated and will be removed in Git 3.0. Writing symbolic refs as symbolic links will be phased @@ -369,9 +368,9 @@ those features with newer alternatives. This decision may get revisited in case we ever figure out that there are almost no users of any of the commands anymore. + -Cf. , -, -<112b6568912a6de6672bf5592c3a718e@manjaro.org>. +Cf. https://lore.kernel.org/git/xmqqttjazwwa.fsf@gitster.g, +https://lore.kernel.org/git/xmqqleeubork.fsf@gitster.g, +https://lore.kernel.org/git/112b6568912a6de6672bf5592c3a718e@manjaro.org. GIT --- -- 2.55.0.793.gc667de3f2c5 ``` ## kristofferhaugsbakk@fastmail.com, 2026-09-28 10:41 Subject: [RFC PATCH 3/4] doc: gitbreaking-changes: add note about living document Message-ID: In-Reply-To: ``` From: Kristoffer Haugsbakk This document has always stated that it is a “living document”, subject to change. With that in mind, we should be mindful of a potentially larger readerbase now that this is a more public-facing page. One could imagine that someone reads this document on a released version, disagrees with a point there, and posts feedback to the project—but this decision could have already been reverted in the live document.[1] Let’s add a note (admonition) following the “live document” with such a reminder. Let’s keep it short and simple though and not go into how to fetch the source. They can figure that out themselves. † 1: Let’s say that someone on Git for Debian Stable reads about the breaking changes for Git 3.0. They don’t like something about it so they post it to the mailing list. Then the mailing list informs them that Git 3.0 was released two years ago and that the current document is about Git 4.0. Signed-off-by: Kristoffer Haugsbakk --- Documentation/gitbreaking-changes.adoc | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/Documentation/gitbreaking-changes.adoc b/Documentation/gitbreaking-changes.adoc index 9aba419efc9..410476c7993 100644 --- a/Documentation/gitbreaking-changes.adoc +++ b/Documentation/gitbreaking-changes.adoc @@ -73,6 +73,16 @@ over time. If circumstances change, an earlier decision to deprecate or change something may need to be revisited from time to time. So do not take items on this list to mean "it is settled, do not waste our time bringing it up again". +[NOTE] +-- +In case you are reading this document from a released version: this +being a _living document_ means that you might want to consult what +the current, development version of the document looks like in case +anything here motivates you to post some feedback to the project. +Because specific details you read here might have been changed in the +development version. +-- + == Procedure Discussing the desire to make breaking changes, declaring that breaking -- 2.55.0.793.gc667de3f2c5 ``` ## kristofferhaugsbakk@fastmail.com, 2026-09-28 10:41 Subject: [RFC PATCH 4/4] doc: git: mention gitbreaking-changes(7) Message-ID: In-Reply-To: ``` From: Kristoffer Haugsbakk Users are the ones who are impacted by breaking changes. Certainly much more than Git developers who are already plugged in to the development channels that discuss the trajectory of the project. We have to that end already made the breaking changes document into a more public-facing page, namely a regular manpage. Now let’s mention on git(1) like the other user-relevant guides. Like last time,[1] use double-spacing for sentences since that is the existing convention. † 1: 5745353d (doc: git: link to the gitdatamodel(7) tutorial, 2026-09-05) Signed-off-by: Kristoffer Haugsbakk --- Documentation/git.adoc | 5 ++++- command-list.txt | 1 + 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/git.adoc b/Documentation/git.adoc index 6f0075f9188..6a4ef2dff5c 100644 --- a/Documentation/git.adoc +++ b/Documentation/git.adoc @@ -26,7 +26,9 @@ See linkgit:gittutorial[7] to get started, then see linkgit:giteveryday[7] for a useful minimum set of commands. The link:user-manual.html[Git User's Manual] has a more in-depth introduction. See linkgit:gitdatamodel[7] if you want to -learn about the data model and important terminology. +learn about the data model and important terminology. See +linkgit:gitbreaking-changes[7] for a discussion of breaking changes +planned for Git 3.0. After you mastered the basic concepts, you can come back to this page to learn what commands Git offers. You can learn more about @@ -1204,6 +1206,7 @@ linkgit:gittutorial[7], linkgit:gittutorial-2[7], linkgit:giteveryday[7], linkgit:gitcvs-migration[7], linkgit:gitglossary[7], linkgit:gitdatamodel[7], linkgit:gitcore-tutorial[7], linkgit:gitcli[7], +linkgit:gitbreaking-changes[7], link:user-manual.html[The Git User's Manual], linkgit:gitworkflows[7] diff --git a/command-list.txt b/command-list.txt index 63ae2a67c94..1b7236a62fd 100644 --- a/command-list.txt +++ b/command-list.txt @@ -213,6 +213,7 @@ git-whatchanged ancillaryinterrogators complete git-worktree mainporcelain git-write-tree plumbingmanipulators gitattributes userinterfaces +gitbreaking-changes guide gitcli userinterfaces gitcore-tutorial guide gitcredentials guide -- 2.55.0.793.gc667de3f2c5 ``` ## Patrick Steinhardt, 2026-09-30 13:28 Subject: Re: [RFC PATCH 1/4] doc: transform breaking changes doc to a manpage Message-ID: In-Reply-To: ``` On Mon, Sep 28, 2026 at 12:41:25PM +0200, kristofferhaugsbakk@fastmail.com wrote: > From: Kristoffer Haugsbakk > > The breaking changes document is not a regular Git documentation page. > That means that you cannot navigate to the doc with git(1), i.e. with: > > git help BreakingChanges > > You instead have to download the Git project source. Or go to > git-scm.com.[1] Then you get this disclaimer:[2] > > This information is specific to the Git project > > Please note that this information is only relevant to you if you > plan on contributing to the Git project itself. It is in no shape or > form required reading for regular Git users. > > But this document is relevant to *all* Git users. Everyone should have > as easy access to it as the other doc and guide pages. Yeah, I agree with that sentiment. The one interesting question about it is of course what we'll do with the document once Git 3.0 is out. Will we retain it? Will we remove it? Will we empty it and make it focus on Git 4.0? I guess once it's a manpage we should definitely retain its contents for a while longer. The breaking changes will be relevant to users even after they've already upgraded to Git 3.0. But if so, we should probably introduce a new section for Git 4.0, at least if we already want to start thinking about that. NB: even if we start thinking about it I think we should probably not release it anytime soon. I guess having a major release once per decade may be good enough. > To that end, let’s move the text to a manpage. But keep the old page, > just linking to the new one. (We wouldn’t want to break any readers.) > > Just do the minimal changes for the new format. Also demote the first > section to the second level, i.e. make “Introduction” the same level > as “Procedure’. I feel like a good first step could've been to convert the BreakingChanges.adoc document in-place to use the new format. Like that, it would've become way easier to see what's actually changing. The rename could've then been a 1:1 move. Patrick ``` ## Patrick Steinhardt, 2026-09-30 13:28 Subject: Re: [RFC PATCH 2/4] doc: gitbreaking-changes: replace msg-ids with URLs Message-ID: In-Reply-To: ``` On Mon, Sep 28, 2026 at 12:41:26PM +0200, kristofferhaugsbakk@fastmail.com wrote: > From: Kristoffer Haugsbakk > > This document has used msg-ids to reference emails since its > inception.[1] This makes the text a bit more terse, and is perhaps > also convenient for people who can use msg-ids to link to messages > in their inbox. But we should consider how convenient this is for people > in general, now that this is a more public-facing page (see previous > commit). And I suspect that most people will be forced to paste the > msg-id according to the described URL template: > > https://lore.kernel.org/git/$message_id/ > > Let’s instead replace all of the msg-ids with complete links. That way > everyone can jump right to the discussions. Fair. The links may of course break if at any point in time lore.kernel.org were to vanish or change its interface. But if so we can adapt accordingly, also because the message ID can still be extracted trivially. > > diff --git a/Documentation/gitbreaking-changes.adoc b/Documentation/gitbreaking-changes.adoc > index c6b974b6d8c..9aba419efc9 100644 > --- a/Documentation/gitbreaking-changes.adoc > +++ b/Documentation/gitbreaking-changes.adoc > @@ -59,15 +59,14 @@ make the described change that can be easily understood without having to read > the mailing list discussions. If there are alternatives to the changed feature, > those alternatives should be pointed out to our users. > > -All items should be accompanied by references to relevant mailing list threads > -where the deprecation was discussed. These references use message-IDs, which > -can visited via > +All items should be accompanied by links to relevant mailing list threads > +where the deprecation was discussed. These links use this format: > > https://lore.kernel.org/git/$message_id/ > > -to see the message and its surrounding discussion. Such a reference is there to > -make it easier for you to find how the project reached consensus on the > -described item back then. > +I.e. they link to the `Message-ID` of the email on the mailing > +list. These references are there to make it easier for you to find how > +the project reached consensus on the described item back then. > > This is a living document as the environment surrounding the project changes > over time. If circumstances change, an earlier decision to deprecate or change I wonder whether the information on how to add new entries should now go towards the end of this document. The target audience is expanding with your patch series, and most of those new readers will not care about how to add an entry. > @@ -332,7 +331,7 @@ The command will be removed. > * Support for `core.commentString=auto` has been deprecated and will > be removed in Git 3.0. > + > -cf. > +cf. https://lore.kernel.org/git/xmqqa59i45wc.fsf@gitster.g > > * Support for `core.preferSymlinkRefs=true` has been deprecated and will be > removed in Git 3.0. Writing symbolic refs as symbolic links will be phased Nit: two spaces. Patrick ``` ## Kristoffer Haugsbakk, 2026-09-30 14:09 Subject: Re: [RFC PATCH 2/4] doc: gitbreaking-changes: replace msg-ids with URLs Message-ID: <5e957505-384c-42b3-980c-da905d69c71a@app.fastmail.com> In-Reply-To: ``` On Wed, Sep 30, 2026, at 15:28, Patrick Steinhardt wrote: > On Mon, Sep 28, 2026 at 12:41:26PM +0200, > kristofferhaugsbakk@fastmail.com wrote: >>[snip] >> Let’s instead replace all of the msg-ids with complete links. That way >> everyone can jump right to the discussions. > > Fair. The links may of course break if at any point in time > lore.kernel.org were to vanish or change its interface. But if so we can > adapt accordingly, also because the message ID can still be extracted > trivially. Yeah makes sense. > >> >> diff --git a/Documentation/gitbreaking-changes.adoc b/Documentation/gitbreaking-changes.adoc >> index c6b974b6d8c..9aba419efc9 100644 >> --- a/Documentation/gitbreaking-changes.adoc >> +++ b/Documentation/gitbreaking-changes.adoc >> @@ -59,15 +59,14 @@ make the described change that can be easily understood without having to read >> the mailing list discussions. If there are alternatives to the changed feature, >> those alternatives should be pointed out to our users. >> >> -All items should be accompanied by references to relevant mailing list threads >> -where the deprecation was discussed. These references use message-IDs, which >> -can visited via >> +All items should be accompanied by links to relevant mailing list threads >> +where the deprecation was discussed. These links use this format: >> >> https://lore.kernel.org/git/$message_id/ >> >> -to see the message and its surrounding discussion. Such a reference is there to >> -make it easier for you to find how the project reached consensus on the >> -described item back then. >> +I.e. they link to the `Message-ID` of the email on the mailing >> +list. These references are there to make it easier for you to find how >> +the project reached consensus on the described item back then. >> >> This is a living document as the environment surrounding the project changes >> over time. If circumstances change, an earlier decision to deprecate or change > > I wonder whether the information on how to add new entries should now go > towards the end of this document. The target audience is expanding with > your patch series, and most of those new readers will not care about how > to add an entry. Yeah, I can make that change. > >> @@ -332,7 +331,7 @@ The command will be removed. >> * Support for `core.commentString=auto` has been deprecated and will >> be removed in Git 3.0. >> + >> -cf. >> +cf. https://lore.kernel.org/git/xmqqa59i45wc.fsf@gitster.g >> >> * Support for `core.preferSymlinkRefs=true` has been deprecated and will be >> removed in Git 3.0. Writing symbolic refs as symbolic links will be phased > > Nit: two spaces. Thanks, I’ll fix that. ``` ## Kristoffer Haugsbakk, 2026-09-30 14:17 Subject: Re: [RFC PATCH 1/4] doc: transform breaking changes doc to a manpage Message-ID: <2e53feae-94fe-4e1b-9665-2a639fe08515@app.fastmail.com> In-Reply-To: ``` On Wed, Sep 30, 2026, at 15:28, Patrick Steinhardt wrote: > On Mon, Sep 28, 2026 at 12:41:25PM +0200, > kristofferhaugsbakk@fastmail.com wrote: >> From: Kristoffer Haugsbakk >> >> The breaking changes document is not a regular Git documentation page. >> That means that you cannot navigate to the doc with git(1), i.e. with: >> >> git help BreakingChanges >> >> You instead have to download the Git project source. Or go to >> git-scm.com.[1] Then you get this disclaimer:[2] >> >> This information is specific to the Git project >> >> Please note that this information is only relevant to you if you >> plan on contributing to the Git project itself. It is in no shape or >> form required reading for regular Git users. >> >> But this document is relevant to *all* Git users. Everyone should have >> as easy access to it as the other doc and guide pages. > > Yeah, I agree with that sentiment. I’m glad that this idea makes sense to more than one person. x) > [...] The one interesting question about it is of course what we'll do > with the document once Git 3.0 is out. Will we retain it? Will we > remove it? Will we empty it and make it focus on Git 4.0? > > I guess once it's a manpage we should definitely retain its contents for > a while longer. The breaking changes will be relevant to users even > after they've already upgraded to Git 3.0. But if so, we should probably > introduce a new section for Git 4.0, at least if we already want to > start thinking about that. > > NB: even if we start thinking about it I think we should probably not > release it anytime soon. I guess having a major release once per > decade may be good enough. I know you are wondering out loud here to the fora. But just personally, I imagine that this will happen after Git 3.0: • A section at the end about Git 3.0 for historical interest as well as people on older versions who might be browsing outside of their installation (probably git-scm) (and who might be on pre-3.0) • Git 4.0 discussion before that, however hypothetical or distant the release date > >> To that end, let’s move the text to a manpage. But keep the old page, >> just linking to the new one. (We wouldn’t want to break any readers.) >> >> Just do the minimal changes for the new format. Also demote the first >> section to the second level, i.e. make “Introduction” the same level >> as “Procedure’. > > I feel like a good first step could've been to convert the > BreakingChanges.adoc document in-place to use the new format. Like that, > it would've become way easier to see what's actually changing. The > rename could've then been a 1:1 move. Like this? 1. Convert to the manpage format without changing the filename 2. Rename the file: pure rename without any other modifications 3. Resurrect `BreakingChanges.adoc` with one line that points to the new document Thanks for reviewing. ``` ## Patrick Steinhardt, 2026-09-30 14:28 Subject: Re: [RFC PATCH 1/4] doc: transform breaking changes doc to a manpage Message-ID: In-Reply-To: <2e53feae-94fe-4e1b-9665-2a639fe08515@app.fastmail.com> ``` On Wed, Sep 30, 2026 at 04:17:44PM +0200, Kristoffer Haugsbakk wrote: > On Wed, Sep 30, 2026, at 15:28, Patrick Steinhardt wrote: > > On Mon, Sep 28, 2026 at 12:41:25PM +0200, kristofferhaugsbakk@fastmail.com wrote: > >> From: Kristoffer Haugsbakk > > [...] The one interesting question about it is of course what we'll do > > with the document once Git 3.0 is out. Will we retain it? Will we > > remove it? Will we empty it and make it focus on Git 4.0? > > > > I guess once it's a manpage we should definitely retain its contents for > > a while longer. The breaking changes will be relevant to users even > > after they've already upgraded to Git 3.0. But if so, we should probably > > introduce a new section for Git 4.0, at least if we already want to > > start thinking about that. > > > > NB: even if we start thinking about it I think we should probably not > > release it anytime soon. I guess having a major release once per > > decade may be good enough. > > I know you are wondering out loud here to the fora. But just personally, > I imagine that this will happen after Git 3.0: > > • A section at the end about Git 3.0 for historical interest as well as > people on older versions who might be browsing outside of their > installation (probably git-scm) (and who might be on pre-3.0) > • Git 4.0 discussion before that, however hypothetical or distant the > release date Yeah, that's also mostly what I arrived at, too. > >> To that end, let’s move the text to a manpage. But keep the old page, > >> just linking to the new one. (We wouldn’t want to break any readers.) > >> > >> Just do the minimal changes for the new format. Also demote the first > >> section to the second level, i.e. make “Introduction” the same level > >> as “Procedure’. > > > > I feel like a good first step could've been to convert the > > BreakingChanges.adoc document in-place to use the new format. Like that, > > it would've become way easier to see what's actually changing. The > > rename could've then been a 1:1 move. > > Like this? > > 1. Convert to the manpage format without changing the filename > 2. Rename the file: pure rename without any other modifications > 3. Resurrect `BreakingChanges.adoc` with one line that points to the new > document I guess (2) and (3) can easily be combined. I'd hope that Git still detects this as a 1:1 rename. Patrick ``` ## Junio C Hamano, 2026-09-30 19:45 Subject: Re: [RFC PATCH 2/4] doc: gitbreaking-changes: replace msg-ids with URLs Message-ID: In-Reply-To: ``` Patrick Steinhardt writes: > On Mon, Sep 28, 2026 at 12:41:26PM +0200, kristofferhaugsbakk@fastmail.com wrote: >> From: Kristoffer Haugsbakk >> >> This document has used msg-ids to reference emails since its >> inception.[1] This makes the text a bit more terse, and is perhaps >> also convenient for people who can use msg-ids to link to messages >> in their inbox. But we should consider how convenient this is for people >> in general, now that this is a more public-facing page (see previous >> commit). And I suspect that most people will be forced to paste the >> msg-id according to the described URL template: >> >> https://lore.kernel.org/git/$message_id/ >> >> Let’s instead replace all of the msg-ids with complete links. That way >> everyone can jump right to the discussions. > > Fair. The links may of course break if at any point in time > lore.kernel.org were to vanish or change its interface. But if so we can > adapt accordingly, also because the message ID can still be extracted > trivially. One caveat is that some "funny characters" in message IDs need to be URL-encoded. A recent example I saw was <20260930061524.GNkIK%taahol@utu.fi>; https://lore.kernel.org/git/20260930061524.GNkIK%25taahol@utu.fi/ is the URL you need to visit to view the message. Having said that, I am somewhat negative on what this particular patch does. We should instead give both, having something like cf. https://lore.kernel.org/git/xmqqa59i45wc.fsf@gitster.g/[^] in the source, and render a readable link text with reachable href when shown in the browser. ``` ## Patrick Steinhardt, 2026-10-01 06:27 Subject: Re: [RFC PATCH 2/4] doc: gitbreaking-changes: replace msg-ids with URLs Message-ID: In-Reply-To: ``` On Wed, Sep 30, 2026 at 12:45:06PM -0700, Junio C Hamano wrote: > Patrick Steinhardt writes: > > > On Mon, Sep 28, 2026 at 12:41:26PM +0200, kristofferhaugsbakk@fastmail.com wrote: > >> From: Kristoffer Haugsbakk > >> > >> This document has used msg-ids to reference emails since its > >> inception.[1] This makes the text a bit more terse, and is perhaps > >> also convenient for people who can use msg-ids to link to messages > >> in their inbox. But we should consider how convenient this is for people > >> in general, now that this is a more public-facing page (see previous > >> commit). And I suspect that most people will be forced to paste the > >> msg-id according to the described URL template: > >> > >> https://lore.kernel.org/git/$message_id/ > >> > >> Let’s instead replace all of the msg-ids with complete links. That way > >> everyone can jump right to the discussions. > > > > Fair. The links may of course break if at any point in time > > lore.kernel.org were to vanish or change its interface. But if so we can > > adapt accordingly, also because the message ID can still be extracted > > trivially. > > One caveat is that some "funny characters" in message IDs need to be > URL-encoded. > > A recent example I saw was <20260930061524.GNkIK%taahol@utu.fi>; > https://lore.kernel.org/git/20260930061524.GNkIK%25taahol@utu.fi/ is > the URL you need to visit to view the message. > > Having said that, I am somewhat negative on what this particular > patch does. We should instead give both, having something like > > cf. https://lore.kernel.org/git/xmqqa59i45wc.fsf@gitster.g/[^] > > in the source, and render a readable link text with reachable href > when shown in the browser. Oh, that's even better if you ask me! Patrick ``` ## Kristoffer Haugsbakk, 2026-10-03 11:52 Subject: Re: [RFC PATCH 2/4] doc: gitbreaking-changes: replace msg-ids with URLs Message-ID: <533e2f52-2c9c-459a-9fa1-dff3ef4bb2f9@app.fastmail.com> In-Reply-To: ``` On Wed, Sep 30, 2026, at 21:45, Junio C Hamano wrote: > Patrick Steinhardt writes: >> On Mon, Sep 28, 2026 at 12:41:26PM +0200, kristofferhaugsbakk@fastmail.com wrote: >>> From: Kristoffer Haugsbakk >>>[snip] >> >> Fair. The links may of course break if at any point in time >> lore.kernel.org were to vanish or change its interface. But if so we can >> adapt accordingly, also because the message ID can still be extracted >> trivially. > > One caveat is that some "funny characters" in message IDs need to be > URL-encoded. > > A recent example I saw was <20260930061524.GNkIK%taahol@utu.fi>; > https://lore.kernel.org/git/20260930061524.GNkIK%25taahol@utu.fi/ is > the URL you need to visit to view the message. > > Having said that, I am somewhat negative on what this particular > patch does. We should instead give both, having something like > > cf. > https://lore.kernel.org/git/xmqqa59i45wc.fsf@gitster.g/[^] > > in the source, and render a readable link text with reachable href > when shown in the browser. With that I get a regular `href` and a `mailto` href.

cf. <xmqqa59i45wc.fsf@gitster.g>^

The `mailto` wins and prepares to send an email. For HTML output at least (I haven’t tested man yet) you can use `@`: cf. https://lore.kernel.org/git/xmqqa59i45wc.fsf@gitster.g/[^] And that works. But with this rendered output: • Support for core.commentString=auto has been deprecated and will be removed in Git 3.0. cf. ^ You have an exceptionally short (cf. UUID monstrosity) msg-id, like all your msg-ids,[1] to the point that it looks as long as an email address but more random-looking and with a weird domain name. And the exception for email addresses (looking) that are formatted as links are that they are `mailto` links. So what would the expectation be for someone who hasn’t read a preamble about what these things with @-symbols are? That they are contact addresses perhaps? I don’t think this is an improvement. Now people unaccustomed to using msg-ids have to be cognizant of these things as links (not as weird email addresses), which is even assuming that they read the preamble. But with regular URLs you don’t even need a preamble. As for the man format: my terminal lets me open links. Maybe we should drop this patch if we disagree that either choice here is an improvement. † 1: 3/11 of the existing msg-ids are from the maintainer ``` ## Kristoffer Haugsbakk, 2026-10-03 14:10 Subject: Re: [RFC PATCH 2/4] doc: gitbreaking-changes: replace msg-ids with URLs Message-ID: <06ab24bd-eb91-40f6-9a46-a2caf5aa523e@app.fastmail.com> In-Reply-To: <533e2f52-2c9c-459a-9fa1-dff3ef4bb2f9@app.fastmail.com> ``` On Sat, Oct 3, 2026, at 13:52, Kristoffer Haugsbakk wrote: > [snip] > And the exception > for email addresses (looking) that are formatted as links are that they > are `mailto` links. Sorry. Replace “exception” with “expectation”. ``` ## Junio C Hamano, 2026-10-04 02:31 Subject: Re: [RFC PATCH 2/4] doc: gitbreaking-changes: replace msg-ids with URLs Message-ID: In-Reply-To: <533e2f52-2c9c-459a-9fa1-dff3ef4bb2f9@app.fastmail.com> ``` "Kristoffer Haugsbakk" writes: >> Having said that, I am somewhat negative on what this particular >> patch does. We should instead give both, having something like >> >> cf. >> https://lore.kernel.org/git/xmqqa59i45wc.fsf@gitster.g/[^] >> >> in the source, and render a readable link text with reachable href >> when shown in the browser. > > With that I get a regular `href` and a `mailto` href. > >

cf. <xmqqa59i45wc.fsf@gitster.g>^

> > The `mailto` wins and prepares to send an email. Ouch. Our primary goal is to give readers ready access to the messages we refer to. With that mailto glitch, it would be unusable, so let's scrap the idea of using the Message-ID as the link text for the link that leads to the lore archive, unless we can tell Asciidoctor to do what we want. Quite honestly, I did not know Asciidoctor was that broken. Also, if readers do not recognize "Message-ID used as link text" as clickable links, that also defeats the purpose. The secondary goal of my suggestion was to avoid repeating the disaster we faced after gmane stopped offering HTTP access to its archive. We ended up with a bunch of references like $gmane/217 to refer to their article numbers in our historical commit log messages, and of course, once we could no longer rely on them, we had no way of knowing what message article 217 referred to [*]. The URL to the lore archive does contain an encoded Message-ID, so the situation is much better than that of gmane from long ago. However, if you live in an environment where it is easier to feed the Message-ID directly to your e-mail program or newsreader than having to visit the web and then come back to your e-mail environment to continue your work, having a readily cut-and-pasteable Message-ID that is not encoded as part of a URL is definitely superior to having the lore URL alone. But the important point is that this was a secondary goal. If the format using Message-IDs as link texts to go to the lore archive does not work (either because we cannot bypass the mailto behavior, or because readers would not recognize that Message-IDs are clickable links), I am perfectly fine with leaving only the HTTP link that is so obviously a URL (even though I find them rather ugly, but I am not the primary target audience). Thanks for testing this and finding the issues before we went too far. [References] * It is , which I think is still one of the most important messages on the list ;-) ```