* Re: git-2.55.0-rc1 t4216 broken TAP failures on non-x86 arch
From: Patrick Steinhardt @ 2026-06-19 7:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Todd Zullinger, git, Taylor Blau
In-Reply-To: <xmqqeci3nz7h.fsf@gitster.g>
On Thu, Jun 18, 2026 at 05:36:18PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > ... But since 389c83025d (t:
> > let prove fail when parsing invalid TAP output, 2026-06-04) it will
> > cause a test failure.
>
> Thanks. That was the piece I was missing.
I've sent a patch via [1]. Thanks!
Patrick
[1]: <20260619-pks-t4216-drop-unused-prereq-v1-1-2ce0d7bea088@pks.im>
^ permalink raw reply
* [PATCH] t4216: fix no-op test that breaks TAP output
From: Patrick Steinhardt @ 2026-06-19 7:20 UTC (permalink / raw)
To: git; +Cc: Todd Zullinger, Taylor Blau, Junio C Hamano, Jeff King
In t4216 we have have a prerequisite that is active in case the system's
`char` type is signed by default. This prerequisite isn't really used by
anything though: while it is used to guard one of our tests, that
specific test is essentially a no-op. So all this infrastructure does is
to provide some debugging hint to a reader that pays a lot of attention.
Besides that, the way we set up the prerequisite also results in broken
TAP output on systems where `char` is unsigned by default: we use
`test_cmp()` to diff two files outside of of any test body, and if the
files differ we enable the prerequisite. If so, the call to `test_cmp()`
would also print output, and that output is of course not valid TAP
output.
That wasn't a problem before 389c83025d (t: let prove fail when parsing
invalid TAP output, 2026-06-04), because our TAP parser was configured
to be lenient. But starting with that commit, t4216 is now failing on
systems with unsigned chars.
Drop the whole infrastructure. The prerequisite is not used anywhere
else, and the only location where it's used doesn't really provide much
value.
Reported-by: Todd Zullinger <tmz@pobox.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
Hi,
as reported in [1]. Thanks!
Patrick
<20260617220330.n6byiFQr@teonanacatl.net>
---
t/t4216-log-bloom.sh | 21 ---------------------
1 file changed, 21 deletions(-)
diff --git a/t/t4216-log-bloom.sh b/t/t4216-log-bloom.sh
index 1064990de3..16bc39c359 100755
--- a/t/t4216-log-bloom.sh
+++ b/t/t4216-log-bloom.sh
@@ -569,27 +569,6 @@ test_expect_success 'set up repo with high bit path, version 1 changed-path' '
git -C highbit1 commit-graph write --reachable --changed-paths
'
-test_expect_success 'setup check value of version 1 changed-path' '
- (
- cd highbit1 &&
- echo "52a9" >expect &&
- get_first_changed_path_filter >actual
- )
-'
-
-# expect will not match actual if char is unsigned by default. Write the test
-# in this way, so that a user running this test script can still see if the two
-# files match. (It will appear as an ordinary success if they match, and a skip
-# if not.)
-if test_cmp highbit1/expect highbit1/actual
-then
- test_set_prereq SIGNED_CHAR_BY_DEFAULT
-fi
-test_expect_success SIGNED_CHAR_BY_DEFAULT 'check value of version 1 changed-path' '
- # Only the prereq matters for this test.
- true
-'
-
test_expect_success 'setup make another commit' '
# "git log" does not use Bloom filters for root commits - see how, in
# revision.c, rev_compare_tree() (the only code path that eventually calls
---
base-commit: 95e20213faefeb95df29277c58ac1980ab68f701
change-id: 20260619-pks-t4216-drop-unused-prereq-5793107a0249
^ permalink raw reply related
* Re: [PATCH v2 7/8] refs: fix recursing `get_main_ref_store()` with "onbranch" config
From: Patrick Steinhardt @ 2026-06-19 6:25 UTC (permalink / raw)
To: Jeff King; +Cc: git, Karthik Nayak
In-Reply-To: <20260618164035.GA1218204@coredump.intra.peff.net>
On Thu, Jun 18, 2026 at 12:40:35PM -0400, Jeff King wrote:
> On Mon, Jun 15, 2026 at 03:56:53PM +0200, Patrick Steinhardt wrote:
[snip]
> I'd expect the ref database config (like the ref format) to be read not
> through the regular config subsystem, but via read_repository_format()
> and friends. And while that does build on the regular config code, it
> should never enable includes at all. So includeIf.onbranch:foo.path is
> just another uninteresting config key to it.
This feels rather painful though, as we'd now have to do this for every
single backend that we know about. Also, I think not enabling includes
is an overly broad fix: there isn't any reason why "includeif.gitdir"
and all the other conditions shouldn't apply. We really only want to
disable "onbranch".
[snip]
> > The consequence is that we have recursion:
> >
> > 1. We call `get_main_ref_store()`.
> >
> > 2. We don't yet have a reference store, so we call `ref_store_init()`.
> >
> > 3. We parse the configuration required for the reference store.
> >
> > 4. We eventually end up in `include_by_branch()`.
> >
> > 5. We have already configured the reference storage format, so we end
> > up calling `get_main_ref_store()` again.
>
> Ah, the culprit seems to be ref_store_init() calling into the regular
> config parser via repo_settings_get_log_all_ref_updates(). But that
> feels weird to me. Either:
>
> 1. It is application config that should not be something we need to
> load in order to initialize the backend. We could lazy-load it
> later, or rely on higher level code to set the option.
I actually tried lazy-loading, but I found it to be quite painful
overall, as the above setting isn't the only one we use. The reftable
backend for example has a bunch of additional settings that it reads.
We could of course start lazy-loading all of these. But that may not
work for future backends that really _need_ to parse some configuration
at initiation time.
> 2. It is crucial to the ref backend functioning, in which case we
> ought to be reading it alongside core.repositoryFormatVersion, etc.
I think ideally, we'd have a way to read the repository configuration
that explicitly disables parsing includes. We could for example extend
`struct config_options` to have a new "ignore_refdb" toggle then
explicitly use that in the reference backends.
I'll give that a try.
Patrick
^ permalink raw reply
* Re: [PATCH] help: prompt user to run corrected command on typo
From: Jishnu C K @ 2026-06-19 6:05 UTC (permalink / raw)
To: Justin Tobler; +Cc: git, gitster
In-Reply-To: <ajQuqTB580gqNP8D@denethor>
On Thu, Jun 18, 2026, Justin Tobler wrote:
> Isn't this already possible via setting `help.autoCorrect=prompt` in the
> config?
Thank you for the review.
You're right that `help.autocorrect=prompt` exists and is similar.
Our change differs in two ways:
1. No configuration needed. The existing prompt mode requires the user
to explicitly set `help.autocorrect=prompt`. Most users are unaware
of this option, so they see a suggestion and must retype the full
command manually. Our change makes the interactive prompt the
default behaviour when stdin and stderr are a terminal.
2. The prompt includes the original arguments. `help.autocorrect=prompt`
shows only:
Run 'checkout' instead [y/N]?
Our prompt shows the full corrected invocation:
Did you mean 'git checkout neo'? [y/N]
This lets the user confirm exactly what will run, including their
original arguments, before pressing 'y'.
If the consensus is that the default should remain non-interactive,
we are happy to rework this as an improvement to the existing
`autocorrect=prompt` mode (showing args in the prompt) with
documentation updates to make the option more discoverable.
--
Jishnu C K
^ permalink raw reply
* [PATCH v3 5/5] SubmittingPatches: note that trailer order matters
From: kristofferhaugsbakk @ 2026-06-19 5:44 UTC (permalink / raw)
To: git; +Cc: Kristoffer Haugsbakk, Patrick Steinhardt, Junio C Hamano
In-Reply-To: <V3_CV_SubPatches_trailers.9ec@msgid.xyz>
From: Kristoffer Haugsbakk <code@khaugsbakk.name>
It matters where you put new trailers: they should be added in
chronological order, and each person who passes on a patch should add
their s-o-b last. You are signing off on the patch as well as the whole
message up to that point.
This also makes it clear who added what:
Acked-by: The Reviewer <r@example.org>
Signed-off-by: The Contributor <c@example.org>
Acked-by: The (Late) Reviewer <late@example.org>
Signed-off-by: The Maintainer <m@example.org>
The first ack was added by the contributor and the second one was added
by the maintainer.
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---
Notes (series):
v2:
• Mention this in both the DCO section (new) as well as the trailers
section
• Emphasize and lead with chronological order and let everything
fall in place according to that
• https://lore.kernel.org/git/xmqq8q8mt4eo.fsf@gitster.g/
• Msg: Drop “the the”; one is enough
Documentation/SubmittingPatches | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 125bc0a2d63..56706e55ea1 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -427,6 +427,10 @@ D-C-O. Indeed you are encouraged to do so. Do not forget to
place an in-body "From: " line at the beginning to properly attribute
the change to its true author (see (2) above).
+Place this `Signed-off-by:` trailer at the end, after trailers added by
+others and after other trailers added by you; see
+<<commit-trailers,Commit trailers>> below ("chronological order").
+
This procedure originally came from the Linux kernel project, so our
rule is quite similar to theirs, but what exactly it means to sign-off
your patch differs from project to project, so it may be different
@@ -487,6 +491,12 @@ particular are not used in this project.
Only capitalize the very first letter of the trailer, i.e. favor
`Signed-off-by:` over `Signed-Off-By:` and `Acked-by:` over `Acked-By:`.
+As mentioned under <<dco,DCO>> above, trailers are added in
+chronological order; one person might sign-off on a patch and send it to
+someone else, who then in turn adds her own sign-off. Further, any
+trailers that you add beyond your sign-off should come before that
+sign-off. That makes it clear what trailers which person added.
+
[[ai]]
=== Use of Artificial Intelligence (AI)
--
2.54.0.22.g9e26862b904
^ permalink raw reply related
* [PATCH v3 4/5] SubmittingPatches: be consistent with trailer markup
From: kristofferhaugsbakk @ 2026-06-19 5:44 UTC (permalink / raw)
To: git; +Cc: Kristoffer Haugsbakk, Patrick Steinhardt
In-Reply-To: <V3_CV_SubPatches_trailers.9ec@msgid.xyz>
From: Kristoffer Haugsbakk <code@khaugsbakk.name>
The rest of this section and (most importantly) the list has decided to
use `<key>:`. So let’s use backticks (`) and a colon (:) throughout the
document.
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---
Documentation/SubmittingPatches | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 5b4ab93543c..125bc0a2d63 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -374,7 +374,7 @@ or, on an older version of Git without support for --pretty=reference:
....
[[sign-off]]
-=== Certify your work by adding your `Signed-off-by` trailer
+=== Certify your work by adding your `Signed-off-by:` trailer
To improve tracking of who did what, we ask you to certify that you
wrote the patch or have the right to pass it on under the same license
@@ -411,7 +411,7 @@ d. I understand and agree that this project and the contribution
this project or the open source license(s) involved.
____
-you add a "Signed-off-by" trailer to your commit, that looks like
+you add a `Signed-off-by:` trailer to your commit, that looks like
this:
....
@@ -421,7 +421,7 @@ this:
This line can be added by Git if you run the git-commit command with
the -s option.
-Notice that you can place your own `Signed-off-by` trailer when
+Notice that you can place your own `Signed-off-by:` trailer when
forwarding somebody else's patch with the above rules for
D-C-O. Indeed you are encouraged to do so. Do not forget to
place an in-body "From: " line at the beginning to properly attribute
@@ -433,7 +433,7 @@ your patch differs from project to project, so it may be different
from that of the project you are accustomed to.
[[real-name]]
-Please use a known identity in the `Signed-off-by` trailer, since we cannot
+Please use a known identity in the `Signed-off-by:` trailer, since we cannot
accept anonymous contributions. It is common, but not required, to use some form
of your real name. We realize that some contributors are not comfortable doing
so or prefer to contribute under a pseudonym or preferred name and we can accept
@@ -485,7 +485,7 @@ Other projects might regularly refer to other kinds of data, like
particular are not used in this project.
Only capitalize the very first letter of the trailer, i.e. favor
-"Signed-off-by" over "Signed-Off-By" and "Acked-by:" over "Acked-By".
+`Signed-off-by:` over `Signed-Off-By:` and `Acked-by:` over `Acked-By:`.
[[ai]]
=== Use of Artificial Intelligence (AI)
@@ -607,7 +607,7 @@ Here is a link:MyFirstContribution.html#v2-git-send-email[step-by-step guide] on
how to submit updated versions of a patch series.
If your log message (including your name on the
-`Signed-off-by` trailer) is not writable in ASCII, make sure that
+`Signed-off-by:` trailer) is not writable in ASCII, make sure that
you send off a message in the correct encoding.
WARNING: Be wary of your MUAs word-wrap
@@ -627,7 +627,7 @@ previously sent.
The `git format-patch` command follows the best current practice to
format the body of an e-mail message. At the beginning of the
patch should come your commit message, ending with the
-`Signed-off-by` trailers, and a line that consists of three dashes,
+`Signed-off-by:` trailers, and a line that consists of three dashes,
followed by the diffstat information and the patch itself. If
you are forwarding a patch from somebody else, optionally, at
the beginning of the e-mail message just before the commit
--
2.54.0.22.g9e26862b904
^ permalink raw reply related
* [PATCH v3 3/5] SubmittingPatches: document Based-on-patch-by trailer
From: kristofferhaugsbakk @ 2026-06-19 5:44 UTC (permalink / raw)
To: git; +Cc: Kristoffer Haugsbakk, Patrick Steinhardt
In-Reply-To: <V3_CV_SubPatches_trailers.9ec@msgid.xyz>
From: Kristoffer Haugsbakk <code@khaugsbakk.name>
This trailer comes up often enough and the use case is not fully covered
by the other trailers here. For example, it is sometimes better to use
this trailer instead of `Co-authored-by:`.
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---
Notes (series):
v2:
• Do *not* say *without sign-off*; do mention the precondition that
it is signed off, and cover the case when the patch author did not
sign off on it
• https://lore.kernel.org/git/xmqqse6tnho1.fsf@gitster.g/
• Drop “without a commit message”. It doesn’t seem important. A bare
patch is just a patch, not a patch plus a message.
Documentation/SubmittingPatches | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 8d946e9acb3..5b4ab93543c 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -465,6 +465,10 @@ These are the common trailers in use:
and found it to have the desired effect.
. `Co-authored-by:` is used to indicate that people exchanged drafts
of a patch before submitting it.
+. `Based-on-patch-by:` is used when someone else authored parts of the
+ patch that you are submitting. This might be relevant if someone sent
+ a patch to the mailing list with their sign-off. (Be mindful and ask
+ them to sign off on it if they did not.)
. `Helped-by:` is used to credit someone who suggested ideas for
changes without providing the precise changes in patch form.
. `Mentored-by:` is used to credit someone with helping develop a
--
2.54.0.22.g9e26862b904
^ permalink raw reply related
* [PATCH v3 2/5] SubmittingPatches: discourage common Linux trailers
From: kristofferhaugsbakk @ 2026-06-19 5:44 UTC (permalink / raw)
To: git; +Cc: Kristoffer Haugsbakk, Patrick Steinhardt
In-Reply-To: <V3_CV_SubPatches_trailers.9ec@msgid.xyz>
From: Kristoffer Haugsbakk <code@khaugsbakk.name>
The Linux Kernel regularly uses trailers (or “tags”) `Fixes` and
`Link`. Sometimes people submit patches to this project with them.
They have their use in that project but it is not clear what purpose
they would serve here.
For `Fixes`: Linux has many trees, and applying patches with
cherry-picks is common. A `Fixes` trailer in commit C2 pointing to
commit C1 helps the cherry-picker figure out that she probably needs
C2 if she wants to apply C1. See linux/d5d6281a (checkpatch: check for
missing Fixes tags, 2024-06-11):[1]
Why are stable patches encouraged to have a fixes tag? Some people
mark their stable patches as "# 5.10" etc. This is useful but a
Fixes tag is still a good idea. For example, the Fixes tag helps in
review. It helps people to not cherry-pick buggy patches without
also cherry-picking the fix.
In contrast the Git project has few trees (to my knowledge), and there
is much less need to cherry-pick fixes as opposed to either using
backmerges or rebasing all of the downstream tree’s commits on top of
git.git `master` from time to time.
This project does regularly mention what commits a patch/commit fixes,
but that is done inline in the commit message proper (cf. the trailer
block of the message).
For `Link`: These are used both to link back to the patch submission as
well as with footnotes. In contrast this project has `refs/notes/amlog`
for linking back to the patch submissions, and footnotes are only used
in the commit message proper.
† 1: Commit linux/d5d6281a has “linux” in front of it since this commit
is from the Linux Kernel, not Git. Example of a Linux tree—as well
as an example of `Link`—is [2].
Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/ [2]
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---
Notes (series):
v2: Msg: it’s “cf.”, not “c.f.”
Documentation/SubmittingPatches | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 4e8dea4eaa6..8d946e9acb3 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -476,6 +476,10 @@ While you can also create your own trailer if the situation warrants it, we
encourage you to instead use one of the common trailers in this project
highlighted above.
+Other projects might regularly refer to other kinds of data, like
+`Fixes:` and `Link:` in the Linux Kernel project, but these ones in
+particular are not used in this project.
+
Only capitalize the very first letter of the trailer, i.e. favor
"Signed-off-by" over "Signed-Off-By" and "Acked-by:" over "Acked-By".
--
2.54.0.22.g9e26862b904
^ permalink raw reply related
* [PATCH v3 1/5] SubmittingPatches: encourage trailer use for substantial help
From: kristofferhaugsbakk @ 2026-06-19 5:44 UTC (permalink / raw)
To: git; +Cc: Kristoffer Haugsbakk, Patrick Steinhardt
In-Reply-To: <V3_CV_SubPatches_trailers.9ec@msgid.xyz>
From: Kristoffer Haugsbakk <code@khaugsbakk.name>
Trailers beyond the mandatory s-o-b are regularly used based on my
last two years of reading the mailing list. Moreover, reviewers might
encourage it.[1]
This is also in line with the project crediting both commit authors and
people mentioned in trailers each release; “Nobody is THE one making
contribution”.[2]
Adding trailers is already encouraged, but in the section `send-patches`.
Let’s replace “If you like” with outright encouragement in this section
so that all trailer discussion (except s-o-b; see `sign-off` section) is
contained in this section; a link to from `send-patches` makes this
information equally visible.
Now we need to make a heading for `commit-trailers` in order for the
HTML output to make sense.
At the same time, it is important to temper this recommendation to a
significant enough contribution; in my experience beginners can be eager
to add a trailer for everyone who replies with an action point that is
followed up on.
Let’s also spell out that these trailers should follow the Git author/
committer format. One might naturally just write the name, but in that
case it will not be picked up by:
git shortlog --group=trailer:<key>
and normalization via `.mailmap` will not work.
Also introduce the list of common trailers as such. Granted, this is
already implied by the later paragraph about “create your own trailer”,
so this just frontloads this information.
† 1: https://lore.kernel.org/git/CAP8UFD0POvYDgGtEx8GBhvKkd8XzzWQsy8XxAKL9M3+uz3ka+w@mail.gmail.com/#:~:text=for%20at%20least
† 2: https://lore.kernel.org/git/xmqqzh248sy0.fsf@gitster.c.googlers.com/
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---
Notes (series):
v3: correct anchor placement
🔗 https://lore.kernel.org/git/xmqq4ij0vo8f.fsf@gitster.g/
v2:
• Msg: proofreading typos, dropped words[1]
• Msg: Avoid hyphenating for linebreaks on syllable[1]
🔗 1: https://lore.kernel.org/git/310ef65e-b6c7-4d0c-a58a-0c88257143ba@app.fastmail.com/
Documentation/SubmittingPatches | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 176567738d4..4e8dea4eaa6 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -444,7 +444,15 @@ The goal of this policy is to allow us to have sufficient information to contact
you if questions arise about your contribution.
[[commit-trailers]]
-If you like, you can put extra trailers at the end:
+=== Commit trailers
+It is polite to credit people who have helped with your work to a
+substantial enough degree. This project uses commit trailers for that,
+where the credited person is written out like a Git author, i.e. with
+both their name and their email address. Note that the threshold to
+credit someone is a judgement call, and crediting someone for simple
+review work is certainly not necessary.
+
+These are the common trailers in use:
. `Reported-by:` is used to credit someone who found the bug that
the patch attempts to fix.
@@ -562,8 +570,8 @@ when the maintainer did not heavily participate in the discussion and
instead left the review to trusted others.
Do not forget to add trailers such as `Acked-by:`, `Reviewed-by:` and
-`Tested-by:` lines as necessary to credit people who helped your
-patch, and "cc:" them when sending such a final version for inclusion.
+`Tested-by:` (see <<commit-trailers,Commit trailers>>), and "cc:" them
+when sending such a final version for inclusion.
==== `format-patch` and `send-email`
--
2.54.0.22.g9e26862b904
^ permalink raw reply related
* [PATCH v3 0/5] SubmittingPatches: update and flesh out trailer sections
From: kristofferhaugsbakk @ 2026-06-19 5:44 UTC (permalink / raw)
To: git; +Cc: Kristoffer Haugsbakk, Patrick Steinhardt
In-Reply-To: <CV_SubPatches_trailers.8f3@msgid.xyz>
From: Kristoffer Haugsbakk <code@khaugsbakk.name>
Topic name (applied) kh/submittingpatches-trailers
Topic summary: Flesh out and update the trailer sections.
All of these points have come up on the mailing list. At least for me.
And `Based-on-patch-by` is a nice-to-have documented kind of thing.
[elide “since January” from v1...]
Link to v2: https://lore.kernel.org/git/V2_CV_SubPatches_trailers.9b6@msgid.xyz/
§ Changes in v3
Patch “encourage trailer use for substantial help”: correct AsciiDoc anchor
placement.
[1/5] SubmittingPatches: encourage trailer use for substantial help
[2/5] SubmittingPatches: discourage common Linux trailers
[3/5] SubmittingPatches: document Based-on-patch-by trailer
[4/5] SubmittingPatches: be consistent with trailer markup
[5/5] SubmittingPatches: note that trailer order matters
Documentation/SubmittingPatches | 46 ++++++++++++++++++++++++++-------
1 file changed, 36 insertions(+), 10 deletions(-)
Interdiff against v2:
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index dceeb5a1817..56706e55ea1 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -447,8 +447,8 @@ identifying, and not misleading.
The goal of this policy is to allow us to have sufficient information to contact
you if questions arise about your contribution.
-=== Commit trailers
[[commit-trailers]]
+=== Commit trailers
It is polite to credit people who have helped with your work to a
substantial enough degree. This project uses commit trailers for that,
where the credited person is written out like a Git author, i.e. with
Range-diff against v2:
1: 835eb736f39 ! 1: dc75b862d73 SubmittingPatches: encourage trailer use for substantial help
@@ Commit message
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
## Documentation/SubmittingPatches ##
-@@ Documentation/SubmittingPatches: identifying, and not misleading.
- The goal of this policy is to allow us to have sufficient information to contact
+@@ Documentation/SubmittingPatches: The goal of this policy is to allow us to have sufficient information to contact
you if questions arise about your contribution.
-+=== Commit trailers
[[commit-trailers]]
-If you like, you can put extra trailers at the end:
++=== Commit trailers
+It is polite to credit people who have helped with your work to a
+substantial enough degree. This project uses commit trailers for that,
+where the credited person is written out like a Git author, i.e. with
2: 5a652b8e14d = 2: 86b9973a8e8 SubmittingPatches: discourage common Linux trailers
3: 5e53999b2e9 = 3: a142f66c3b8 SubmittingPatches: document Based-on-patch-by trailer
4: dd47fabe917 = 4: 439fa864da7 SubmittingPatches: be consistent with trailer markup
5: 726386d976b = 5: 2d133f2ad5e SubmittingPatches: note that trailer order matters
base-commit: 1ff279f3404a482a83fb04c7457e41ab26884aea
--
2.54.0.22.g9e26862b904
^ permalink raw reply related
* Re: [PATCH v3 15/17] odb/source-packed: stub out remaining functions
From: Patrick Steinhardt @ 2026-06-19 5:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Karthik Nayak, Justin Tobler
In-Reply-To: <xmqqik7frapn.fsf@gitster.g>
On Thu, Jun 18, 2026 at 10:59:32AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
>
> Just FYI (i.e. nothing wrong in this patch)
>
> > +static int odb_source_packed_write_object(struct odb_source *source UNUSED,
> > + const void *buf UNUSED,
> > + unsigned long len UNUSED,
>
> The type of this parameter will become size_t via another topic in
> flight; I prepared an evil merge to address it (otherwise winbuild
> would barf, as expected).
>
> -- >8 --
> Author: Junio C Hamano <gitster@pobox.com>
> Date: Thu Jun 18 10:49:10 2026 -0700
>
> merge-fix po/hash-object-size-t vs ps/odb-source-packed
>
> diff --git a/odb/source-packed.c b/odb/source-packed.c
> index 42c28fba0e..decc81aa52 100644
> --- a/odb/source-packed.c
> +++ b/odb/source-packed.c
> @@ -503,7 +503,7 @@ static int odb_source_packed_freshen_object(struct odb_source *source,
>
> static int odb_source_packed_write_object(struct odb_source *source UNUSED,
> const void *buf UNUSED,
> - unsigned long len UNUSED,
> + size_t len UNUSED,
> enum object_type type UNUSED,
> struct object_id *oid UNUSED,
> struct object_id *compat_oid UNUSED,
Thanks for the heads up, the change looks obviously correct to me. I'm
also happy to send a rebased version -- just give me a nudge and I'll do
that.
Patrick
^ permalink raw reply
* Re: [PATCH] rebase: mention --abort alongside --continue
From: Junio C Hamano @ 2026-06-19 1:36 UTC (permalink / raw)
To: Harald Nordgren; +Cc: Phillip Wood, Harald Nordgren via GitGitGadget, git
In-Reply-To: <CAHwyqnV8je6gCTExr=CFCdYskN1dVaEDVSKDLUo5A4Ukv=qhiA@mail.gmail.com>
Harald Nordgren <haraldnordgren@gmail.com> writes:
> Just an example when working on a different topic:
>
> I rebased with -x to run all the tests, but ran a test that didn't
> exist yet on the first commit and ended up in a bad state. Here it
> should clearly show the 'git rebase --abort', so I can start over,
> it's not something to fix:
>
> ```
> $ git rebase --keep-base -x 'make -s' -x 'cd t && prove -j8
> t3454-history-squash.sh t3453-history-fixup.sh t3452-history-split.sh
> t3451-history-reword.sh t3450-history.sh'
> Executing: make -s
> GIT_VERSION=2.55.0.rc1.20.g1e31474ef6
> Executing: cd t && prove -j8 t3454-history-squash.sh
> t3453-history-fixup.sh t3452-history-split.sh t3451-history-reword.sh
> t3450-history.sh
> Cannot detect source of 't3454-history-squash.sh'! at
> /System/Library/Perl/5.34/TAP/Parser/IteratorFactory.pm line 256.
> ...
> warning: execution failed: cd t && prove -j8 t3454-history-squash.sh
> t3453-history-fixup.sh t3452-history-split.sh t3451-history-reword.sh
> t3450-history.sh
> You can fix the problem, and then run
>
> git rebase --continue
Hmph, you do not have to "fix" as you know some of the test scripts
did not exist at this stage. So the solution to the issue seems to
be just to say "git rebase --continue", instead of starting over by
aborting. It is especially true if the test scripts are introduced
in the middle of this rebase session somewhere later in the series,
no?
Of course if you gave a totally broken script to "-x" option, you'd
need to be able to abort it, but is that the use case we should be
giving one extra line of output for users in all other situations?
I dunno.
^ permalink raw reply
* Re: git-2.55.0-rc1 t4216 broken TAP failures on non-x86 arch
From: Junio C Hamano @ 2026-06-19 0:36 UTC (permalink / raw)
To: Jeff King; +Cc: Patrick Steinhardt, Todd Zullinger, git, Taylor Blau
In-Reply-To: <20260618233536.GA1431359@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> ... But since 389c83025d (t:
> let prove fail when parsing invalid TAP output, 2026-06-04) it will
> cause a test failure.
Thanks. That was the piece I was missing.
^ permalink raw reply
* [RFH] Why do osx CI jobs so unreliable?
From: Junio C Hamano @ 2026-06-19 0:35 UTC (permalink / raw)
To: git
I've been observing that in recent push-out to 'master' and 'next',
osx-* jobs in GitHub Actions CI keep running for 6 hours and get
killed.
What is troubling is that this seems to be very flaky. For example,
https://github.com/git/git/actions/runs/27778820659 is testing
95e20213 (Hopefully final batch before -rc2, 2026-06-17) which got
killed after wasting 6 hours in osx-clang and osx-gcc jobs.
https://github.com/git/git/actions/runs/27790036076 is testing
the same 'master', with a patch to .github/workflows/main.yml to
remove everything except for config and osx-* jobs, which succeeded
within 30 minutes.
Stumped...
^ permalink raw reply
* Re: [PATCH v3 0/4] history: add squash subcommand to fold a range
From: Junio C Hamano @ 2026-06-19 0:34 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: Harald Nordgren via GitGitGadget, git, Harald Nordgren
In-Reply-To: <pull.2337.v3.git.git.1781810226.gitgitgadget@gmail.com>
"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
> Adds git history squash <revision-range> to fold a range of commits into its
> oldest one, reusing that commit's message and replaying any descendants on
> top.
One thing that just occurred to me.
When you have a linear history
o---A---B---C
you run "git history squash A..C" and come to
o---X
where the tree of X is the same as C, with the log message of A
reused for it. That is simple, clean, and easy to explain.
But what should happen to refs (i.e., branch head) that point at A
or B?
I am adressing this message to Patrick as this question relates to
the grand vision for the "git history" command. I think "git
replay" wants to rewrite all the refs that are involved in the
rewrite operation, while "git rebase" (without "--update-refs")
wants to leave all others refs intact and update only the branch it
was told to rewrite. Is it the same design as "rebase" and
"--update-refs" controls if we update _other_ refs that happened to
be in the range that are rewritten?
Now, assuming that there do exist a mode where the command can
update these refs that point into the history that got rewritten,
there probably are at least two possibilities.
On one hand, I think it is reasonable to _remove_ these refs that
used to point at a section of history that disappeared (like the one
that were pointing at A or B). Perhaps A and B were pointed at by
two branches or tags that were used to mark "up to this point things
are broken" and "from here on things are fixed" (i.e., imagine a
manual bisection). After squashing all of the commits in this
section of history, the result no longer has such transition points.
It also is plausible that users may want these refs that used to
point at A or B to point at X, just like the ref that used to point
at C would now point at X, even though I cannot offhand think of a
good story (like "there used to be transtion points, now there
isn't" I said above to explain why these refs should disappear) to
support such a behaviour.
Thoughts?
^ permalink raw reply
* Re: git-2.55.0-rc1 t4216 broken TAP failures on non-x86 arch
From: Jeff King @ 2026-06-18 23:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Patrick Steinhardt, Todd Zullinger, git, Taylor Blau
In-Reply-To: <xmqq4iizpkig.fsf@gitster.g>
On Thu, Jun 18, 2026 at 03:10:47PM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
>
> >> Building git-2.55.0-rc1 today, all non-x86 architectures
> >> failed with:
> >> ...
> >> This looks like it comes from the following chunk of code in
> >> the test:
> >>
> >> # expect will not match actual if char is unsigned by default. Write the test
> >> # in this way, so that a user running this test script can still see if the two
> >> # files match. (It will appear as an ordinary success if they match, and a skip
> >> # if not.)
> >> if test_cmp highbit1/expect highbit1/actual
> >> then
> >> test_set_prereq SIGNED_CHAR_BY_DEFAULT
> >> fi
> >> test_expect_success SIGNED_CHAR_BY_DEFAULT 'check value of version 1 changed-path' '
> >> # Only the prereq matters for this test.
> >> true
> >> '
>
> The "problematic" part is from mid 2024, so it is not anything new
> in 2.55-rc1, is it? Nobody built and ran tests for the past two
> years on non-x86 boxes?
Presumably they did not notice the extra cruft to stdout, either because
it was being eaten by the TAP harness or for a raw "make test" it was
mixed in with a million other lines of output. But since 389c83025d (t:
let prove fail when parsing invalid TAP output, 2026-06-04) it will
cause a test failure.
-Peff
^ permalink raw reply
* Re: git-2.55.0-rc1 t4216 broken TAP failures on non-x86 arch
From: Junio C Hamano @ 2026-06-18 22:10 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: Todd Zullinger, git, Taylor Blau
In-Reply-To: <ajOP1IOjA3EYvRfm@pks.im>
Patrick Steinhardt <ps@pks.im> writes:
>> Building git-2.55.0-rc1 today, all non-x86 architectures
>> failed with:
>> ...
>> This looks like it comes from the following chunk of code in
>> the test:
>>
>> # expect will not match actual if char is unsigned by default. Write the test
>> # in this way, so that a user running this test script can still see if the two
>> # files match. (It will appear as an ordinary success if they match, and a skip
>> # if not.)
>> if test_cmp highbit1/expect highbit1/actual
>> then
>> test_set_prereq SIGNED_CHAR_BY_DEFAULT
>> fi
>> test_expect_success SIGNED_CHAR_BY_DEFAULT 'check value of version 1 changed-path' '
>> # Only the prereq matters for this test.
>> true
>> '
The "problematic" part is from mid 2024, so it is not anything new
in 2.55-rc1, is it? Nobody built and ran tests for the past two
years on non-x86 boxes?
> Hm, this thing is indeed somewhat puzzling to me. I assume the intent is
> to give the developer some information that their platform is using
> signed characters by default? Other than that it's not really doing
> anything, as the prereq is only used by the one test shown above. I hope
> that Taylor has some more insight here.
>
> There's two potential fixes:
>
> - We can just drop this completely, as it ultimately doesn't even end
> up doing anything.
>
> - We can convert the call to `test_cmp` into a `test_lazy_prereq`,
> like done in the below patch, which retains the current behaviour.
Yeah, unless Taylor can tell us something we are not seeing, I am
inclined to say that we can just get rid of the whole thing.
SIGNED_CHAR_BY_DEFAULT is not used anywhere else, and the only place
it is used isd to run "true".
^ permalink raw reply
* Re: [PATCH 5/7] line-log: support diff stat formats with -L
From: Junio C Hamano @ 2026-06-18 22:00 UTC (permalink / raw)
To: Michael Montalbo via GitGitGadget; +Cc: git, D. Ben Knoble, Michael Montalbo
In-Reply-To: <a70d861d27a13459bab34f6681b3ccfe2f20d0d8.1781806593.git.gitgitgadget@gmail.com>
"Michael Montalbo via GitGitGadget" <gitgitgadget@gmail.com> writes:
> diff --git a/Documentation/line-range-options.adoc b/Documentation/line-range-options.adoc
> index 72f639b5e7..1a25f55bb1 100644
> --- a/Documentation/line-range-options.adoc
> +++ b/Documentation/line-range-options.adoc
> @@ -9,10 +9,14 @@
> _<start>_ and _<end>_ (or _<funcname>_) must exist in the starting revision.
> You can specify this option more than once. Implies `--patch`.
> Patch output can be suppressed using `--no-patch`.
> - Non-patch diff formats `--raw`, `--name-only`, `--name-status`,
> - and `--summary` are supported. Diff stat formats
> - (`--stat`, `--numstat`, `--shortstat`, `--dirstat`) are not
> - currently implemented.
> + The following non-patch diff formats are supported: `--raw`,
> + `--name-only`, `--name-status`, `--summary`,
> + `--stat`, `--numstat`, and `--shortstat`.
> + The stat formats show range-scoped counts: only lines within
> + the tracked range are counted. `--dirstat` is not supported
If "range-scoped" is a widely known term (as opposed to a new word
invented only during the introduction of this topic), the above
reads well with a nice rhythm, but otherwise it may be easier to
read, i.e., something like
The stat formats counts only lines within the tracked range.
without having readers learn yet another new term that is only used
here.
> diff --git a/diff.c b/diff.c
> index 6233a96bf0..026fafeb90 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -4289,7 +4289,18 @@ static void builtin_diffstat(const char *name_a, const char *name_b,
> xecfg.ctxlen = o->context;
> xecfg.interhunkctxlen = o->interhunkcontext;
> xecfg.flags = XDL_EMIT_NO_HUNK_HDR;
> - if (xdi_diff_outf(&mf1, &mf2, NULL,
> +
> + if (p->line_ranges) {
> + struct line_range_filter lr_filter;
> +
> + line_range_filter_init(&lr_filter, p->line_ranges,
> + diffstat_consume, diffstat);
> +
> + if (line_range_filter_diff(&lr_filter, &mf1, &mf2,
> + &xpp, &xecfg))
> + die("unable to generate diffstat for %s",
> + one->path);
> + } else if (xdi_diff_outf(&mf1, &mf2, NULL,
> diffstat_consume, diffstat, &xpp, &xecfg))
> die("unable to generate diffstat for %s", one->path);
It is pleasing to see that this can be done with such a surprisingly
small change.
^ permalink raw reply
* Re: [PATCH v3 3/4] history: add squash subcommand to fold a range
From: D. Ben Knoble @ 2026-06-18 21:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Harald Nordgren via GitGitGadget, git, Harald Nordgren
In-Reply-To: <xmqqzf0rpmn0.fsf@gitster.g>
On Thu, Jun 18, 2026 at 5:25 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Junio C Hamano <gitster@pobox.com> writes:
>
> > As t3454 is taken by another topic already in flight, I've queued a
> > trivial "rename it to t3455" patch on top before queuing the topic.
>
> Another tweak I had to make was to replace "grep" with "test_grep"
> to avoid triggering test lint added by another topic in flight.
>
> For the one in the second hunk, it may be much better to rewrite it
> to process "out" directly with the awk script without preprocessing
> it with "grep", as awk is a programming language capable enough to
> recognize a line that matches a pattern and process only those
> matching lines by itself.
>
> --- >8 ---
> Author: Junio C Hamano <gitster@pobox.com>
> Date: Thu Jun 18 13:44:36 2026 -0700
>
> SQUASH??? avoid test_grep lint triggering on uses of raw grep
>
> diff --git a/t/t3455-history-squash.sh b/t/t3455-history-squash.sh
> index 1edd148295..20370c0136 100755
> --- a/t/t3455-history-squash.sh
> +++ b/t/t3455-history-squash.sh
[snip]
> @@ -177,7 +177,7 @@ test_expect_success '--dry-run predicts the rewrite without performing it' '
> head_before=$(git rev-parse HEAD) &&
>
> git history squash --dry-run start.. >out &&
> - grep "^update refs/heads/" out >update &&
> + test_grep "^update refs/heads/" out >update &&
> predicted=$(awk "{print \$3}" update) &&
> test_cmp_rev "$head_before" HEAD &&
Odd: I thought the other topic acknowledged that bare grep as a filter
(here, with stdout redirected) was fine. My memory must not be right
:)
--
D. Ben Knoble
^ permalink raw reply
* Re: [PATCH v3 3/4] history: add squash subcommand to fold a range
From: Junio C Hamano @ 2026-06-18 21:24 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget; +Cc: git, Harald Nordgren
In-Reply-To: <xmqq7bnvr3qb.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
> As t3454 is taken by another topic already in flight, I've queued a
> trivial "rename it to t3455" patch on top before queuing the topic.
Another tweak I had to make was to replace "grep" with "test_grep"
to avoid triggering test lint added by another topic in flight.
For the one in the second hunk, it may be much better to rewrite it
to process "out" directly with the awk script without preprocessing
it with "grep", as awk is a programming language capable enough to
recognize a line that matches a pattern and process only those
matching lines by itself.
--- >8 ---
Author: Junio C Hamano <gitster@pobox.com>
Date: Thu Jun 18 13:44:36 2026 -0700
SQUASH??? avoid test_grep lint triggering on uses of raw grep
diff --git a/t/t3455-history-squash.sh b/t/t3455-history-squash.sh
index 1edd148295..20370c0136 100755
--- a/t/t3455-history-squash.sh
+++ b/t/t3455-history-squash.sh
@@ -150,10 +150,10 @@ test_expect_success '--reedit-message offers every folded-in message' '
test_set_editor "$(pwd)/editor" &&
git history squash --reedit-message start.. &&
- grep "re-one subject" buffer &&
- grep "re-one body line" buffer &&
- grep re-two buffer &&
- grep re-three buffer &&
+ test_grep "re-one subject" buffer &&
+ test_grep "re-one body line" buffer &&
+ test_grep re-two buffer &&
+ test_grep re-three buffer &&
git log --format="%s" -1 >actual &&
echo combined >expect &&
test_cmp expect actual
@@ -177,7 +177,7 @@ test_expect_success '--dry-run predicts the rewrite without performing it' '
head_before=$(git rev-parse HEAD) &&
git history squash --dry-run start.. >out &&
- grep "^update refs/heads/" out >update &&
+ test_grep "^update refs/heads/" out >update &&
predicted=$(awk "{print \$3}" update) &&
test_cmp_rev "$head_before" HEAD &&
^ permalink raw reply related
* Re: [PATCH v3 0/4] history: add squash subcommand to fold a range
From: D. Ben Knoble @ 2026-06-18 21:23 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget; +Cc: git, Harald Nordgren
In-Reply-To: <pull.2337.v3.git.git.1781810226.gitgitgadget@gmail.com>
On Thu, Jun 18, 2026 at 3:17 PM Harald Nordgren via GitGitGadget
<gitgitgadget@gmail.com> wrote:
>
> Adds git history squash <revision-range> to fold a range of commits into its
> oldest one, reusing that commit's message and replaying any descendants on
> top.
>
> Changes in v3:
>
> * Moved the feature out of git rebase and into a new git history squash
> <revision-range> subcommand, per the list discussion. git rebase --squash
> is dropped.
> * Takes an arbitrary range (git history squash @~3.., git history squash
> @~5..@~2), folding it into the oldest commit and replaying any
> descendants on top.
> * Implemented as a single tree operation rather than picking each commit,
> so there are no repeated conflict stops (addresses Phillip's efficiency
> point).
I think I mentioned this, too, albeit indirectly. I'm not concerned
about credit, though. Just excited to have this.
Thanks!
> * A merge inside the range is folded fine, only a range with more than one
> base is rejected.
> * --reedit-message seeds the editor with every folded-in message, not just
> the oldest.
>
> Harald Nordgren (4):
> history: extract helper for a commit's parent tree
> history: give commit_tree_ext a message template
> history: add squash subcommand to fold a range
> history: re-edit a squash with every message
^ permalink raw reply
* Re: [PATCH v3 3/4] history: add squash subcommand to fold a range
From: Junio C Hamano @ 2026-06-18 20:30 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget; +Cc: git, Harald Nordgren
In-Reply-To: <66b2f49fb427c7328136b2d440dc7461b97fb4e0.1781810227.git.gitgitgadget@gmail.com>
"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
> +static int cmd_history_squash(int argc,
> + const char **argv,
> + const char *prefix,
> + struct repository *repo)
> +{
> + base_tree_oid = &repo_get_commit_tree(repo, base)->object.oid;
> + tip_tree_oid = &repo_get_commit_tree(repo, tip)->object.oid;
> + commit_list_append(base, &parents);
> +
> + ret = commit_tree_ext(repo, "squash", oldest, NULL, parents,
> + base_tree_oid, tip_tree_oid, &rewritten, flags);
We use the tree object taken from the commit at the top end of the
range, and create a new commit directly on top of the boundary
commit beyond the bottom of the range, using the message from the
commit at the bottom of the range. No need to go through the
rigmarole of replaying commits in the range stepwise like sequencer
does, since we are not transplanting the history on top of a
different tree at all. Very nice.
When I do drunken-walk development to build many commits, making
detour to arrive at an ideal state, the key message is often not in
the bottommost commit but somewhere in the middle where I discovered
why my initial attempt were wrong and discovered a much better
solution, so using only the message from the oldest limits the
usefulness of this feature, but I guess for certain people the
bottommost commit would be a good default.
I see you have already an option to grab messages from all the
commits in the range (many of which may have useless "oops, that was
wrong" single-liner) in a way similar to how "git rebase --squash"
or "squash" insn in the "git rebase -i" todo list lets you use them
in the next step, which is workable. It is plausible that we would
later want to offer an option to name the single commit that may not
be the bottommost one and use the message only from that commit.
But we'd need to start from somewhere, and "use the bottommost
commit and nothing else" and "we will give you messages from all the
commits, just rearrange them in your editor" may be a good place to
start.
As t3454 is taken by another topic already in flight, I've queued a
trivial "rename it to t3455" patch on top before queuing the topic.
Thanks.
^ permalink raw reply
* [PATCH v16 7/7] branch: add --dry-run for --delete-merged
From: Harald Nordgren via GitGitGadget @ 2026-06-18 19:25 UTC (permalink / raw)
To: git
Cc: Kristoffer Haugsbakk, Johannes Sixt, Phillip Wood,
Harald Nordgren, Harald Nordgren
In-Reply-To: <pull.2285.v16.git.git.1781810729.gitgitgadget@gmail.com>
From: Harald Nordgren <haraldnordgren@gmail.com>
With --dry-run, --delete-merged prints the local branches it would
delete, one "Would delete branch <name>" line each, and exits
without touching any ref. The same filtering applies, so the output
is exactly the set that the real run would delete.
--dry-run is only meaningful together with --delete-merged and is
rejected otherwise.
Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
---
Documentation/git-branch.adoc | 8 +++++++-
builtin/branch.c | 9 ++++++++-
t/t3200-branch.sh | 11 ++++++++++-
3 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-branch.adoc b/Documentation/git-branch.adoc
index 91700f2e8a..09063d74f2 100644
--- a/Documentation/git-branch.adoc
+++ b/Documentation/git-branch.adoc
@@ -25,7 +25,7 @@ git branch (-m|-M) [<old-branch>] <new-branch>
git branch (-c|-C) [<old-branch>] <new-branch>
git branch (-d|-D) [-r] <branch-name>...
git branch --edit-description [<branch-name>]
-git branch --delete-merged <branch>...
+git branch [--dry-run] --delete-merged <branch>...
DESCRIPTION
-----------
@@ -226,6 +226,12 @@ A branch whose work has not yet been merged into its upstream is
silently skipped. Delete it with `git branch -D` if you want to
remove it anyway.
+`--dry-run`::
+ With `--delete-merged`, print which branches would be
+ deleted and exit without touching any ref. Useful for
+ sanity-checking a wide pattern like `'origin/*'` before
+ committing to the deletion.
+
`-v`::
`-vv`::
`--verbose`::
diff --git a/builtin/branch.c b/builtin/branch.c
index 942e2297c8..f67d0949fe 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -826,6 +826,7 @@ int cmd_branch(int argc,
int delete = 0, rename = 0, copy = 0, list = 0,
unset_upstream = 0, show_current = 0, edit_description = 0;
int delete_merged = 0;
+ int dry_run = 0;
const char *new_upstream = NULL;
int noncreate_actions = 0;
/* possible options */
@@ -881,6 +882,8 @@ int cmd_branch(int argc,
N_("edit the description for the branch")),
OPT_BOOL(0, "delete-merged", &delete_merged,
N_("delete local branches whose upstream matches <branch> and are merged")),
+ OPT_BOOL(0, "dry-run", &dry_run,
+ N_("with --delete-merged, only print which branches would be deleted")),
OPT__FORCE(&force, N_("force creation, move/rename, deletion"), PARSE_OPT_NOCOMPLETE),
OPT_MERGED(&filter, N_("print only branches that are merged")),
OPT_NO_MERGED(&filter, N_("print only branches that are not merged")),
@@ -943,6 +946,9 @@ int cmd_branch(int argc,
if (noncreate_actions > 1)
usage_with_options(builtin_branch_usage, options);
+ if (dry_run && !delete_merged)
+ die(_("--dry-run requires --delete-merged"));
+
if (recurse_submodules_explicit) {
if (!submodule_propagate_branches)
die(_("branch with --recurse-submodules can only be used if submodule.propagateBranches is enabled"));
@@ -983,7 +989,8 @@ int cmd_branch(int argc,
goto out;
} else if (delete_merged) {
ret = delete_merged_branches(argc, argv,
- quiet ? DELETE_BRANCH_QUIET : 0);
+ (quiet ? DELETE_BRANCH_QUIET : 0) |
+ (dry_run ? DELETE_BRANCH_DRY_RUN : 0));
goto out;
} else if (show_current) {
print_current_branch_name();
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index 09cecfaff5..4a71845c76 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -1892,8 +1892,12 @@ test_expect_success '--delete-merged deletes merged branches and spares the rest
) &&
sha=$(git -C repo rev-parse --short merged) &&
- git -C repo branch --delete-merged origin/next >actual 2>&1 &&
+ git -C repo branch --dry-run --delete-merged origin/next >actual 2>&1 &&
+ echo "Would delete branch merged (was $sha)." >expect &&
+ test_cmp expect actual &&
+ git -C repo rev-parse --verify refs/heads/merged &&
+ git -C repo branch --delete-merged origin/next >actual 2>&1 &&
echo "Deleted branch merged (was $sha)." >expect &&
test_cmp expect actual &&
git -C repo for-each-ref --format="%(refname:short)" refs/heads/ >actual &&
@@ -1970,4 +1974,9 @@ test_expect_success "branch -d still deletes a deleteMerged=false branch" '
test_must_fail git -C repo rev-parse --verify refs/heads/kept
'
+test_expect_success '--dry-run without --delete-merged is rejected' '
+ test_must_fail git -C forked branch --dry-run 2>err &&
+ test_grep "requires --delete-merged" err
+'
+
test_done
--
gitgitgadget
^ permalink raw reply related
* [PATCH v16 6/7] branch: add branch.<name>.deleteMerged opt-out
From: Harald Nordgren via GitGitGadget @ 2026-06-18 19:25 UTC (permalink / raw)
To: git
Cc: Kristoffer Haugsbakk, Johannes Sixt, Phillip Wood,
Harald Nordgren, Harald Nordgren
In-Reply-To: <pull.2285.v16.git.git.1781810729.gitgitgadget@gmail.com>
From: Harald Nordgren <haraldnordgren@gmail.com>
Setting branch.<name>.deleteMerged=false exempts that branch from
"git branch --delete-merged", which is useful for a topic you want
to keep developing after an early round of it has been merged
upstream. Unless --quiet is given, each skip is reported so the
user knows why their topic was kept.
Explicit deletion with "git branch -d" still uses the normal merge
check and ignores this setting.
Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
---
Documentation/config/branch.adoc | 7 +++++++
Documentation/git-branch.adoc | 5 +++--
builtin/branch.c | 15 +++++++++++++++
t/t3200-branch.sh | 26 ++++++++++++++++++++++++++
4 files changed, 51 insertions(+), 2 deletions(-)
diff --git a/Documentation/config/branch.adoc b/Documentation/config/branch.adoc
index a4db9fa5c8..d8483acb4f 100644
--- a/Documentation/config/branch.adoc
+++ b/Documentation/config/branch.adoc
@@ -102,3 +102,10 @@ for details).
`git branch --edit-description`. Branch description is
automatically added to the `format-patch` cover letter or
`request-pull` summary.
+
+`branch.<name>.deleteMerged`::
+ If set to `false`, branch _<name>_ is exempt from
+ `git branch --delete-merged`. Useful for a topic branch you
+ intend to develop further after an initial round has been
+ merged upstream. Defaults to true. Explicit deletion via
+ `git branch -d` is unaffected.
diff --git a/Documentation/git-branch.adoc b/Documentation/git-branch.adoc
index f82cfa36d0..91700f2e8a 100644
--- a/Documentation/git-branch.adoc
+++ b/Documentation/git-branch.adoc
@@ -215,10 +215,11 @@ A branch is not deleted when:
+
--
* its upstream remote-tracking branch no longer exists,
-* it is checked out in any worktree, or
+* it is checked out in any worktree,
* its push destination (`<branch>@{push}`) equals its upstream
(`<branch>@{upstream}`), so it cannot be distinguished from a
- branch that just looks "fully merged" right after a pull.
+ branch that just looks "fully merged" right after a pull, or
+* `branch.<name>.deleteMerged` is set to `false`.
--
+
A branch whose work has not yet been merged into its upstream is
diff --git a/builtin/branch.c b/builtin/branch.c
index e7e4f1d27f..942e2297c8 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -722,6 +722,8 @@ static int delete_merged_branches(int argc, const char **argv,
struct ref_filter filter = REF_FILTER_INIT;
struct ref_array candidates = { 0 };
struct strvec deletable = STRVEC_INIT;
+ struct strbuf key = STRBUF_INIT;
+ bool quiet = flags & DELETE_BRANCH_QUIET;
int i, ret = 0;
if (!argc)
@@ -739,6 +741,7 @@ static int delete_merged_branches(int argc, const char **argv,
const char *short_name;
struct branch *branch;
const char *upstream, *push;
+ int opt_out;
if (!skip_prefix(full_name, "refs/heads/", &short_name))
BUG("filter returned non-branch ref '%s'", full_name);
@@ -753,6 +756,17 @@ static int delete_merged_branches(int argc, const char **argv,
if (!push || !strcmp(push, upstream))
continue;
+ strbuf_reset(&key);
+ strbuf_addf(&key, "branch.%s.deletemerged", short_name);
+ if (!repo_config_get_bool(the_repository, key.buf, &opt_out) &&
+ !opt_out) {
+ if (!quiet)
+ fprintf(stderr,
+ _("Skipping '%s' (branch.%s.deleteMerged is false)\n"),
+ short_name, short_name);
+ continue;
+ }
+
strvec_push(&deletable, short_name);
}
@@ -763,6 +777,7 @@ static int delete_merged_branches(int argc, const char **argv,
DELETE_BRANCH_NO_HEAD_FALLBACK |
flags);
+ strbuf_release(&key);
strvec_clear(&deletable);
ref_array_clear(&candidates);
ref_filter_clear(&filter);
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index 609a67bb5a..09cecfaff5 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -1944,4 +1944,30 @@ test_expect_success '--delete-merged requires at least one <branch>' '
test_grep "requires at least one <branch>" err
'
+test_expect_success '--delete-merged honours branch.<name>.deleteMerged=false' '
+ test_when_finished "rm -rf repo" &&
+ setup_repo_for_delete_merged &&
+ merged_branch deleted origin/next &&
+ merged_branch kept origin/next &&
+ git -C repo config branch.kept.deleteMerged false &&
+ git -C repo checkout --detach &&
+
+ git -C repo branch --delete-merged origin/next 2>err &&
+
+ test_grep "Skipping .kept." err &&
+ test_must_fail git -C repo rev-parse --verify refs/heads/deleted &&
+ git -C repo rev-parse --verify refs/heads/kept
+'
+
+test_expect_success "branch -d still deletes a deleteMerged=false branch" '
+ test_when_finished "rm -rf repo" &&
+ setup_repo_for_delete_merged &&
+ merged_branch kept origin/next &&
+ git -C repo config branch.kept.deleteMerged false &&
+ git -C repo checkout --detach &&
+
+ git -C repo branch -d kept &&
+ test_must_fail git -C repo rev-parse --verify refs/heads/kept
+'
+
test_done
--
gitgitgadget
^ permalink raw reply related
* [PATCH v16 5/7] branch: add --delete-merged <branch>
From: Harald Nordgren via GitGitGadget @ 2026-06-18 19:25 UTC (permalink / raw)
To: git
Cc: Kristoffer Haugsbakk, Johannes Sixt, Phillip Wood,
Harald Nordgren, Harald Nordgren
In-Reply-To: <pull.2285.v16.git.git.1781810729.gitgitgadget@gmail.com>
From: Harald Nordgren <haraldnordgren@gmail.com>
git branch --delete-merged <branch>...
deletes the local branches that "--forked <branch>" would list,
keeping only those whose tip is reachable from their configured
upstream. The work has already landed on the upstream they track,
so the local copy is no longer needed.
Three kinds of branches are not deleted:
* any branch checked out in any worktree
* any branch whose upstream remote-tracking branch no longer
exists, since a missing upstream is not by itself a sign of
integration
* any branch whose push destination equals its upstream
(<branch>@{push} is the same as <branch>@{upstream}), such as
a local "main" that tracks and pushes to "origin/main". Right
after a pull it just looks "fully merged", so it is kept. Only
branches that push somewhere other than their upstream,
typically topics in a fork workflow, are candidates.
A branch whose work is not yet merged into its upstream is silently
skipped, so one unmerged topic does not abort the whole sweep.
Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
---
Documentation/git-branch.adoc | 24 ++++++++
builtin/branch.c | 67 +++++++++++++++++++++-
t/t3200-branch.sh | 105 ++++++++++++++++++++++++++++++++++
3 files changed, 194 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-branch.adoc b/Documentation/git-branch.adoc
index b0d66a6deb..f82cfa36d0 100644
--- a/Documentation/git-branch.adoc
+++ b/Documentation/git-branch.adoc
@@ -25,6 +25,7 @@ git branch (-m|-M) [<old-branch>] <new-branch>
git branch (-c|-C) [<old-branch>] <new-branch>
git branch (-d|-D) [-r] <branch-name>...
git branch --edit-description [<branch-name>]
+git branch --delete-merged <branch>...
DESCRIPTION
-----------
@@ -201,6 +202,29 @@ This option is only applicable in non-verbose mode.
Print the name of the current branch. In detached `HEAD` state,
nothing is printed.
+`--delete-merged <branch>...`::
+ Delete the local branches that `--forked` would list for the
+ given _<branch>_ arguments, but only those whose tip is
+ reachable from their configured upstream. In other words, the
+ work on the branch has already landed on the upstream it
+ tracks, so the local copy is no longer needed. Several
+ _<branch>_ patterns may be given, e.g. `git branch
+ --delete-merged origin/main 'feature*'`.
++
+A branch is not deleted when:
++
+--
+* its upstream remote-tracking branch no longer exists,
+* it is checked out in any worktree, or
+* its push destination (`<branch>@{push}`) equals its upstream
+ (`<branch>@{upstream}`), so it cannot be distinguished from a
+ branch that just looks "fully merged" right after a pull.
+--
++
+A branch whose work has not yet been merged into its upstream is
+silently skipped. Delete it with `git branch -D` if you want to
+remove it anyway.
+
`-v`::
`-vv`::
`--verbose`::
diff --git a/builtin/branch.c b/builtin/branch.c
index 1d3f28e4cb..e7e4f1d27f 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -38,6 +38,7 @@ static const char * const builtin_branch_usage[] = {
N_("git branch [<options>] (-c | -C) [<old-branch>] <new-branch>"),
N_("git branch [<options>] [-r | -a] [--points-at]"),
N_("git branch [<options>] [-r | -a] [--format]"),
+ N_("git branch [<options>] --delete-merged <branch>..."),
NULL
};
@@ -714,6 +715,60 @@ static int parse_opt_forked(const struct option *opt, const char *arg, int unset
return 0;
}
+static int delete_merged_branches(int argc, const char **argv,
+ unsigned int flags)
+{
+ struct ref_store *refs = get_main_ref_store(the_repository);
+ struct ref_filter filter = REF_FILTER_INIT;
+ struct ref_array candidates = { 0 };
+ struct strvec deletable = STRVEC_INIT;
+ int i, ret = 0;
+
+ if (!argc)
+ die(_("--delete-merged requires at least one <branch>"));
+
+ for (i = 0; i < argc; i++)
+ if (ref_filter_forked_add(&filter, argv[i]) < 0)
+ die(_("'%s' is not a valid branch or pattern"), argv[i]);
+
+ filter.kind = FILTER_REFS_BRANCHES;
+ filter_refs(&candidates, &filter, filter.kind);
+
+ for (i = 0; i < candidates.nr; i++) {
+ const char *full_name = candidates.items[i]->refname;
+ const char *short_name;
+ struct branch *branch;
+ const char *upstream, *push;
+
+ if (!skip_prefix(full_name, "refs/heads/", &short_name))
+ BUG("filter returned non-branch ref '%s'", full_name);
+ if (branch_checked_out(full_name))
+ continue;
+
+ branch = branch_get(short_name);
+ upstream = branch_get_upstream(branch, NULL);
+ if (!upstream || !refs_ref_exists(refs, upstream))
+ continue;
+ push = branch_get_push(branch, NULL);
+ if (!push || !strcmp(push, upstream))
+ continue;
+
+ strvec_push(&deletable, short_name);
+ }
+
+ if (deletable.nr)
+ ret = delete_branches(deletable.nr, deletable.v,
+ FILTER_REFS_BRANCHES,
+ DELETE_BRANCH_SKIP_UNMERGED |
+ DELETE_BRANCH_NO_HEAD_FALLBACK |
+ flags);
+
+ strvec_clear(&deletable);
+ ref_array_clear(&candidates);
+ ref_filter_clear(&filter);
+ return ret;
+}
+
static GIT_PATH_FUNC(edit_description, "EDIT_DESCRIPTION")
static int edit_branch_description(const char *branch_name)
@@ -755,6 +810,7 @@ int cmd_branch(int argc,
/* possible actions */
int delete = 0, rename = 0, copy = 0, list = 0,
unset_upstream = 0, show_current = 0, edit_description = 0;
+ int delete_merged = 0;
const char *new_upstream = NULL;
int noncreate_actions = 0;
/* possible options */
@@ -808,6 +864,8 @@ int cmd_branch(int argc,
OPT_BOOL(0, "create-reflog", &reflog, N_("create the branch's reflog")),
OPT_BOOL(0, "edit-description", &edit_description,
N_("edit the description for the branch")),
+ OPT_BOOL(0, "delete-merged", &delete_merged,
+ N_("delete local branches whose upstream matches <branch> and are merged")),
OPT__FORCE(&force, N_("force creation, move/rename, deletion"), PARSE_OPT_NOCOMPLETE),
OPT_MERGED(&filter, N_("print only branches that are merged")),
OPT_NO_MERGED(&filter, N_("print only branches that are not merged")),
@@ -855,7 +913,8 @@ int cmd_branch(int argc,
0);
if (!delete && !rename && !copy && !edit_description && !new_upstream &&
- !show_current && !unset_upstream && argc == 0)
+ !show_current && !unset_upstream && !delete_merged &&
+ argc == 0)
list = 1;
if (filter.with_commit || filter.no_commit ||
@@ -865,7 +924,7 @@ int cmd_branch(int argc,
noncreate_actions = !!delete + !!rename + !!copy + !!new_upstream +
!!show_current + !!list + !!edit_description +
- !!unset_upstream;
+ !!unset_upstream + !!delete_merged;
if (noncreate_actions > 1)
usage_with_options(builtin_branch_usage, options);
@@ -907,6 +966,10 @@ int cmd_branch(int argc,
(delete > 1 ? DELETE_BRANCH_FORCE : 0) |
(quiet ? DELETE_BRANCH_QUIET : 0));
goto out;
+ } else if (delete_merged) {
+ ret = delete_merged_branches(argc, argv,
+ quiet ? DELETE_BRANCH_QUIET : 0);
+ goto out;
} else if (show_current) {
print_current_branch_name();
ret = 0;
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index 3104c555f6..609a67bb5a 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -1839,4 +1839,109 @@ test_expect_success '--forked narrows a <pattern> argument' '
test_cmp expect actual
'
+test_expect_success '--delete-merged: setup' '
+ git init -b main upstream &&
+ (
+ cd upstream &&
+ test_commit base &&
+ git checkout -b next &&
+ test_commit next-work &&
+ git checkout main
+ ) &&
+ git init -b main other &&
+ test_commit -C other other-base &&
+ git init -b main fork
+'
+
+setup_repo_for_delete_merged () {
+ rm -rf repo &&
+ git clone upstream repo &&
+ (
+ cd repo &&
+ git remote add fork ../fork &&
+ git remote add other ../other &&
+ git config remote.pushDefault fork &&
+ git config push.default current &&
+ git fetch other
+ )
+}
+
+merged_branch () {
+ (
+ cd repo &&
+ git checkout -b "$1" "$2" &&
+ git commit --allow-empty -m "$1 work" &&
+ git push origin "$1:next" &&
+ git fetch origin &&
+ git branch --set-upstream-to="$2" "$1"
+ )
+}
+
+test_expect_success '--delete-merged deletes merged branches and spares the rest' '
+ test_when_finished "rm -rf repo" &&
+ setup_repo_for_delete_merged &&
+ merged_branch merged origin/next &&
+ (
+ cd repo &&
+ git checkout -b unmerged origin/next &&
+ git commit --allow-empty -m "unmerged work" &&
+ git branch --set-upstream-to=origin/next unmerged &&
+ git checkout -b tracks-other other/main &&
+ git branch --set-upstream-to=other/main tracks-other &&
+ git checkout --detach
+ ) &&
+ sha=$(git -C repo rev-parse --short merged) &&
+
+ git -C repo branch --delete-merged origin/next >actual 2>&1 &&
+
+ echo "Deleted branch merged (was $sha)." >expect &&
+ test_cmp expect actual &&
+ git -C repo for-each-ref --format="%(refname:short)" refs/heads/ >actual &&
+ cat >expect <<-\EOF &&
+ main
+ tracks-other
+ unmerged
+ EOF
+ test_cmp expect actual
+'
+
+test_expect_success '--delete-merged deletes merged branches and spares protected ones' '
+ test_when_finished "rm -rf repo" &&
+ setup_repo_for_delete_merged &&
+ merged_branch on-next origin/next &&
+ merged_branch checked-out origin/next &&
+ merged_branch upstream-gone origin/next &&
+ (
+ cd repo &&
+ git checkout -b mainline main &&
+ git checkout -b on-local mainline &&
+ git branch --set-upstream-to=mainline on-local &&
+ git update-ref refs/remotes/origin/topic refs/remotes/origin/next &&
+ git branch --set-upstream-to=origin/topic upstream-gone &&
+ git update-ref -d refs/remotes/origin/topic &&
+ git branch --set-upstream-to=origin/main main &&
+ git config branch.main.pushRemote origin &&
+ git checkout -b tracks-other other/main &&
+ git branch --set-upstream-to=other/main tracks-other &&
+ git checkout checked-out
+ ) &&
+
+ git -C repo branch --delete-merged origin/next mainline &&
+
+ git -C repo for-each-ref --format="%(refname:short)" refs/heads/ >actual &&
+ cat >expect <<-\EOF &&
+ checked-out
+ main
+ mainline
+ tracks-other
+ upstream-gone
+ EOF
+ test_cmp expect actual
+'
+
+test_expect_success '--delete-merged requires at least one <branch>' '
+ test_must_fail git -C forked branch --delete-merged 2>err &&
+ test_grep "requires at least one <branch>" err
+'
+
test_done
--
gitgitgadget
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox