Welcome to the 131st edition of Git Rev News, a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to subscribe, see the Git Rev News page on git.github.io.
This edition covers what happened during the months of December 2025 and January 2026.
Would it make sense to add a commit.signOff config?
Stefan Haller started the discussion by asking if it would be
appropriate to add a commit.signoff configuration variable. He
observed that while many Git commands, such as merge,
cherry-pick, and revert, accept the --signoff argument, only
format-patch has a corresponding configuration to enable it for
all invocations. Stefan found it reasonable for users to want a
“Signed-off-by” trailer added automatically to every commit they
make. This question was prompted by his work on the Lazygit
project, which already includes such a configuration and had
received a feature request to extend its behavior to the revert
command.
The “Signed-off-by” trailer is a formal certification that the contributor has the right to submit the work under the project’s license, often associated with a Developer Certificate of Origin (DCO). While widely used in open-source projects to maintain a legal paper trail, its use in closed-source environments is less common.
Carlo Marcelo Arenas Belón replied to Stefan, noting that a similar topic had been discussed recently where it was argued that sign-offs should be given explicitly rather than automated. Junio Hamano, the Git maintainer, agreed and suggested resurrecting a proposal from 2020 to explicitly document why Git intentionally lacks this configuration. Junio expressed a desire to “save time from potential contributors” who might otherwise put effort into a patch that the community had already reached a consensus against.
Collin Funk supported the idea of documenting the consensus and recommended using the full phrase “Signed-off-by” instead of the abbreviation “SoB” to ensure clarity for all readers. brian m. carlson suggested that the explanation could be placed in the Git FAQ, the manual pages, or both. brian also provided a minor grammatical correction to the initial text proposal.
Junio submitted
version 1
of a patch to document the decision. The proposed text explained
that automation makes it harder to defend a sign-off’s validity in
court, as a person could claim the trailer “was done by inertia
without person X really intending to certify what DCO says”. The
patch also acknowledged that while format.signoff exists, it is
considered a “historical mistake” that should not be emulated by
other commands.
Elijah Newren found the initial draft somewhat difficult to parse and suggested an alternative version with more sentence breaks. Elijah’s draft emphasized that Git avoids automatic sign-offs specifically to “protect the legal and intentional significance of a sign-off”. He also recommended a shorter version for the manual pages that would point users toward a more detailed entry in the FAQ. Johannes Sixt agreed that Elijah’s version was much easier to read and suggested a minor shortening of the final sentences to maintain impact. Johannes also emphasized the importance of leaving a pointer in the manual pages, as users looking for automation features are more likely to check documentation for specific commands rather than the general FAQ.
Junio provided
version 2
of the patch, which incorporated Elijah’s and Johannes’s
refinements. During the final review, Johannes suggested changing
the phrase “pile on more mistakes” to “add more mistakes” to be
clearer for non-native English speakers. Junio adopted this change,
noting it would be clear for everyone. Kristoffer Haugsbakk also
contributed a final polish by suggesting the use of a proper
linkgit:gitfaq[7] reference in the manual page. Elijah and brian
both confirmed they were satisfied with the final result.
During the discussion there was a clear consensus that Git will not
add a global commit.signoff configuration. The creation of
permanent documentation in the Git FAQ and manual pages to explain
the legal reasoning behind this decision will prevent future
contributors from wasting time on a feature that would be rejected.
Various
Light reading
Git
section of build-your-own-x
lists a few articles about reimplementing parts of Git functionality.
Mentioned in Git Rev News Edition #40..gitignore file effectively
to used with a monorepo.git show <revision>:<path>.git filter-repo to migrate from Git LFS
to standard Git).jj) is a Git-compatible version control system,
written in Rust, which was first mentioned in
Git Rev News Edition #85.Git tools and sites
git str),
a tool to send and receive Git patches over Nostr,
using NIP-34
(mentioned in Git Rev News Edition #109).git-ssb
(see the git-ssb-intro guide),
a decentralized Git repo hosting and issue tracking on Secure-ScuttleButt (SSB)
(mentioned in Git Rev News Edition #26
and #40).git subcommand
for tracking package dependencies across Git history.
It analyzes your repository to show when dependencies were added, modified, or removed,
who made those changes, and why.
Builds on bibliothecary,
the manifest parsing library behind ecosyste.ms.
Written in Go (originally in Ruby),
under MIT license.This edition of Git Rev News was curated by Christian Couder <christian.couder@gmail.com>, Jakub Narębski <jnareb@gmail.com>, Markus Jansen <mja@jansen-preisler.de> and Kaartic Sivaraam <kaartic.sivaraam@gmail.com> with help from Toon Claes.