* [PATCH v2 4/5] SubmittingPatches: be consistent with trailer markup
From: kristofferhaugsbakk @ 2026-06-17 20:52 UTC (permalink / raw)
To: git; +Cc: Kristoffer Haugsbakk, Patrick Steinhardt
In-Reply-To: <V2_CV_SubPatches_trailers.9b6@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 4a37bc29f5a..cb2df3cfff6 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 v2 3/5] SubmittingPatches: document Based-on-patch-by trailer
From: kristofferhaugsbakk @ 2026-06-17 20:52 UTC (permalink / raw)
To: git; +Cc: Kristoffer Haugsbakk, Patrick Steinhardt
In-Reply-To: <V2_CV_SubPatches_trailers.9b6@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 38e18982aa2..4a37bc29f5a 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 v2 2/5] SubmittingPatches: discourage common Linux trailers
From: kristofferhaugsbakk @ 2026-06-17 20:52 UTC (permalink / raw)
To: git; +Cc: Kristoffer Haugsbakk, Patrick Steinhardt
In-Reply-To: <V2_CV_SubPatches_trailers.9b6@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 0b12badf86d..38e18982aa2 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 v2 1/5] SubmittingPatches: encourage trailer use for substantial help
From: kristofferhaugsbakk @ 2026-06-17 20:52 UTC (permalink / raw)
To: git; +Cc: Kristoffer Haugsbakk, Patrick Steinhardt
In-Reply-To: <V2_CV_SubPatches_trailers.9b6@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):
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..0b12badf86d 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -443,8 +443,16 @@ 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]]
-If you like, you can put extra trailers at the end:
+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 v2 0/5] SubmittingPatches: update and flesh out trailer sections
From: kristofferhaugsbakk @ 2026-06-17 20:52 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 v1: https://lore.kernel.org/git/CV_SubPatches_trailers.8f3@msgid.xyz/
§ Changes in v2
See the patch Notes for details.
• Improve commit messages
• Drop patch “discuss non-ident trailers”
• https://lore.kernel.org/git/CV_SubPatches_trailers.8f3@msgid.xyz/T/#m53305dbb8c1f19b06be781ee720fc3be875a326d
• Rewrite “note that trailer order matters” to emphasize chronological
order and to also mention it in the DCO section
• See https://lore.kernel.org/git/xmqq8q8mt4eo.fsf@gitster.g/
[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 v1:
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 89542263444..dceeb5a1817 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
@@ -467,8 +471,8 @@ These are the common trailers in use:
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 without a commit message or a
- `Signed-off-by:` and you have picked it up.
+ 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
@@ -478,10 +482,7 @@ These are the common trailers in use:
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. A trailer that credits someone might be more likely
-to be accepted since these are the most common ones. But another kind of
-trailer might be relevant, for example to link to an issue tracker
-belonging to a downstream project that is affected by a bug in Git.
+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
@@ -490,10 +491,11 @@ 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:`.
-Note that these trailers should come before your `Signed-off-by:`
-trailer. You are signing off to the patch as well as the message. This
-also makes it clear who added trailers when multiple people have signed
-off on a patch.
+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)
Range-diff against v1:
1: 366c0f43b71 ! 1: 835eb736f39 SubmittingPatches: encourage trailer use for substantial help
@@ Commit message
contribution”.[2]
Adding trailers is already encouraged, but in the section `send-patches`.
- Let’s replace “If you like” with outright encouragment in this section
+ 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.
@@ Commit message
Now we need to make a heading for `commit-trailers` in order for the
HTML output to make sense.
- At the same, it is important to temper this recommendation to a sign-
- ificant enough contribution; in my experience beginners can be eager
+ 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.
2: c78fb49c245 < -: ----------- SubmittingPatches: discuss non-ident trailers
3: cff069ced4e ! 2: 5a652b8e14d SubmittingPatches: discourage common Linux trailers
@@ Commit message
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 (c.f. the trailer
+ 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
@@ Commit message
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
## Documentation/SubmittingPatches ##
-@@ Documentation/SubmittingPatches: to be accepted since these are the most common ones. But another kind of
- trailer might be relevant, for example to link to an issue tracker
- belonging to a downstream project that is affected by a bug in Git.
+@@ Documentation/SubmittingPatches: 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
4: 278eb2c5d21 ! 3: 5e53999b2e9 SubmittingPatches: document Based-on-patch-by trailer
@@ Documentation/SubmittingPatches: These are the common trailers in use:
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 without a commit message or a
-+ `Signed-off-by:` and you have picked it up.
++ 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
5: 347c72e4e08 = 4: dd47fabe917 SubmittingPatches: be consistent with trailer markup
6: 1c7e9ad8e69 ! 5: 20f04e18cee SubmittingPatches: note that trailer order matters
@@ Metadata
## Commit message ##
SubmittingPatches: note that trailer order matters
- It matters where you put the s-o-b; it should be last. You are signing
- off on the patch as well as the whole message up to that point.
+ 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:
@@ Commit message
Acked-by: The (Late) Reviewer <late@example.org>
Signed-off-by: The Maintainer <m@example.org>
- The the first ack was added by the contributor and the second one was
- added by the maintainer.
+ 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>
## Documentation/SubmittingPatches ##
+@@ Documentation/SubmittingPatches: 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
@@ Documentation/SubmittingPatches: 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:`.
-+Note that these trailers should come before your `Signed-off-by:`
-+trailer. You are signing off to the patch as well as the message. This
-+also makes it clear who added trailers when multiple people have signed
-+off on a patch.
++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)
base-commit: 1ff279f3404a482a83fb04c7457e41ab26884aea
--
2.54.0.22.g9e26862b904
^ permalink raw reply related
* Re: [PATCH v5 2/2] graph: indent visual root in graph
From: Jeff King @ 2026-06-17 20:27 UTC (permalink / raw)
To: Pablo Sabater
Cc: git, ayu.chandekar, chandrapratap3519, christian.couder, gitster,
jltobler, karthik.188, phillip.wood, siddharthasthana31
In-Reply-To: <20260613-ps-pre-commit-indent-v5-2-8d308efea63d@gmail.com>
On Sat, Jun 13, 2026 at 09:09:16PM +0200, Pablo Sabater wrote:
> +/*
> + * Iterates the commits queue searching for the next visible commit, once found
> + * sets visibleness and visual-root flags.
> + * Knowing if the next commit is also a visual root avoids redundant indentations
> + *
> + * NEEDSWORK: The queue is actively being modified by the walker, for each commit
> + * its parents and itself get simplified and their flags set, but for the next
> + * unrelated commit or the grandparents they are not simplified yet, which means
> + * that a commit whose parents are all filtered will not be marked as a visual
> + * root candidate at the lookahead.
> + * This causes the lookahead to fail, failing to set the cascade flag to avoid
> + * redundant indentations.
> + * See 'test_expect_failure' at t4218-log-graph-indentation.sh.
> + */
> +static void graph_peek_next_visible(struct git_graph *graph,
> + struct graph_lookahead_flags *flags)
> +{
> + struct commit_list *cl;
> +
> + flags->is_next_visible = 0;
> + flags->is_next_visual_root = 0;
> + flags->next_has_column = 0;
> +
> + for (cl = graph->revs->commits; cl; cl = cl->next) {
> + if (get_commit_action(graph->revs, cl->item) != commit_show)
> + continue;
> [...]
I have a feeling this may interact badly with the prio-queue introduced
by dd4bc01c0a (revision: use priority queue for non-limited streaming
walks, 2026-05-27). In that commit, get_revision_1() sucks all of the
commits from revs->commits into revs->commit_queue, and then traversal
puts the parents into that queue, not the commits list.
So during the traversal, revs->commits does not hold the complete queue
anymore. I think it does see _some_ commits, since some get placed
directly into revs->commits and then later moved next time
get_revision() is called. But if we instrument the code like this:
diff --git a/graph.c b/graph.c
index e0d1e2a510..8a5f17a089 100644
--- a/graph.c
+++ b/graph.c
@@ -926,6 +926,10 @@ static void graph_peek_next_visible(struct git_graph *graph,
flags->is_next_visual_root = 0;
flags->next_has_column = 0;
+ warning("peeking at visible commits: %d in list, %d in queue",
+ commit_list_count(graph->revs->commits),
+ (int)graph->revs->commit_queue.nr);
+
for (cl = graph->revs->commits; cl; cl = cl->next) {
if (get_commit_action(graph->revs, cl->item) != commit_show)
continue;
and run something like:
./git log --graph --oneline -- Makefile
we can see that we're always considering just one commit, while there
may be dozens or hundreds in the queue.
I'm not sure what the solution is. This function wants to peek ahead in
queue order, possibly through multiple entries. But a heap-based queue
inherently only supports peeking at the first entry.
None of the tests seem to fail, but I'm not sure if that's because I'm
way off base in my analysis, or there's a gap in the test coverage, or
if this case is part of the expect_failure ones mentioned in the
comment.
I noticed because I have another topic which drops the revs->commits
list entirely (and just always uses the queue), which of course doesn't
compile when merged with this (I merge with 'jch' for my daily driver,
which now includes this patch).
-Peff
^ permalink raw reply related
* Re: [PATCH 0/3] config: allow disabling config includes
From: Junio C Hamano @ 2026-06-17 20:22 UTC (permalink / raw)
To: Derrick Stolee; +Cc: Jeff King, Derrick Stolee via GitGitGadget, git
In-Reply-To: <e88c6e7d-1236-4595-9dea-26c33eab6432@gmail.com>
Derrick Stolee <stolee@gmail.com> writes:
> On 6/17/2026 2:53 PM, Junio C Hamano wrote:
>> Derrick Stolee <stolee@gmail.com> writes:
>>
>>> On 6/11/2026 4:39 AM, Jeff King wrote:
>>>> On Tue, Jun 09, 2026 at 08:59:22AM -0400, Derrick Stolee wrote:
>>>
>>>> I'm not sure I entirely understand the problematic case, though. The
>>>> user points to in-repo config (which we already tell people is a bad
>>>> idea), and then that config breaks for some reason? Because the include
>>>> is relative and git is run from another directory?
>>>
>>>>> Or: are we venturing into territory where we don't even want to create a
>>>>> new foot-gun? If there were another way to solve the situation that I'm
>>>>> facing without these risks, then I'd be open to it. Any ideas?
>>>>
>>>> Yeah, the more I think on it, the more it seems like a foot-gun. Like I
>>>> said, I'm not sure I entirely understand the use-case. If you could
>>>> flesh out an example, that might help.
>>> The case I'm struggling with is that our build system has sandboxing
>>> restrictions to make sure the build is deterministic based on a certain
>>> number of inputs. A tool we don't control is calling Git commands and
>>> these users with included config are getting errors because the build
>>> is looking at files in the repo that are not registered as build inputs.
>>>
>>> Files within $SRCROOT/.git/ are ignored as "internal to Git" but when
>>> the users update their config to include other files, this error occurs.
>>>
>>> I'd much rather that this tool doesn't call Git at all, but I'm unable
>>> to make that change to a third-party tool. But this environment variable
>>> would make it possible to disable this behavior. And I'd also rather
>>> that these users don't use includes in this way, but they are using a
>>> checked-in file to share aliases and other quality-of-life things when
>>> a human uses Git, not "critical" settings.
>>>
>>> This series is my attempt to see if we can find a solution that enables
>>> this behavior, but maybe we've found enough concerns with the idea that
>>> we can push back on the users to say "stop doing that."
>>
>> It seems that the thread went dark after this message. Should I
>> take silence as an agreement, and mark the topic as retracted?
>>
>> Thanks for an interesting discussion.
>
> Yes, consider this retracted. I saw you made that note in the What's
> Cooking email so I thought it was understood.
>
> I believe that the risk is not worth the reward here.
Thanks. Will drop.
^ permalink raw reply
* Re: [PATCH 0/3] config: allow disabling config includes
From: Derrick Stolee @ 2026-06-17 20:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Derrick Stolee via GitGitGadget, git
In-Reply-To: <xmqqzf0tuhfm.fsf@gitster.g>
On 6/17/2026 2:53 PM, Junio C Hamano wrote:
> Derrick Stolee <stolee@gmail.com> writes:
>
>> On 6/11/2026 4:39 AM, Jeff King wrote:
>>> On Tue, Jun 09, 2026 at 08:59:22AM -0400, Derrick Stolee wrote:
>>
>>> I'm not sure I entirely understand the problematic case, though. The
>>> user points to in-repo config (which we already tell people is a bad
>>> idea), and then that config breaks for some reason? Because the include
>>> is relative and git is run from another directory?
>>
>>>> Or: are we venturing into territory where we don't even want to create a
>>>> new foot-gun? If there were another way to solve the situation that I'm
>>>> facing without these risks, then I'd be open to it. Any ideas?
>>>
>>> Yeah, the more I think on it, the more it seems like a foot-gun. Like I
>>> said, I'm not sure I entirely understand the use-case. If you could
>>> flesh out an example, that might help.
>> The case I'm struggling with is that our build system has sandboxing
>> restrictions to make sure the build is deterministic based on a certain
>> number of inputs. A tool we don't control is calling Git commands and
>> these users with included config are getting errors because the build
>> is looking at files in the repo that are not registered as build inputs.
>>
>> Files within $SRCROOT/.git/ are ignored as "internal to Git" but when
>> the users update their config to include other files, this error occurs.
>>
>> I'd much rather that this tool doesn't call Git at all, but I'm unable
>> to make that change to a third-party tool. But this environment variable
>> would make it possible to disable this behavior. And I'd also rather
>> that these users don't use includes in this way, but they are using a
>> checked-in file to share aliases and other quality-of-life things when
>> a human uses Git, not "critical" settings.
>>
>> This series is my attempt to see if we can find a solution that enables
>> this behavior, but maybe we've found enough concerns with the idea that
>> we can push back on the users to say "stop doing that."
>
> It seems that the thread went dark after this message. Should I
> take silence as an agreement, and mark the topic as retracted?
>
> Thanks for an interesting discussion.
Yes, consider this retracted. I saw you made that note in the What's
Cooking email so I thought it was understood.
I believe that the risk is not worth the reward here.
Thanks,
-Stolee
^ permalink raw reply
* Re: [PATCH] gitlab-ci: migrate Windows builds away from Chocolatey
From: Justin Tobler @ 2026-06-17 20:03 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
In-Reply-To: <20260615-b4-pks-gitlab-ci-drop-chocolatey-v1-1-51a6e7d5e388@pks.im>
On 26/06/15 02:21PM, Patrick Steinhardt wrote:
> The Windows builds in GitLab CI use Chocolatey to install dependencies.
> Unfortunately, Chocolatey seems to be very unreliable, which causes the
> jobs to fail very regularly. This is a limitation that seems to be
> somewhat known [1]:
>
> As an organization, you want 100% reliability (or at least that
> potential), and you may want full trust and control as well. This is
> something you can get with internally hosted packages, and you are
> unlikely to achieve from use of the Community Package Repository.
>
> So using the Community Package Repository is kind of discouraged in case
> one wants reliability. We _do_ want reliability though, and we cannot
> easily switch to an enterprise license to fix this issue.
Make sense.
> Introduce a new script that downloads and installs dependencies
> directly. This has a couple of benefits:
>
> - We can drop our dependency on Chocolatey completely, thus improving
> reliability.
>
> - We can easily cache the installers.
>
> - We get direct control over the exact versions we install.
Naive question: Do we expect to have to update the pinned versions
often?
> - Installing dependencies is sped up from roundabout 3 minutes to 1
> minute.
Is fetching the dependencides directly just plain faster? Or is this due
to the caching?
> [1]: https://docs.chocolatey.org/en-us/community-repository/community-packages-disclaimer/#summary
>
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
> Hi
>
> I've been quite annoyed recently because our Windows builds in GitLab CI
> are extremely flakey. All of those flakes come from Chocolatey, which is
> why this patch moves away from it.
>
> Thanks!
>
> Patrick
> ---
> .gitlab-ci.yml | 11 ++++++---
> ci/install-dependencies.ps1 | 55 +++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 63 insertions(+), 3 deletions(-)
>
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index e0b9a0d82b..87a5343a94 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -161,11 +161,16 @@ test:mingw64:
> TEST_OUTPUT_DIRECTORY: "C:/Git-Test"
> tags:
> - saas-windows-medium-amd64
> + cache:
> + key:
> + files:
> + - ci/install-dependencies.ps1
> + paths:
> + - .dependencies
Nice that we can cache the installers now.
> before_script:
> - *windows_before_script
> - - choco install -y git meson ninja rust-ms
> - - Import-Module $env:ChocolateyInstall\helpers\chocolateyProfile.psm1
> - - refreshenv
> + - ./ci/install-dependencies.ps1
> + - $env:Path = "C:\Meson;C:\Rust\bin;$env:Path"
I assume Git is already discoverable on the path?
> - New-Item -Path $env:TEST_OUTPUT_DIRECTORY -ItemType Directory
>
> build:msvc-meson:
> diff --git a/ci/install-dependencies.ps1 b/ci/install-dependencies.ps1
> new file mode 100755
> index 0000000000..e3b367fa54
> --- /dev/null
> +++ b/ci/install-dependencies.ps1
> @@ -0,0 +1,55 @@
> +param(
> + [string]$DownloadDirectory = '.dependencies'
> +)
> +
> +$ErrorActionPreference = 'Stop'
> +$ProgressPreference = 'SilentlyContinue'
> +
> +$GitVersion = '2.54.0.windows.1'
> +$MesonVersion = '1.11.0'
> +$RustVersion = '1.96.0'
> +
> +New-Item -Path $DownloadDirectory -ItemType Directory -Force | Out-Null
> +New-Item -Path .git/info -ItemType Directory -Force | Out-Null
> +New-Item -Path .git/info/exclude -ItemType File -Force | Out-Null
> +Add-Content -Path .git/info/exclude -Value "/$DownloadDirectory"
Here we create the ".dependencies" directory and add it to
".git/info/exclude" to be ignored.
> +function Get-Installer {
> + param(
> + [Parameter(Mandatory = $true)][string]$Name,
> + [Parameter(Mandatory = $true)][string]$Url
> + )
> +
> + $path = Join-Path $DownloadDirectory $Name
> + if (-not (Test-Path $path)) {
> + Write-Host "Downloading $Url"
> + Invoke-WebRequest $Url -OutFile $path -TimeoutSec 300
We only download the installer if it is not already cached. Makes sense.
> + }
> + return $path
> +}
> +
> +function Invoke-Installer {
> + param(
> + [Parameter(Mandatory = $true)][string]$FilePath,
> + [Parameter(Mandatory = $true)][string[]]$ArgumentList
> + )
> +
> + Write-Host "Running $FilePath $($ArgumentList -join ' ')"
> + $process = Start-Process -Wait -PassThru -FilePath $FilePath -ArgumentList $ArgumentList
> + if ($process.ExitCode -ne 0) {
> + throw "$FilePath failed with exit code $($process.ExitCode)"
> + }
> +}
> +
> +$gitAssetVersion = $GitVersion -replace '\.windows\.\d+$', ''
> +$gitInstaller = Get-Installer "Git-Installer.exe" `
> + "https://github.com/git-for-windows/git/releases/download/v$GitVersion/PortableGit-$gitAssetVersion-64-bit.7z.exe"
> +Invoke-Installer $gitInstaller @('-y', '-o"C:\Program Files\Git"')
> +
> +$mesonMsi = Get-Installer "meson.msi" `
> + "https://github.com/mesonbuild/meson/releases/download/$MesonVersion/meson-$MesonVersion-64.msi"
> +Invoke-Installer msiexec.exe @('/i', $mesonMsi, 'INSTALLDIR=C:\Meson', '/quiet', '/norestart')
> +
> +$rustMsi = Get-Installer "rust.msi" `
> + "https://static.rust-lang.org/dist/rust-$RustVersion-x86_64-pc-windows-msvc.msi"
> +Invoke-Installer msiexec.exe @('/i', $rustMsi, 'INSTALLDIR=C:\Rust', 'ADDLOCAL=Rustc,Cargo,Std', '/quiet', '/norestart')
Here is actually invoke the helpers to fetch and install the
dependencies. Looks good. I also validated that this job is working on
GitLab CI.
-Justin
^ permalink raw reply
* Re: [PATCH v3 00/11] doc: interpret-trailers: explain key format
From: Kristoffer Haugsbakk @ 2026-06-17 19:45 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Christian Couder, jackmanb, Linus Arver, D. Ben Knoble
In-Reply-To: <xmqqcxxyt4op.fsf@gitster.g>
On Thu, Jun 11, 2026, at 00:24, Junio C Hamano wrote:
>[snip]
>> +A trailer block will be created with only that trailer if a trailer
>> +block does not already exist. Recall that a trailer block needs to be
>> +preceded by a blank line, so a blank line (specifically an empty line)
>> +will be inserted before the new trailer block in that case.
>
> If you want to stress that a line with only whitespaces on it does
> not count as a blank line for the purpose of this paragraph, you can
> consistently say "an empty line" withotu saying "a blank line", and
> you do not need to have "(specifically an empty lline)" there.
Okay, I’ll make it shorter.
It felt too long for a simple concept indeed.
>
>> +More concretely, this is how the new trailer is added: a `<key>=<value>`
>> +or `<key>:<value>` argument given using `--trailer` will be appended
>> +after the existing trailers. The _<key>_ and _<value>_ parts will be
>> +trimmed to remove starting and trailing whitespace, and the resulting
>> +trimmed _<key>_ and _<value>_ will appear in the output like this:
>
> "More concretely" here feels a bit out of place, as the three paragraphs
> we saw so far aren't really progression of the same thing. First we
> saw when a new trailer line is added, second we learned that an
> extra empty line may be added in addition to the new trailer line.
> What we are about to mention is orthogonal: how each trailer line
> would look like. There is no more or less concrete about it.
Yeah, I think I see. I thought this would be continuation into the more
nuts and bolts of it, where we move from discussing the concepts to the
concrete placeholders, so to speak.
I thought I needed a phrase to connect the paragraphs. But now I don’t
think I do. Just dropping that phrase:
Let's consider new trailers added with `--trailer`.
By default, the new trailer will appear at the end of the trailer block.
Also by default, this new trailer will only be added
if the last trailer is different to it.
A trailer block will be created with only that trailer if a trailer
block does not already exist. Recall that a trailer block needs to be
preceded by a blank line, so a blank line (specifically an empty line)
will be inserted before the new trailer block in that case.
This is how the new trailer is added: a `<key>=<value>`
or `<key>:<value>` argument given using `--trailer` will be appended
after the existing trailers. The _<key>_ and _<value>_ parts will be
trimmed to remove starting and trailing whitespace, and the resulting
trimmed _<key>_ and _<value>_ will appear in the output like this:
And it still flows.
>
>> ------------------------------------------------
>> key: value
>> @@ -74,6 +82,16 @@ key: value
>> This means that the trimmed _<key>_ and _<value>_ will be separated by
>> "`:`{nbsp}" (one colon followed by one space).
>>
>> +Existing trailers are extracted from the input by looking for the
>> +trailer block. Concretely, that is a group of one or more lines that (i)
>
> "Concretely, that is a" -> "A trailer block is a".
Yeah. That seems simpler.
Replacing “that” with what it represents, namely “A trailer block”.
Sometimes just repeating the noun can feel stuttery, like the sentences
don’t flow. But there is enough variation here; the previous sentence
ends with “the trailer block” (definitive), and the next sentence takes
a step back and talks about the indefinitive (a trailer block).
>
>> +is all trailers, or (ii) contains at least one Git-generated or
>> +user-configured trailer and consists of at
>> +least 25% trailers.
>
> Hmph, isn't (i) a narrow subset of (ii)?
Well, this text modulo a grammatical fix goes back all the way to the
implementation of the 25% rule in 14624506 (trailer: allow non-trailers
in trailer block, 2016-10-21).
But I don’t see how either one is a subset of the other. With (i) I just
need valid trailers. With (ii) I need at least one “Git-generated”
trailer (or `(cherry picked from` I think), i.e. as soon as a
non-trailer line has infected the prospective block.
You could have respectively:
i. Only trailers but none are configured
ii. One configured trailer and one comment line
I don’t see how one can subsume the other.
>
>> +The trailer block is by definition at the end the the message. The end
>> +of the message in turn is either (i) at the end of the input, or (ii)
>
> "at the end the the message" -> "at the end of the commit log
> message", and "the input" -> "the message", probably.
Okay, there is both a “the the” as well as missing “of”.
As to “*commit* message”: my first instinct was that the text might as
well talk about just “message” throughout, since we establish at the
beginning that a commit message is *one* application (and the main one)
but isn’t necessarily the only one (tag messages these days, in
fact). But now I see that we already use “commit message” throughout, so
it is indeed best to stick with that here.
> The latter is because not everybody is "parsing" the message to futz
> with trailers, using the message as "input", and some are "writing
> out" the message, using it as "output".
I don’t understand this part. This is supposed to be prosaic. The input
is the data on the standard input. And of that data the message is a
subset, for example and probably most notably with the
git-format-patch(1) format.
Now, we could define what “the commit message” is in terms of “the
message”. But those terms are so close, it might look like you are
restating “commit message” but just dropping “commit” because it is
clear from context now.
For comparison this is the paragraph on `master` (commit 0fae78c9).
Existing trailers are extracted from the input by looking for
a group of one or more lines that (i) is all trailers, or (ii) contains at
least one Git-generated or user-configured trailer and consists of at
least 25% trailers.
The group must be preceded by one or more empty (or whitespace-only) lines.
The group must either be at the end of the input or be the last
non-whitespace lines before a line that starts with `---` (followed by a
space or the end of the line).
>> +the last non-whitespace lines before a line that starts with `---`
>> +(followed by a space or the end of the line).
>
> OK.
^ permalink raw reply
* Re: [PATCH 2/6] SubmittingPatches: discuss non-ident trailers
From: Kristoffer Haugsbakk @ 2026-06-17 19:43 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
In-Reply-To: <ajJNjOYMVDwL52zY@pks.im>
On Wed, Jun 17, 2026, at 09:32, Patrick Steinhardt wrote:
> On Tue, Jun 16, 2026 at 10:02:46PM +0200, Kristoffer Haugsbakk wrote:
>> On Fri, Jun 12, 2026, at 13:35, Patrick Steinhardt wrote:
>> >>[snip]
>> >
>> > Hm, I wonder whether this is a bit too vague to really be helpful for a
>> > newcomer. Instead of alluding to such trailers, wouldn't it be
>> > preferable if we added those as actual examples to the list of known
>> > trailers and then tell folks that they can invent their own ones if
>> > there is a good reason to do so?
>>
>> Honestly there are so few non-ident trailers that I don’t think they can
>> be listed as common trailers:
>>
>> 1. The Git project doesn’t need them (e.g. no bug tracker)
>> 2. They seem mostly for use by other projects (bug trackers again)
>>
>> With this list:
>>
>> git log --format='%(trailers:only,keyonly)' | sort | uniq
>>
>> If you filter out the ident-looking ones:
>>
>> grep -v --extended-regexp -- '-[Bb]y$'
>>
>> There are few left. And some can be discarded:
>>
>> • Change-Id
>> • Message-ID
>> • Fixes (pointing to a commit)
>>
>> So to address your point:
>>
>> 1. Maybe this is so niche that it is not worth mentioning; or
>> 2. Maybe give a concrete example like `Closes: <bug link>`?
>
> Well, we don't use "Closes:" trailers, either. So I'd rather side with
> your (1) and just not mention them at all.
Yeah, I think this can just be dropped. Thanks.
^ permalink raw reply
* Re: [PATCH v13 0/2] checkout: --track=fetch
From: Junio C Hamano @ 2026-06-17 19:15 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget
Cc: git, Ramsay Jones, D. Ben Knoble, Kristoffer Haugsbakk,
Marc Branchaud, Phillip Wood, Harald Nordgren
In-Reply-To: <pull.2281.v13.git.git.1779565714.gitgitgadget@gmail.com>
"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
> * Create a preparatory commit that exposes find_tracking_remote_for_ref()
> and advise_ambiguous_fetch_refspec() from branch.c, so checkout can reuse
> the same lookup git branch --track uses.
> * Use advise_ambiguous_fetch_refspec() for the "multiple remotes match"
> case, so the wording matches git branch --track.
>
> Harald Nordgren (2):
> branch: expose helpers for finding the remote owning a tracking ref
> checkout: extend --track with a "fetch" mode to refresh start-point
>
> Documentation/git-checkout.adoc | 17 +-
> Documentation/git-switch.adoc | 5 +-
> branch.c | 96 ++++++-----
> branch.h | 16 ++
> builtin/checkout.c | 139 +++++++++++++++-
> t/t7201-co.sh | 276 ++++++++++++++++++++++++++++++++
> 6 files changed, 498 insertions(+), 51 deletions(-)
I was scanning "What's cooking" and this topic was the oldest one
among the ones marked as "Needs review". Nobody seems to have
commented on this iteration.
I am still not convinced that it is a good idea to allow "checkout"
to go to the network and muck with remote-tracking branches. The
remote-tracking branches are meant to give us solid reference
points, and such an on-demand update to move them (which by itself
is not bad) and then use the updated result without first seeing
what it contains (which is the part I disagree with) cannot lead us
to a good place. I suspect that the feature encourages a bad
workflow to our end-users.
Having said all that, the changes since v12, in response to earlier
review comments to avoid duplicating the remote lookup and ambiguity
advice logic, look well executed in this round. This also ensures
consistent error messages and behavior between 'git branch --track'
and 'git checkout --track=fetch'.
IOW, I find the mechanical implementation fairly solid. I am not
sure if we are implementing a good thing, though.
One small thing about [1/2];
diff --git a/branch.h b/branch.h
index 3dc6e2a0ff..0aafa1673f 100644
--- a/branch.h
+++ b/branch.h
@@ -1,9 +1,25 @@
#ifndef BRANCH_H
#define BRANCH_H
+#include "refspec.h"
+#include "string-list.h"
+
struct repository;
struct strbuf;
+struct tracking {
+ struct refspec_item spec;
+ struct string_list *srcs;
+ const char *remote;
+ int matches;
+};
+
+void find_tracking_remote_for_ref(struct tracking *tracking,
+ struct string_list *ambiguous_remotes);
+
+void advise_ambiguous_fetch_refspec(const char *dst,
+ const struct string_list *ambiguous_remotes);
+
As we are not embedding any "string_list" instance into any of our
struct (we only have a pointer to a struct), unlike the way we embed
"struct refspec_item" that requires us to include "refspec.h", we do
not need to include "string-list.h". Instead, we only need to
declare "struct string_list", just like we declare repository and
strbuf.
diff --git i/branch.h w/branch.h
index 0aafa1673f..c2e6725491 100644
--- i/branch.h
+++ w/branch.h
@@ -2,8 +2,8 @@
#define BRANCH_H
#include "refspec.h"
-#include "string-list.h"
+struct string_list;
struct repository;
struct strbuf;
^ permalink raw reply related
* Re: [PATCH v15 0/7] branch: delete-merged
From: Harald Nordgren @ 2026-06-17 19:11 UTC (permalink / raw)
To: phillip.wood
Cc: Harald Nordgren via GitGitGadget, git, Kristoffer Haugsbakk,
Johannes Sixt
In-Reply-To: <5829103e-d357-4880-b295-fa0d9f4a2c62@gmail.com>
> Right but you sent that version a few hours after I'd posted a partial
> review which concluded by saying I'd finish it the next day. If you send
> a new version when you are waiting for further comments it clutters the
> list because you know you're going to have to post another revision when
> you get the rest of the comments. Anyone reviewing the interim version
> is wasting their time. When you receive review comments, by all means
> start thinking about them and updating your local copy but please don't
> post a new version until the discussion on the previous version has
> settled down.
That's fair. Sorry about that.
Will you let me know when your review here is finished?
I received the same feedback from Junio before, so I'm not unaware of
this problem. I am trying to slow down. I often prepare the work as
soon as I get some comments -- I'm on paternity leave so I have a lot
of time when the baby is sleeping -- then I actively hold off on
sending to not overload the rest of you. But at the same time I think
it's valuable to keep up a certain pace. It's a balancing act.
Harald
^ permalink raw reply
* Re: [PATCH 0/3] config: allow disabling config includes
From: Junio C Hamano @ 2026-06-17 18:53 UTC (permalink / raw)
To: Derrick Stolee; +Cc: Jeff King, Derrick Stolee via GitGitGadget, git
In-Reply-To: <539713c4-b291-42e6-8541-a16a454518f5@gmail.com>
Derrick Stolee <stolee@gmail.com> writes:
> On 6/11/2026 4:39 AM, Jeff King wrote:
>> On Tue, Jun 09, 2026 at 08:59:22AM -0400, Derrick Stolee wrote:
>
>> I'm not sure I entirely understand the problematic case, though. The
>> user points to in-repo config (which we already tell people is a bad
>> idea), and then that config breaks for some reason? Because the include
>> is relative and git is run from another directory?
>
>>> Or: are we venturing into territory where we don't even want to create a
>>> new foot-gun? If there were another way to solve the situation that I'm
>>> facing without these risks, then I'd be open to it. Any ideas?
>>
>> Yeah, the more I think on it, the more it seems like a foot-gun. Like I
>> said, I'm not sure I entirely understand the use-case. If you could
>> flesh out an example, that might help.
> The case I'm struggling with is that our build system has sandboxing
> restrictions to make sure the build is deterministic based on a certain
> number of inputs. A tool we don't control is calling Git commands and
> these users with included config are getting errors because the build
> is looking at files in the repo that are not registered as build inputs.
>
> Files within $SRCROOT/.git/ are ignored as "internal to Git" but when
> the users update their config to include other files, this error occurs.
>
> I'd much rather that this tool doesn't call Git at all, but I'm unable
> to make that change to a third-party tool. But this environment variable
> would make it possible to disable this behavior. And I'd also rather
> that these users don't use includes in this way, but they are using a
> checked-in file to share aliases and other quality-of-life things when
> a human uses Git, not "critical" settings.
>
> This series is my attempt to see if we can find a solution that enables
> this behavior, but maybe we've found enough concerns with the idea that
> we can push back on the users to say "stop doing that."
It seems that the thread went dark after this message. Should I
take silence as an agreement, and mark the topic as retracted?
Thanks for an interesting discussion.
^ permalink raw reply
* Re: [PATCH v2 7/8] refs: fix recursing `get_main_ref_store()` with "onbranch" config
From: Justin Tobler @ 2026-06-17 18:41 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Karthik Nayak, Jeff King
In-Reply-To: <20260615-b4-pks-refs-avoid-chdir-notify-reparent-v2-7-f4854aa99859@pks.im>
On 26/06/15 03:56PM, Patrick Steinhardt wrote:
[snip]
> diff --git a/refs.c b/refs.c
> index d3caa9a633..e69b9b8ac8 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -2351,15 +2351,31 @@ void ref_store_release(struct ref_store *ref_store)
>
> struct ref_store *get_main_ref_store(struct repository *r)
> {
> + enum ref_storage_format format;
> +
> if (r->refs_private)
> return r->refs_private;
>
> if (!r->gitdir)
> BUG("attempting to get main_ref_store outside of repository");
>
> - r->refs_private = ref_store_init(r, r->ref_storage_format,
> - r->gitdir, REF_STORE_ALL_CAPS);
> + /*
> + * When constructing the reference backend we'll end up reading the Git
> + * configuration. This means we'll also try to evaluate "onbranch"
> + * conditions.
> + *
> + * We cannot read branches when constructing the refdb, so it is not
> + * possible to evaluate those conditions in the first place. To gate
> + * their evaluation we check whether or not the reference storage
> + * format has been configured -- we thus have to temporarily set it to
> + * UNKNOWN here so that we don't end up recursing.
> + */
> + format = r->ref_storage_format;
> + r->ref_storage_format = REF_STORAGE_FORMAT_UNKNOWN;
Is this really the best signal to indicate that a repository ref store
has not been initialized? Temporarily setting the storage format to
REF_STORAGE_FORMAT_UNKNOWN feels rather awkward and suggests to me that
`include_by_branch()` probably shouldn't be using it to begin with if
its not reliable.
-Justin
^ permalink raw reply
* Re: [PATCH v2 6/8] repository: free main reference database
From: Justin Tobler @ 2026-06-17 18:09 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Karthik Nayak, Jeff King
In-Reply-To: <20260615-b4-pks-refs-avoid-chdir-notify-reparent-v2-6-f4854aa99859@pks.im>
On 26/06/15 03:56PM, Patrick Steinhardt wrote:
> While we release worktree and submodule reference databases when
> clearing a repository, we don't ever release the main reference
> database. This memory leak went unnoticed because its pointer is
> kept alive by the "chdir_notify" subsystem.
>
> Fix the memory leak.
>
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
> repository.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/repository.c b/repository.c
> index 187dd471c4..e2b5c6712b 100644
> --- a/repository.c
> +++ b/repository.c
> @@ -421,6 +421,11 @@ void repo_clear(struct repository *repo)
> FREE_AND_NULL(repo->remote_state);
> }
>
> + if (repo->refs_private) {
> + ref_store_release(repo->refs_private);
> + FREE_AND_NULL(repo->refs_private);
> + }
Nice fix. :)
^ permalink raw reply
* Re: [PATCH v2 4/8] refs: unregister reference stores from "chdir_notify"
From: Justin Tobler @ 2026-06-17 18:07 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Karthik Nayak, Jeff King
In-Reply-To: <ajLdIY_fxkKDTBaW@denethor>
On 26/06/17 01:02PM, Justin Tobler wrote:
> On 26/06/15 03:56PM, Patrick Steinhardt wrote:
> > Note that this requires us to use `chdir_notify_register()` instead of
> > `chdir_notify_reparent()`, as there is no infrastructure to unregister the
> > latter. It ultimately doesn't matter much though: in a subsequent commit
> > we'll drop this infrastructure completely. We merely require this step
> > here so that we can fix the memory leaks ahead of time.
>
> Since this version of the series dropped the last patch which stopped
> using `chdir_notify_reparent()`, does the log message here need to be
> updated?
After looking at the next patch, I realized we are referring to just the
`chdir_notify_reparent()` function here which is no longer used. The
current log message makes sense.
-Justin
^ permalink raw reply
* Re: [PATCH v2 4/8] refs: unregister reference stores from "chdir_notify"
From: Justin Tobler @ 2026-06-17 18:02 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Karthik Nayak, Jeff King
In-Reply-To: <20260615-b4-pks-refs-avoid-chdir-notify-reparent-v2-4-f4854aa99859@pks.im>
On 26/06/15 03:56PM, Patrick Steinhardt wrote:
> When creating reference stores we register them with the "chdir_notify"
> subsystem. This is required because some of the paths we track may be
> relative paths, so we have to reparent them in case the current working
> directory changes.
>
> But while we register the reference stores, we never unregister them.
> This can have multiple outcomes:
>
> - For a repository's main reference database we essentially keep the
> pointer alive. We never free that database, either, and our leak
> checker doesn't notice because it's still registered.
>
> - For submodule and worktree reference databases we do eventually free
> them in `repo_clear()`, so we may keep pointers to free'd memory
> registered. We never notice though as we don't tend to chdir around
> in the middle of the process.
>
> We never noticed either of these symptoms, but they are obviously bad.
>
> Partially fix those issues by unregistering the reference stores when
> releasing them. The leak of the main reference database will be fixed in
> a subsequent commit.
>
> Note that this requires us to use `chdir_notify_register()` instead of
> `chdir_notify_reparent()`, as there is no infrastructure to unregister the
> latter. It ultimately doesn't matter much though: in a subsequent commit
> we'll drop this infrastructure completely. We merely require this step
> here so that we can fix the memory leaks ahead of time.
Since this version of the series dropped the last patch which stopped
using `chdir_notify_reparent()`, does the log message here need to be
updated?
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
> refs/files-backend.c | 22 +++++++++++++++++++---
> refs/packed-backend.c | 16 +++++++++++++++-
> refs/reftable-backend.c | 16 +++++++++++++++-
> 3 files changed, 49 insertions(+), 5 deletions(-)
>
> diff --git a/refs/files-backend.c b/refs/files-backend.c
> index a4c7858787..296981584b 100644
> --- a/refs/files-backend.c
> +++ b/refs/files-backend.c
> @@ -100,6 +100,23 @@ static void clear_loose_ref_cache(struct files_ref_store *refs)
> }
> }
>
> +static void files_ref_store_reparent(const char *name UNUSED,
> + const char *old_cwd,
> + const char *new_cwd,
> + void *payload)
> +{
> + struct files_ref_store *refs = payload;
> + char *tmp;
> +
> + tmp = reparent_relative_path(old_cwd, new_cwd, refs->base.gitdir);
> + free(refs->base.gitdir);
> + refs->base.gitdir = tmp;
> +
> + tmp = reparent_relative_path(old_cwd, new_cwd, refs->gitcommondir);
> + free(refs->gitcommondir);
> + refs->gitcommondir = tmp;
> +}
Ok, here is introduce a callback specific to the file ref store to
handle reparenting both the gitdir and commondir.
> /*
> * Create a new submodule ref cache and add it to the internal
> * set of caches.
> @@ -128,9 +145,7 @@ static struct ref_store *files_ref_store_init(struct repository *repo,
>
> repo_config_get_bool(repo, "core.prefersymlinkrefs", &refs->prefer_symlink_refs);
>
> - chdir_notify_reparent("files-backend $GIT_DIR", &refs->base.gitdir);
> - chdir_notify_reparent("files-backend $GIT_COMMONDIR",
> - &refs->gitcommondir);
> + chdir_notify_register(NULL, files_ref_store_reparent, refs);
We use the new callback here instead of relying on the generic callback
used by `chdir_notify_reparent()`.
> strbuf_release(&refdir);
>
> @@ -182,6 +197,7 @@ static void files_ref_store_release(struct ref_store *ref_store)
> free(refs->gitcommondir);
> ref_store_release(refs->packed_ref_store);
> free(refs->packed_ref_store);
> + chdir_notify_unregister(NULL, files_ref_store_reparent, refs);
This allows us to unregister the callback and avoid holding on
references which may have been free'd. Makes sense.
The rest of the patch does the exact same for the packed ref store and
reftable BE which look correct too.
-Justin
^ permalink raw reply
* Re: [PATCH v2 2/2] doc: advise batching patch rerolls
From: Junio C Hamano @ 2026-06-17 17:50 UTC (permalink / raw)
To: Weijie Yuan; +Cc: git, ps
In-Reply-To: <496a08c74ddd9368587d032da7117520af1478ae.1781714757.git.wy@wyuan.org>
Weijie Yuan <wy@wyuan.org> writes:
> +The right timing depends on the topic and the feedback. Larger series usually
> +need more review time. If the only comments so far are minor, such as typo
> +fixes, it often makes sense to wait a little longer in case deeper reviews are
> +still coming.
All sensible up to this point.
> If the comments require substantial rework, sending a new version
> +sooner may save reviewers from spending time on a version you already know will
> +change significantly.
I am not sure about this one. Even though the intention to avoid
wasting reviewers' time spent on reading through the previous
version that will be invalidated is a good one, by definition, a
substantial rework will naturally take time, and it is better not to
rush and send an updated version with substantial changes that you
yourself haven't had a chance to thoroughly review yet.
In such a case, it would be a better idea to respond to the review
that made you realize a substantial rewrite is needed with a simple
"I'll make a substantial rework based on this comment, which would
invalidate this and that part of the current patch series, so please
do not waste reviewer cycles on these parts until I send an updated
series out" message.
> If the topic is close to being accepted and the remaining
> +comments are small, a quicker new version may also be fine.
I am not sure if this needs to be codified.
I often see (e.g., in patches from Patrick) that an iteration is
marked clearly as final candidate that the author is not aware of
any outstanding issues. This encourages reviewers to ask "what
about this one raised there?" to remind what is missed, or chime in
with "yup, this looks good" to show support. Such a note is highly
recommended, but I do not see a need to say "the (supposedly) final
one is specifically allowed to be sent without waiting" even then.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 3/8] setup: don't apply "GIT_REFERENCE_BACKEND" without a repository
From: Justin Tobler @ 2026-06-17 17:43 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Karthik Nayak, Jeff King
In-Reply-To: <20260615-b4-pks-refs-avoid-chdir-notify-reparent-v2-3-f4854aa99859@pks.im>
On 26/06/15 03:56PM, Patrick Steinhardt wrote:
> When discovering a repository we eventually also apply the
> "GIT_REFERENCE_BACKEND" environment variable to the repository. There's
> two problems with that:
>
> - We do this unconditionally, which is rather pointless: we really
> only have to configure the repository when we have found one.
I agree that configuring the repository reference format when there
isn't a repository to begin doesn't sound very useful.
> - We have already applied the repository format at that point in time,
> so we need to manually reapply it.
>
> Move the logic around so that we only apply the environment variable
> when a repository was discovered. This also allows us to drop the
> explcit call to `repo_set_ref_storage_format()` because we now adjust
> the format before we apply it via `apply_repository_format()`.
Make sense.
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
[snip]
> @@ -2023,6 +2022,8 @@ const char *setup_git_directory_gently(struct repository *repo, int *nongit_ok)
> startup_info->have_repository ||
> /* GIT_DIR_EXPLICIT */
> getenv(GIT_DIR_ENVIRONMENT)) {
> + const char *ref_backend_uri;
> +
> if (!repo->gitdir) {
> const char *gitdir = getenv(GIT_DIR_ENVIRONMENT);
> if (!gitdir)
> @@ -2030,6 +2031,24 @@ const char *setup_git_directory_gently(struct repository *repo, int *nongit_ok)
> setup_git_env_internal(repo, gitdir);
> }
>
> + /*
> + * The env variable should override the repository config
> + * for 'extensions.refStorage'.
> + */
> + ref_backend_uri = getenv(GIT_REFERENCE_BACKEND_ENVIRONMENT);
> + if (ref_backend_uri) {
> + char *format;
> +
> + free(repo_fmt.ref_storage_payload);
> +
> + parse_reference_uri(ref_backend_uri, &format, &repo_fmt.ref_storage_payload);
> + repo_fmt.ref_storage_format = ref_storage_format_by_name(format);
> + if (repo_fmt.ref_storage_format == REF_STORAGE_FORMAT_UNKNOWN)
> + die(_("unknown ref storage format: '%s'"), format);
> +
> + free(format);
> + }
> +
> if (startup_info->have_repository) {
> struct strbuf err = STRBUF_INIT;
Hmmm, we only invoke `apply_repository_format()` if we indeed have a
repository (having just GIT_DIR_ENVIRONMENT set isn't enough). Should we
instead nest this logic right above `apply_repository_format()` in the
same block?
-Justin
^ permalink raw reply
* Re: [PATCH v2 2/8] setup: stop applying repository format twice
From: Justin Tobler @ 2026-06-17 17:22 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Karthik Nayak, Jeff King
In-Reply-To: <20260615-b4-pks-refs-avoid-chdir-notify-reparent-v2-2-f4854aa99859@pks.im>
On 26/06/15 03:56PM, Patrick Steinhardt wrote:
> When discovering the repository in "setup.c" we apply the final
> repository format multiple times:
>
> - Once via `repository_format_configure()`, where we apply the hash
> algorithm and ref storage format to both `struct repository_format`
> and `struct repository`.
>
> - And once via `apply_repository_format()`, where we apply these two
> settings from `struct repository_format` to `struct repository`.
>
> With the current flow both of these are in fact necessary. But this is
> only because we call `repository_format_configure()` after we have
> called `apply_repository_format()`. Consequently, if we only changed the
> repository format in `repository_format_configure()` it would never
> propagate to the repository.
Ok, so because `repository_format_configure()` is invoked after the
repository format was already applied, it had to explictly configure the
repository as well.
> Refactor the code so that we first configure the repository format
> before applying it to the repository so that we can stop setting the
> hash and reference storage format multiple times.
Makes sense. Sounds like a good change.
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
> setup.c | 9 ++-------
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/setup.c b/setup.c
> index a9db1f2c23..2748155964 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -2710,8 +2710,7 @@ static int read_default_format_config(const char *key, const char *value,
> return ret;
> }
>
> -static void repository_format_configure(struct repository *repo,
> - struct repository_format *repo_fmt,
> +static void repository_format_configure(struct repository_format *repo_fmt,
> int hash, enum ref_storage_format ref_format)
We now only care about configuring the repository format and will let
`apply_repository_format()` handle setting the repository. Looks good.
[snip]
> @@ -2830,10 +2825,10 @@ int init_db(struct repository *repo,
> * is an attempt to reinitialize new repository with an old tool.
> */
> check_repository_format_gently(repo_get_git_dir(repo), &repo_fmt, NULL);
> + repository_format_configure(&repo_fmt, hash, ref_storage_format);
> if (apply_repository_format(repo, &repo_fmt, APPLY_REPOSITORY_FORMAT_HONOR_ENV, &err) < 0)
> die("%s", err.buf);
> startup_info->have_repository = 1;
> - repository_format_configure(repo, &repo_fmt, hash, ref_storage_format);
`apply_repository_format()` already has the logic to set the hash algo
and ref storage format from the repository format, so change changing
the order here is ok and a good change.
-Justin
^ permalink raw reply
* Re: [PATCH] completion: zsh: support completion after "git -C <path>"
From: Junio C Hamano @ 2026-06-17 17:21 UTC (permalink / raw)
To: Lutz Lengemann via GitGitGadget; +Cc: git, Lutz Lengemann
In-Reply-To: <pull.2155.git.1781710256081.gitgitgadget@gmail.com>
"Lutz Lengemann via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Lutz Lengemann <lutz@lengemann.net>
>
> The zsh completion wrapper (__git_zsh_main) did not handle the global -C
> option, so "git -C <path> <command> <TAB>" offered nothing and could not
> complete a command's arguments.
I do not write, use, or customize zsh, so please take my comments
with huge grains of salt, or just ignore them completely (your
choice) ;-), but one thng I noticed was that ...
> diff --git a/contrib/completion/git-completion.zsh b/contrib/completion/git-completion.zsh
> index c32186a977..323049be8b 100644
> --- a/contrib/completion/git-completion.zsh
> +++ b/contrib/completion/git-completion.zsh
> @@ -227,6 +227,7 @@ __git_zsh_main ()
> '(-p --paginate --no-pager)'{-p,--paginate}'[pipe all output into ''less'']' \
> '(-p --paginate)--no-pager[do not pipe git output into a pager]' \
> '--git-dir=-[set the path to the repository]: :_directories' \
> + '*-C[run as if git was started in <path>]: :_directories' \
> '--bare[treat the repository as a bare repository]' \
> '(- :)--version[prints the git suite version]' \
> '--exec-path=-[path to where your core git programs are installed]:: :_directories' \
... this part talks about not just "-C<dir>" but knows about
all the other options that the "git" potty itself takes, while ...
> @@ -252,6 +253,14 @@ __git_zsh_main ()
> ;;
> (arg)
> local command="${words[1]}" __git_dir __git_cmd_idx=1
> + local -a __git_C_args
> + local -i i=2
> +
> + while [[ ${orig_words[i]} == -C ]]; do
> + __git_C_args+=(-C ${orig_words[i+1]})
> + (( __git_cmd_idx += 2 ))
> + (( i += 2 ))
> + done
... this only knows about "-C<dir>" and nothing else.
Doesn't it want to do something similar to what __git_main in
git-completion.bash does at the beginning, namely, this part?
__git_main ()
{
local i c=1 command __git_dir __git_repo_path
local __git_C_args C_args_count=0
local __git_cmd_idx
while [ $c -lt $cword ]; do
i="${words[c]}"
case "$i" in
--git-dir=*)
__git_dir="${i#--git-dir=}"
;;
--git-dir)
((c++))
__git_dir="${words[c]}"
;;
--bare)
__git_dir="."
;;
--help)
command="help"
break
;;
-c|--work-tree|--namespace)
((c++))
;;
-C)
__git_C_args[C_args_count++]=-C
((c++))
__git_C_args[C_args_count++]="${words[c]}"
;;
-*)
;;
*)
command="$i"
__git_cmd_idx="$c"
break
;;
esac
((c++))
done
^ permalink raw reply
* Re: [PATCH] completion: zsh: support completion after "git -C <path>"
From: Ben Knoble @ 2026-06-17 17:17 UTC (permalink / raw)
To: Lutz Lengemann via GitGitGadget; +Cc: git, Lutz Lengemann
In-Reply-To: <pull.2155.git.1781710256081.gitgitgadget@gmail.com>
I’d like to take a deeper look at this, but I’m not sure when I can.
> Le 17 juin 2026 à 11:37, Lutz Lengemann via GitGitGadget <gitgitgadget@gmail.com> a écrit :
>
> From: Lutz Lengemann <lutz@lengemann.net>
>
> The zsh completion wrapper (__git_zsh_main) did not handle the global -C
> option, so "git -C <path> <command> <TAB>" offered nothing and could not
> complete a command's arguments.
One easy note, though: our commit style prefers describing the code base before the patch in question in the present tense (« does not handle », « offers nothing »).
The below imperative mood looks appropriate to me.
>
> Three things are needed to make it work, all scoped to -C:
>
> - Add -C to the _arguments specification, so completion no longer stops
> at it.
>
> - Advance __git_cmd_idx past any leading "-C <path>" options. The index
> is hard-coded to 1, i.e. the command is assumed to be the first
> argument; with -C present the command sits two words later for each
> -C, so the bash helpers otherwise look at the wrong word and produce
> nothing.
>
> - Collect the -C paths into __git_C_args, as __git_main does. The bash
> helpers run git to resolve aliases and list refs; without the -C
> paths they run in the current directory, so completion fails whenever
> the cwd is not the target repository or the command is an alias.
>
> With these, "git -C <path> <command> <TAB>" completes the command, its
> options and its arguments, including outside the repository, through
> aliases, and with repeated -C options.
>
> Signed-off-by: Lutz Lengemann <lutz@lengemann.net>
> ---
> completion: zsh: support completion after "git -C "
>
> This patch is intentionally scoped to -C, but the underlying problem is
> more general. The zsh wrapper hard-codes __git_cmd_idx=1, i.e. it
> assumes the command is always the first argument. That assumption breaks
> argument completion after any global option that precedes the command,
> not just -C — e.g. --git-dir, --work-tree, --namespace, -c, and
> -p/--paginate. After those, git <opt> <command> <TAB> currently
> completes the command name but not its arguments.
>
> The same approach generalizes cleanly: instead of skipping only leading
> -C options, walk all leading global options and their arguments to
> locate the command and its true index (mirroring the option scan in
> __git_main in git-completion.bash), while collecting -C into
> __git_C_args and --git-dir into __git_dir as today.
>
> I kept this revision narrow for reviewability and because git -C is the
> case where I miss the completion, but I'm happy to extend it to cover
> the other global options in a follow-up (or fold it into this patch) if
> that's preferred.
>
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2155%2Fmobilutz%2Fzsh-complete-global-C-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2155/mobilutz/zsh-complete-global-C-v1
> Pull-Request: https://github.com/gitgitgadget/git/pull/2155
>
> contrib/completion/git-completion.zsh | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/contrib/completion/git-completion.zsh b/contrib/completion/git-completion.zsh
> index c32186a977..323049be8b 100644
> --- a/contrib/completion/git-completion.zsh
> +++ b/contrib/completion/git-completion.zsh
> @@ -227,6 +227,7 @@ __git_zsh_main ()
> '(-p --paginate --no-pager)'{-p,--paginate}'[pipe all output into ''less'']' \
> '(-p --paginate)--no-pager[do not pipe git output into a pager]' \
> '--git-dir=-[set the path to the repository]: :_directories' \
> + '*-C[run as if git was started in <path>]: :_directories' \
> '--bare[treat the repository as a bare repository]' \
> '(- :)--version[prints the git suite version]' \
> '--exec-path=-[path to where your core git programs are installed]:: :_directories' \
> @@ -252,6 +253,14 @@ __git_zsh_main ()
> ;;
> (arg)
> local command="${words[1]}" __git_dir __git_cmd_idx=1
> + local -a __git_C_args
> + local -i i=2
> +
> + while [[ ${orig_words[i]} == -C ]]; do
> + __git_C_args+=(-C ${orig_words[i+1]})
> + (( __git_cmd_idx += 2 ))
> + (( i += 2 ))
> + done
>
> if (( $+opt_args[--bare] )); then
> __git_dir='.'
>
> base-commit: 0fae78c9d55efe705877ea537fe42c59164ccd94
> --
> gitgitgadget
>
^ permalink raw reply
* Re: [PATCH 1/2] environment: move ignore_case into repo_config_values
From: Junio C Hamano @ 2026-06-17 17:16 UTC (permalink / raw)
To: Tian Yuchen
Cc: git, ps, phillip.wood123, johannes.schindelin, stolee,
Christian Couder, Ayush Chandekar, Olamide Caleb Bello
In-Reply-To: <20260617154929.564498-2-cat@malon.dev>
Tian Yuchen <cat@malon.dev> writes:
> Note that the newly introduced getter, 'repo_get_ignore_case()',
> intentionally avoids checking 'repo->gitdir'. This could safely
> accommodates early dynamic probing of the filesystem during
> 'git init' or clone operations, where the 'gitdir' might not be fully
> initialized but the filesystem capability must be recorded.
Why "could"? It either "safely accommodates" or it doesn't.
I do not quite understand the logic behind this part. Why is it OK
to punt until .gitdir is ready for trust-executable-bit, like it is
done in f951ed98 (environment: move trust_executable_bit into
repo_config_values, 2026-06-13)
diff --git a/environment.c b/environment.c
index fc3ed8bb1c..75069a884d 100644
--- a/environment.c
+++ b/environment.c
@@ -142,6 +141,13 @@ int is_bare_repository(void)
return is_bare_repository_cfg && !repo_get_work_tree(the_repository);
}
+int repo_trust_executable_bit(struct repository *repo)
+{
+ return repo->gitdir?
+ repo_config_values(repo)->trust_executable_bit :
+ 1;
+}
+
or hfs/ntfs in 71386c21 (environment: move 'protect_hfs' and
'protect_ntfs' into 'repo_config_values', 2026-06-10)
diff --git a/environment.c b/environment.c
index fc3ed8bb1c..683fe1b4d3 100644
--- a/environment.c
+++ b/environment.c
@@ -142,6 +140,20 @@ int is_bare_repository(void)
return is_bare_repository_cfg && !repo_get_work_tree(the_repository);
}
+int repo_protect_ntfs(struct repository *repo)
+{
+ return repo->gitdir ?
+ repo_config_values(repo)->protect_ntfs :
+ PROTECT_NTFS_DEFAULT;
+}
+
+int repo_protect_hfs(struct repository *repo)
+{
+ return repo->gitdir ?
+ repo_config_values(repo)->protect_hfs :
+ PROTECT_HFS_DEFAULT;
+}
+
int have_git_dir(void)
{
return startup_info->have_repository
but not for this bit?
> +int repo_get_ignore_case(struct repository *repo)
> +{
> + if (repo)
> + return repo_config_values(repo)->ignore_case;
> + return 0;
> +}
What makes ignore-case so special? Doesn't the same logic apply to
the other three bits?
Or use a more direct
if (repo && repo->initialized)
...;
for all three, as repo_config_values(repo) barfs when repo is not
initialized?
I dunno.
^ permalink raw reply related
* [ANNOUNCE] Git v2.55.0-rc1
From: Junio C Hamano @ 2026-06-17 17:16 UTC (permalink / raw)
To: git; +Cc: Linux Kernel, git-packagers
A release candidate Git v2.55.0-rc1 is now available for testing at
the usual places. It is comprised of 460 non-merge commits since
v2.54.0, contributed by 82 people, 27 of which are new faces [*].
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The following public repositories all have a copy of the
'v2.55.0-rc1' tag and the 'master' branch that the tag points at:
url = https://git.kernel.org/pub/scm/git/git
url = https://kernel.googlesource.com/pub/scm/git/git
url = git://repo.or.cz/alt-git.git
url = https://github.com/gitster/git
New contributors whose contributions weren't in v2.54.0 are as follows.
Welcome to the Git development community!
Abhinav Gupta, Aliwoto, Arijit Banerjee, Brandon Chinn, Claude
Sonnet 4.6, David Lin, Ethan Dickson, Hugo Osvaldo Barrera,
Ivan Baluta, Jean-Christophe Manciot, Jonas Rebmann, Kristofer
Karlsson, Kushal Das, Luke Martin, Luna Schwalbe, Matheus Afonso
Martins Moreira, Michael Grossfeld, Owen Stephens, Rob McDonald,
Saagar Jha, Scott Bauersfeld, Scott L. Burson, Sebastien Tardif,
Shardul Natu, Siddh Raman Pant, slonkazoid, and Weijie Yuan.
Returning contributors who helped this release are as follows.
Thanks for your continued support.
Adam Johnson, Adrian Ratiu, Ævar Arnfjörð Bjarmason, Alexander
Monakov, Alyssa Ross, Andrew Kreimer, brian m. carlson,
Christian Couder, D. Ben Knoble, Derrick Stolee, Elijah
Newren, Emily Shaffer, Ezekiel Newren, Ghanshyam Thakkar, Greg
Hurrell, Harald Nordgren, Jacob Keller, Jan Palus, Jayesh Daga,
Jean-Noël Avila, Jeff King, Johannes Schindelin, Johannes Sixt,
Jonatan Holmgren, Junio C Hamano, Justin Tobler, Karthik Nayak,
Kristoffer Haugsbakk, LorenzoPegorari, Lucas Seiki Oshiro,
Mark Levedahl, Matthew John Cheetham, Michael Montalbo, Mirko
Faina, Olamide Caleb Bello, Pablo Sabater, Patrick Steinhardt,
Paul Tarjan, Philippe Blain, Phillip Wood, Pushkar Singh,
Ramsay Jones, René Scharfe, Samo Pogačnik, Shreyansh Paliwal,
Siddharth Asthana, Siddharth Shrimali, SZEDER Gábor, Taylor
Blau, Toon Claes, Torsten Bögershausen, Trieu Huynh, Tuomas
Ahola, Usman Akinyemi, and Zakariyah Ali.
[*] We are counting not just the authorship contribution but issue
reporting, mentoring, helping and reviewing that are recorded in
the commit trailers.
----------------------------------------------------------------
Git v2.55 Release Notes (draft)
===============================
UI, Workflows & Features
------------------------
* Hook scripts defined via the configuration system can now be
configured to run in parallel.
* The userdiff driver for the Scheme language has been extended to
cover other Lisp dialects.
* Terminal control sequences coming over the sideband while talking
to a remote repository are mostly disabled by default, except for
ANSI color escape sequences.
* "ort" merge backend improvements.
* "git checkout -m another-branch" was invented to deal with local
changes to paths that are different between the current and the new
branch, but it gave only one chance to resolve conflicts. The command
was taught to create a stash to save the local changes.
* A new builtin "git format-rev" is introduced for pretty formatting
one revision expression per line or commit object names found in
running text.
* "git history" learned "fixup" command.
* The internal URL parsing logic has been made accessible via a new
subcommand "git url-parse".
* Misspelt proxy URL (e.g., httt://...) did not trigger any warning
or failure, which has been corrected.
* Document the fact that .git/info/exclude is shared across worktrees
linked to the same repository.
* The command line parser for "git diff" learned a few options take
only non-negative integers.
* The graph output from commands like "git log --graph" can now be
limited to a specified number of lanes, preventing overly wide output
in repositories with many branches.
* The fsmonitor daemon has been implemented for Linux.
* "git cat-file --batch" learns an in-line command "mailmap"
that lets the user toggle use of mailmap.
* The "git pack-objects --path-walk" traversal has been integrated
with several object filters, including blobless and sparse filters.
* "git push" learned to take a "remote group" name to push to, which
causes pushes to multiple places, just like "git fetch" would do.
* The 'git-jump' command (in contrib/) has been taught to automatically
pick a mode (merge, diff, or ws) when invoked without arguments.
* The documentation for `push.default = simple` has been clarified to
better explain its behavior, making it clear that it pushes the
current branch to a same-named branch on the remote, and detailing
the upstream requirements for centralized workflows.
* The documentation for "--word-diff" has been extended with a bit of
implementation detail of where these different words come from.
* "git config foo.bar=baz" is not likely to be a request to read the
value of such a variable with '=' in its name; rather it is plausible
that the user meant "git config set foo.bar baz". Give advice when
giving an error message.
* "git rev-list" (and "git log" family of commands) learned a new "--max-count-oldest"
that picks oldest N commits in the range instead of the usual newest.
Performance, Internal Implementation, Development Support etc.
--------------------------------------------------------------
* Promisor remote handling has been refactored and fixed in
preparation for auto-configuration of advertised remotes.
* Rust support is enabled by default (but still allows opting out) in
some future version of Git.
* Preparation of the xdiff/ codebase to work with Rust.
* Use a larger buffer size in the code paths to ingest pack stream.
* Refactor service routines in the ref subsystem backends.
* Shrink wasted memory in Myers diff that does not account for common
prefix and suffix removal.
* Enable expensive tests to catch topics that may cause breakages on
integration branches closer to their origin in the contributor PR
builds.
* "git merge-base" optimization.
* The limit_list() function that is one of the core part of the
revision traversal infrastructure has been optimized by replacing
its use of linear list with priority queue.
* In a lazy clone, "git cherry" and "git grep" often fetch necessary
blob objects one by one from promisor remotes. It has been corrected
to collect necessary object names and fetch them in bulk to gain
reasonable performance.
* The logic to determine that branches in an octopus merge are
independent has been optimized.
* The consistency checks for the files reference backend have been updated
to skip lock files earlier, avoiding unnecessary parsing of
intermediate files.
* The negotiation tip options in "git fetch" have been reworked to
allow requiring certain refs to be sent as "have" lines, and to
restrict negotiation to a specific set of refs.
* The repacking code has been refactored and compaction of MIDX layers
have been implemented, and incremental strategy that does not require
all-into-one repacking has been introduced.
* ODB transaction interface is being reworked to explicitly handle
object writes.
* Add a new odb "in-memory" source that is meant to only hold
tentative objects (like the virtual blob object that represents the
working tree file used by "git blame").
* Many uses of the_repository has been updated to use a more
appropriate struct repository instance in setup.c codepath.
* Revision traversal optimization.
* Build update.
* The logic to lazy-load trees from the commit-graph has been made
more robust by falling back to reading the commit object when
the commit-graph is no longer available.
* The "name" argument in git_connect() and related functions has been
converted to a "service" enum to improve type safety and clarify its
purpose.
* 'git restore --staged' has been optimized to avoid unnecessarily expanding
the sparse index when operating on paths within the sparse checkout
definition, by handling sparse directory entries at the tree level.
* "git stash -p" has been optimized by reusing cached index
entries in its temporary index, avoiding unnecessary lstat()
calls on unchanged files.
* The check for non-stale commits in the priority queue used by
`paint_down_to_common` and `ahead_behind` has been optimized by
replacing an O(N) scan with an O(1) counter, yielding performance
improvements in repositories with wide histories.
* Reachability bitmap generation has been significantly optimized. By
reordering tree traversal, caching object positions, and refining how
pseudo-merge bitmaps are constructed, the performance of "git repack
--write-midx-bitmaps" is improved, especially for large repositories
and when using pseudo-merges.
* Adding a decimal integer with strbuf_addf("%u") appears commonly;
they have been optimized by using a custom formatter.
* Formatting object name in full hexadecimal form has been optimized
by using a new strbuf_add_oid_hex() helper function.
* Encourage original authors to monitor the CI status.
* The `git log -L` implementation has been refactored to use the
standard diff output pipeline, enabling pickaxe and diff-filter to
work as expected. Additionally, metadata-only diff formats like
--raw and --name-only are now supported with -L.
* The loose object source has been refactored into a proper `struct
odb_source`.
* Guidelines on how to write a cover letter for a multi-patch series
have been added to SubmittingPatches, which also got a new marker
to separate the section for typofixes.
* The setup logic to discover and configure repositories has been
refactored, and the initialization of the object database has been
centralized.
* Many core configuration variables have been migrated from global
variables into 'repo_config_values' to tie them to a specific
repository instance, avoiding cross-repository state leakage.
* Streaming revision walks have been optimized by using a priority queue
for date-sorting commits, speeding up walks repositories with many
merges.
* A recent regression in t7527 that broke TAP output has been fixed,
some other test noise that also broke TAP output has been silenced,
and 'prove' is now configured to fail on invalid TAP output to
prevent future regressions.
* A handful of inappropriate uses of the_repository have been
rewritten to use the right repository structure instance in the
unpack-trees.c codepath.
* "git index-pack" has been optimized by retaining child bases in the
delta cache instead of immediately freeing them, letting the existing
cache limit policy decide eviction.
Fixes since v2.54
-----------------
* Code clean-up to use the right instance of a repository instance in
calls inside refs subsystem.
(merge 57c590feb9 sp/refs-reduce-the-repository later to maint).
* The check that implements the logic to see if an in-core cache-tree
is fully ready to write out a tree object was broken, which has
been corrected.
(merge 521731213c dl/cache-tree-fully-valid-fix later to maint).
* The test suite harness and many individual test scripts have been
updated to work correctly when 'set -e' is in effect, which helps
detect misspelled test commands.
(merge ffe8005b9d ps/test-set-e-clean later to maint).
* Revert a recent change that introduced a regression to help mksh users.
* Update various GitHub Actions versions.
* Avoid hitting the pathname limit for socks proxy socket during the
test..
* To help Windows 10 installations, avoid removing files whose
contents are still mmap()'ed.
* The 'git backfill' command now rejects revision-limiting options that
are incompatible with its operation, uses standard documentation for
revision ranges, and includes blobs from boundary commits by default
to improve performance of subsequent operations.
(merge a1ad4a0fca en/backfill-fixes-and-edges later to maint).
* "git grep" update.
(merge 9ff4b5ab1b rs/grep-column-only-match-fix later to maint).
* Headers from glibc 2.43 when used with clang does not allow
disabling C11 language features, causing build failures..
* The 'http.emptyAuth=auto' configuration now correctly attempts
Negotiate authentication before falling back to manual credentials.
This allows seamless Kerberos ticket-based authentication without
requiring users to explicitly set 'http.emptyAuth=true'.
(merge 4919938d28 mc/http-emptyauth-negotiate-fix later to maint).
* Ramifications of turning off commit-graph has been documented a bit
more clearly.
(merge 48c855bb8f kh/doc-commit-graph later to maint).
* "git rebase --update-refs", when used with an rebase.instructionFormat
with "%d" (describe) in it, tried to update local branch HEAD by
mistake, which has been corrected.
(merge 106b6885c7 ag/rebase-update-refs-limit-to-branches later to maint).
* Tweak the way how sideband messages from remote are printed while
we talk with a remote repository to avoid tickling terminal
emulator glitches.
(merge 31e8fcabd8 rs/sideband-clear-line-before-print later to maint).
* The configuration variable submodule.fetchJobs was not read correctly,
which has been corrected.
(merge aa45a5902f sj/submodule-update-clone-config-fix later to maint).
* Update code paths that assumed "unsigned long" was long enough for
"size_t".
(merge 7a094d68a2 js/objects-larger-than-4gb-on-windows later to maint).
* Stop using unmaintained custom allocator in Windows build which was
the last user of the code.
* The computation to shorten the filenames shown in diffstat measured
width of individual UTF-8 characters to add up, but forgot to take
into account error cases (e.g., an invalid UTF-8 sequence, or a
control character).
(merge 09d86a3b98 en/diffstat-utf8-truncation-fix later to maint).
* Some tests assume that bare repository accesses are by default
allowed; rewrite some of them to avoid the assumption, rewrite
others to explicitly set safe.bareRepository to allow them.
(merge 985b38ca6c js/adjust-tests-to-explicitly-access-bare-repo later to maint).
* Signing commit with custom encoding was passing the data to be
signed at a wrong stage in the pipeline, which has been corrected.
(merge 7735d7eee3 bc/sign-commit-with-custom-encoding later to maint).
* Further update to the i18n alias support to avoid regressions.
* "git fetch --deepen=<n>" in a full clone truncated the history to <n>
commits deep, which has been corrected to be a no-op instead.
(merge 2431f5e0e5 sp/shallow-deepen-on-non-shallow-repo-fix later to maint).
* "git maintenance" that goes background did not use the lockfile to
prevent multiple maintenance processes from running at the same
time, which has been corrected.
(merge 29364f1624 ps/maintenance-daemonize-lockfix later to maint).
* Remove ineffective strbuf presizing that would have computed an
allocation that would not have fit in the available memory anyway,
or too small due to integer wraparound to cause immediate automatic
growing.
(merge a9ce8526dc jk/pretty-no-strbuf-presizing later to maint).
* The HTTP walker misinterpreted the alternates file that gives an
absolute path when the server URL does not have the final slash
(i.e., "https://example.com" not "https://example.com/").
(merge b92387cd55 jk/dumb-http-alternate-fix later to maint).
* "git bisect" now uses the selected terms (e.g., old/new) more
consistently in its output.
(merge cb55991825 jr/bisect-custom-terms-in-output later to maint).
* Update GitLab CI jobs that exercise macOS.
(merge 62319b49bb ps/gitlab-ci-macOS-improvements later to maint).
* "Friday noon" asked in the morning on Sunday was parsed to be one
day before the specified time, which has been corrected.
(merge b809304101 ta/approxidate-noon-fix later to maint).
* The GIT_WORK_TREE variable prepared to invoke the push-to-checkout
hook was leaking into the environment even when there was no hook
used and broke the default push-to-deploy (i.e., let "git checkout"
update the working tree only when the working tree is clean).
(merge 44d04e4426 ar/receive-pack-worktree-env later to maint).
* A batch of documentation pages has been updated to use the modern
synopsis style.
(merge 2ef248ae45 ja/doc-synopsis-style-again later to maint).
* The "promisor.quiet" configuration variable was not used from
relevant submodules when commands like "grep --recurse-submodules"
triggered a lazy fetch, which has been corrected.
(merge fa1468a1f7 th/promisor-quiet-per-repo later to maint).
* Correct use of sockaddr API in "git daemon".
(merge 422a5bf575 st/daemon-sockaddr-fixes later to maint).
* A memory leak in `fetch_and_setup_pack_index()` when verification of
the downloaded pack index fails has been plugged. Also an obsolete
`unlink()` call on parse failure has been cleaned up.
* In t3070-wildmatch, "via ls-files" test variants with patterns
containing backslash escapes are now skipped on Windows, avoiding 36
test failures caused by pathspec separator conversion.
(merge 8c84e6802c kk/wildmatch-windows-ls-files-prereq later to maint).
* A linker warning on macOS when building with Xcode 16.3 or newer has
been avoided by passing -fno-common to the compiler when a
sufficiently new linker is detected.
(merge 5cd4d0d850 hn/macos-linker-warning later to maint).
* Documentation and tests have been added to clarify that Git's internal
raw timestamp format requires a `@` prefix for values less than
100,000,000 to prevent ambiguity with other formats like YYYYMMDD.
(merge 4018dc29ee ls/doc-raw-timestamp-prefix later to maint).
* Wording used in "format-patch --subject-prefix" documentation
has been improved.
(merge 4a1eb9304a lo/doc-format-patch-subject-prefix later to maint).
* Advanced emulation of kill() used on Windows in GfW has been
upstreamed to improve the symptoms like left-behind .lock files and
that fails to let the child clean-up itself when it gets killed.
(merge 363f1d8b3a js/win-kill-child-more-gently later to maint).
* The 'git describe --contains --all' command has been fixed to
properly honor the '--match' and '--exclude' options by passing
them down to 'git name-rev' with the appropriate reference
prefixes.
(merge 1891707d1b jk/describe-contains-all-match-fix later to maint).
* Various typos, grammatical errors, and duplicated words in both
documentation and code comments have been corrected.
(merge dc6068df67 wy/docs-typofixes later to maint).
* The subprocess handshake during startup has been made gentler by using
packet_read_line_gently() instead of packet_read_line() to prevent the
parent Git process from dying abruptly when a configured subprocess
(e.g., a clean/smudge filter) fails to start.
(merge 061a68e443 mm/subprocess-handshake-fix later to maint).
* Other code cleanup, docfix, build fix, etc.
(merge 80f4b802e9 ja/doc-difftool-synopsis-style later to maint).
(merge b96490241e jc/doc-timestamps-in-stat later to maint).
(merge ef85286e51 ss/t7004-unhide-git-failures later to maint).
(merge 7584d10bc2 mf/format-patch-cover-letter-format-docfix later to maint).
(merge 8547908eb3 pw/rename-to-get-current-worktree later to maint).
(merge 890229b3f3 sg/t6112-unwanted-tilde-expansion-fix later to maint).
(merge ab9753e7bc kh/doc-restore-double-underscores-fix later to maint).
(merge 4a9e097228 za/t2000-modernise-more later to maint).
(merge b635fd0725 kh/doc-log-decorate-list later to maint).
(merge 65ea197dca jk/commit-sign-overflow-fix later to maint).
(merge 3ccb16052a jk/apply-leakfix later to maint).
(merge 5e6e8dc786 tb/pseudo-merge-bugfixes later to maint).
(merge 6d09e798bc pb/doc-diff-format-updates later to maint).
(merge 34a891a2d3 rs/trailer-fold-optim later to maint).
(merge 499f9048e0 ps/t3903-cover-stash-include-untracked later to maint).
(merge b56ab270aa jk/sq-dequote-cleanup later to maint).
(merge 29d9fdcf10 rs/use-builtin-add-overflow-explicitly-on-clang later to maint).
(merge d9982e8290 ed/check-connected-close-err-fd-2.53 later to maint).
(merge 1740cc35d0 ed/check-connected-close-err-fd later to maint).
(merge f4d7eb3d1c sp/doc-range-diff-takes-notes later to maint).
(merge 83e7f3bd2b kh/free-commit-list later to maint).
(merge d1b72b29e9 am/doc-tech-hash-typofix later to maint).
(merge 014c454799 ak/typofixes later to maint).
(merge 522ea8ef7d js/osxkeychain-build-wo-rust later to maint).
----------------------------------------------------------------
Changes since v2.54.0 are as follows:
Abhinav Gupta (2):
rebase: ignore non-branch update-refs
sequencer: remove todo_add_branch_context.commit
Adam Johnson (1):
stash: reuse cached index entries in --patch temporary index
Adrian Ratiu (9):
repository: fix repo_init() memleak due to missing _clear()
config: add a repo_config_get_uint() helper
hook: parse the hook.jobs config
hook: allow pre-push parallel execution
hook: add per-event jobs config
hook: warn when hook.<friendly-name>.jobs is set
hook: move is_known_hook() to hook.c for wider use
hook: add hook.<event>.enabled switch
hook: allow hook.jobs=-1 to use all available CPU cores
Alexander Monakov (1):
doc: fix typo in GIT_ALTERNATE_OBJECT_DIRECTORIES
Aliwoto (1):
http: reject unsupported proxy URL schemes
Alyssa Ross (1):
receive-pack: fix updateInstead with core.worktree
Andrew Kreimer (1):
doc: fix typos via codespell
Arijit Banerjee (1):
index-pack: retain child bases in delta cache
Christian Couder (10):
promisor-remote: try accepted remotes before others in get_direct()
promisor-remote: pass config entry to all_fields_match() directly
promisor-remote: clarify that a remote is ignored
promisor-remote: reject empty name or URL in advertised remote
promisor-remote: refactor should_accept_remote() control flow
promisor-remote: refactor has_control_char()
promisor-remote: refactor accept_from_server()
promisor-remote: keep accepted promisor_info structs alive
promisor-remote: remove the 'accepted' strvec
t5710: use proper file:// URIs for absolute paths
D. Ben Knoble (1):
ignore: note info/exclude lives in GIT_COMMON_DIR, not GIT_DIR
David Lin (1):
cache-tree: fix inverted object existence check in cache_tree_fully_valid
Derrick Stolee (20):
t5516: fix test order flakiness
fetch: add --negotiation-restrict option
transport: rename negotiation_tips
remote: add remote.*.negotiationRestrict config
negotiator: add have_sent() interface
fetch: add --negotiation-include option for negotiation
remote: add remote.*.negotiationInclude config
send-pack: pass negotiation config in push
t5620: make test work with path-walk var
pack-objects: pass --objects with --path-walk
t/perf: add pack-objects filter and path-walk benchmark
path-walk: always emit directly-requested objects
path-walk: support blobless filter
backfill: die on incompatible filter options
path-walk: support blob size limit filter
path-walk: add pl_sparse_trees to control tree pruning
pack-objects: support sparse:oid filter with path-walk
t6601: tag otherwise-unreachable trees
t1092: test 'git restore' with sparse index
restore: avoid sparse index expansion
Elijah Newren (9):
backfill: reject rev-list arguments that do not make sense
backfill: document acceptance of revision-range in more standard manner
backfill: default to grabbing edge blobs too
diff: fix out-of-bounds reads and NULL deref in diffstat UTF-8 truncation
merge-ort: handle cached rename & trivial resolution interaction better
promisor-remote: document caller filtering contract
patch-ids.h: add missing trailing parenthesis in documentation comment
builtin/log: prefetch necessary blobs for `git cherry`
grep: prefetch necessary blobs
Emily Shaffer (3):
hook: allow parallel hook execution
hook: mark non-parallelizable hooks
hook: add -j/--jobs option to git hook run
Ethan Dickson (1):
connected: close err_fd in promisor fast-path
Ezekiel Newren (6):
xdiff/xdl_cleanup_records: delete local recs pointer
xdiff: use unambiguous types in xdl_bogo_sqrt()
xdiff/xdl_cleanup_records: use unambiguous types
xdiff/xdl_cleanup_records: make limits more clear
xdiff/xdl_cleanup_records: make setting action easier to follow
xdiff/xdl_cleanup_records: make execution of action easier to follow
Greg Hurrell (1):
git-jump: pick a mode automatically when invoked without arguments
Harald Nordgren (9):
stash: add --label-ours, --label-theirs, --label-base for apply
sequencer: allow create_autostash to run silently
sequencer: teach autostash apply to take optional conflict marker labels
checkout: rollback lock on early returns in merge_working_tree
checkout -m: autostash when switching branches
config.mak.uname: avoid macOS linker warning on Xcode 16.3+
config: add git_config_key_is_valid() for quiet validation
config: improve diagnostic for "set" with missing value
git-gui: silence install recipes under "make -s"
Ivan Baluta (1):
doc: clarify push.default=simple behavior
Jacob Keller (1):
describe: fix --exclude, --match with --contains and --all
Jayesh Daga (1):
unpack-trees: use repository from index instead of global
Jean-Noël Avila (10):
doc: convert git-difftool manual page to synopsis style
doc: convert git-range-diff manual page to synopsis style
doc: convert git-shortlog manual page to synopsis style
doc: convert git-describe manual page to synopsis style
doc: convert git-bisect to synopsis style
doc: git bisect: clarify the usage of the synopsis vs actual command
doc: convert git-grep synopsis and options to new style
doc: convert git-am synopsis and options to new style
doc: convert git-apply synopsis and options to new style
doc: convert git-imap-send synopsis and options to new style
Jeff King (12):
t1800: test SIGPIPE with parallel hooks
Revert "transport-helper, connect: use clean_on_exit to reap children on abnormal exit"
pretty: drop strbuf pre-sizing from add_rfc2047()
http: handle absolute-path alternates from server root
apply: plug leak on "patch too large" error
commit: handle large commit messages in utf8 verification
quote.h: bump strvec forward declaration to the top
quote: drop sq_dequote_to_argv()
quote: simplify internals of dequoting
connect: use "service" enum for "name" argument
commit: fall back to full read when maybe_tree is NULL
transport-helper: fix typo in BUG() message
Johannes Schindelin (39):
sideband: mask control characters
sideband: introduce an "escape hatch" to allow control characters
sideband: do allow ANSI color sequences by default
sideband: add options to allow more control sequences to be passed through
sideband: offer to configure sanitizing on a per-URL basis
test-lib: allow bare repository access when breaking changes are enabled
t7900: do not let `$HOME/.gitconfig` interfere with XDG tests
t1300: remove global config settings injected by test-lib.sh
t1305: use `--git-dir=.` for bare repo in include cycle test
t5601: restore `.gitconfig` after includeIf test
ls-files tests: filter `.gitconfig` from `--others` output
status tests: filter `.gitconfig` from status output
safe.bareRepository: default to "explicit" with WITH_BREAKING_CHANGES
t5564: use a short path for the SOCKS proxy socket
ci: bump microsoft/setup-msbuild from v2 to v3
ci: bump actions/{upload,download}-artifact to v7 and v8
ci: bump actions/github-script from v8 to v9
ci: bump actions/checkout from v5 to v6
ci: bump git-for-windows/setup-git-for-windows-sdk from v1 to v2
l10n: bump mshick/add-pr-comment from v2 to v3
mingw: optionally use legacy (non-POSIX) delete semantics
maintenance(geometric): do release the `.idx` files before repacking
mingw: stop using nedmalloc
mingw: drop the build-system plumbing for nedmalloc
mingw: remove the vendored compat/nedmalloc/ subtree
index-pack, unpack-objects: use size_t for object size
git-zlib: handle data streams larger than 4GB
odb, packfile: use size_t for streaming object sizes
delta, packfile: use size_t for delta header sizes
test-tool: add a helper to synthesize large packfiles
t5608: add regression test for >4GB object clone
test-tool synthesize: use the unsafe hash for speed
test-tool synthesize: precompute pack for 4 GiB + 1
test-tool synthesize: add precomputed SHA-256 pack for 4 GiB + 1
t5608: mark >4GB tests as EXPENSIVE
ci: run expensive tests on push builds to integration branches
mingw: kill child processes in a gentler way
mingw: really handle SIGINT
osxkeychain: fix build with Rust
Johannes Sixt (2):
userdiff: tighten word-diff test case of the scheme driver
git-gui: remove unnecessary 'cd $_gitworktree' from do_gitk
Jonas Rebmann (3):
bisect: use selected alternate terms in status output
bisect: print bisect terms in single quotes
rev-parse: use selected alternate terms to look up refs
Jonatan Holmgren (1):
alias: restore support for simple dotted aliases
Junio C Hamano (25):
sideband: drop 'default' configuration
CodingGuidelines: st_mtimespec vs st_mtim vs st_mtime
t5551: "GIT_TEST_LONG=Yes make test" is broken
ci: enable EXPENSIVE for contributor builds
Start 2.55 cycle
The second batch
The 3rd batch
The 4th batch
The 5th batch
The 6th batch
Start preparing for 2.54.1
The 7th batch
The 8th batch
SubmittingPatches: proactively monitor GHCI pages
The 9th batch
The 10th batch
The 11th batch
SubmittingPatches: separate typofixes section
SubmittingPatches: describe cover letter
The 12th batch
The 13th batch
Git 2.55-rc0
topic flush before -rc1 (batch 1)
topic flush before -rc1 (batch 2)
Git 2.55-rc1
Justin Tobler (7):
odb: split `struct odb_transaction` into separate header
odb/transaction: use pluggable `begin_transaction()`
odb: update `struct odb_write_stream` read() callback
object-file: remove flags from transaction packfile writes
object-file: avoid fd seekback by checking object size upfront
object-file: generalize packfile writes to use odb_write_stream
odb/transaction: make `write_object_stream()` pluggable
Karthik Nayak (10):
refs: remove unused typedef 'ref_transaction_commit_fn'
refs: introduce `ref_store_init_options`
refs: extract out reflog config to generic layer
refs: return `ref_transaction_error` from `ref_transaction_update()`
update-ref: move `print_rejected_refs()` up
update-ref: handle rejections while adding updates
refs: move object parsing to the generic layer
refs: add peeled object ID to the `ref_update` struct
refs: use peeled tag values in reference backends
refs/files: skip lock files during consistency checks
Kristofer Karlsson (13):
commit-reach: introduce merge_base_flags enum
commit-reach: early exit paint_down_to_common for single merge-base
merge: use repo_in_merge_bases for octopus up-to-date check
revision: use priority queue in limit_list()
commit-reach: use object flags for tips_reachable_from_bases()
t6600: add tests for duplicate tips in tips_reachable_from_bases()
object.h: fix stale entries in object flag allocation table
commit-reach: deduplicate queue entries in paint_down_to_common
commit-reach: replace queue_has_nonstale() scan with O(1) tracking
pack-objects: call release_revisions() after cruft traversal
revision: introduce rev_walk_mode to clarify get_revision_1()
revision: use priority queue for non-limited streaming walks
t3070: skip ls-files tests with backslash patterns on Windows
Kristoffer Haugsbakk (15):
doc: log: fix --decorate description list
doc: log: use the same delimiter in description list
doc: restore: remove double underscore
doc: add caveat about turning off commit-graph
name-rev: wrap both blocks in braces
name-rev: run clang-format before factoring code
name-rev: factor code for sharing with a new command
name-rev: make dedicated --annotate-stdin --name-only test
format-rev: introduce builtin for on-demand pretty formatting
doc: hook: remove stray backtick
doc: hook: consistently capitalize Git
doc: config: include existing git-hook(1) section
doc: hook: don’t self-link via config include
*: replace deprecated free_commit_list
commit: remove deprecated functions
LorenzoPegorari (2):
http: cleanup function fetch_and_setup_pack_index()
http: fix memory leak in fetch_and_setup_pack_index()
Lucas Seiki Oshiro (1):
Documentation: remove redundant 'instead' in --subject-prefix
Luna Schwalbe (1):
doc: document and test `@` prefix for raw timestamps
Mark Levedahl (11):
git-gui: use HEAD as current branch when detached
git-gui: guard set/unset of GIT_DIR and GIT_WORK_TREE
git-gui: do not change global vars in choose_repository::pick
git-gui: use --absolute-git-dir
git-gui: use rev-parse exclusively to find a repository
git-gui: use git rev-parse for worktree discovery
git-gui: simplify [is_bare] to report if a worktree is known
git-gui: try harder to find worktree from gitdir
git-gui: allow specifying path '.' to the browser
git-gui: check browser/blame arguments carefully
git-gui: add gui and pick as explicit subcommands
Matheus Afonso Martins Moreira (8):
connect: rename enum protocol to url_scheme
url: move url_is_local_not_ssh to url.h
url: move scheme detection to URL header/source
url: return URL_SCHEME_UNKNOWN instead of dying
urlmatch: define url_parse function
builtin: create url-parse command
doc: describe the url-parse builtin
t9904: add tests for the new url-parse builtin
Matthew John Cheetham (4):
http: extract http_reauth_prepare() from retry paths
http: attempt Negotiate auth in http.emptyAuth=auto mode
t5563: add tests for http.emptyAuth with Negotiate
doc: clarify http.emptyAuth values
Michael Montalbo (9):
diff: reject negative values for --inter-hunk-context
diff: reject negative values for -U/--unified
xdiff: guard against negative context lengths
parse-options: clarify what "negated" means for PARSE_OPT_NONEG
doc: clarify that --word-diff operates on line-level hunks
revision: move -L setup before output_format-to-diff derivation
line-log: integrate -L output with the standard log-tree pipeline
line-log: allow non-patch diff formats with -L
sub-process: use gentle handshake to avoid die() on startup failure
Mirko Faina (3):
Fix docs for format.commitListFormat
revision.c: implement --max-count-oldest
bash-completions: add --max-count-oldest
Olamide Caleb Bello (8):
environment: move "trust_ctime" into `struct repo_config_values`
environment: move "check_stat" into `struct repo_config_values`
environment: move `zlib_compression_level` into `struct repo_config_values`
environment: move "pack_compression_level" into `struct repo_config_values`
environment: move "precomposed_unicode" into `struct repo_config_values`
environment: move "core_sparse_checkout_cone" into `struct repo_config_values`
environment: move "sparse_expect_files_outside_of_patterns" into `struct repo_config_values`
environment: move "warn_on_object_refname_ambiguity" into `struct repo_config_values`
Pablo Sabater (3):
graph: limit the graph width to a hard-coded max
graph: add --graph-lane-limit option
graph: add truncation mark to capped lanes
Patrick Steinhardt (89):
t: prepare `test_match_signal ()` calls for `set -e`
t: prepare `test_must_fail ()` for `set -e`
t: prepare `stop_git_daemon ()` for `set -e`
t: prepare `git config --unset` calls for `set -e`
t: prepare conditional test execution for `set -e`
t: prepare execution of potentially failing commands for `set -e`
t: prepare `test_when_finished ()`/`test_atexit()` for `set -e`
t0008: silence error in subshell when using `grep -v`
t1301: don't fail in case setfacl(1) doesn't exist or fails
t6002: fix use of `expr` with `set -e`
t9902: fix use of `read` with `set -e`
t: detect errors outside of test cases
replay: allow callers to control what happens with empty commits
builtin/history: generalize function to commit trees
builtin/history: introduce "fixup" subcommand
build: tolerate use of _Generic from glibc 2.43 with Clang
builtin/maintenance: fix locking with "--detach"
run-command: honor "gc.auto" for auto-maintenance
odb: introduce "in-memory" source
odb/source-inmemory: implement `free()` callback
odb: fix unnecessary call to `find_cached_object()`
odb/source-inmemory: implement `read_object_info()` callback
odb/source-inmemory: implement `read_object_stream()` callback
odb/source-inmemory: implement `write_object()` callback
odb/source-inmemory: implement `write_object_stream()` callback
cbtree: allow using arbitrary wrapper structures for nodes
oidtree: add ability to store data
odb/source-inmemory: convert to use oidtree
odb/source-inmemory: implement `for_each_object()` callback
odb/source-inmemory: implement `find_abbrev_len()` callback
odb/source-inmemory: implement `count_objects()` callback
odb/source-inmemory: implement `freshen_object()` callback
odb/source-inmemory: stub out remaining functions
odb: generic in-memory source
t/unit-tests: add tests for the in-memory object source
setup: replace use of `the_repository` in static functions
setup: stop using `the_repository` in `is_inside_git_dir()`
setup: stop using `the_repository` in `is_inside_work_tree()`
setup: stop using `the_repository` in `prefix_path()`
setup: stop using `the_repository` in `path_inside_repo()`
setup: stop using `the_repository` in `verify_filename()`
setup: stop using `the_repository` in `verify_non_filename()`
setup: stop using `the_repository` in `enter_repo()`
setup: stop using `the_repository` in `setup_work_tree()`
setup: stop using `the_repository` in `set_git_work_tree()`
setup: stop using `the_repository` in `setup_git_env()`
setup: stop using `the_repository` in `setup_git_directory_gently()`
setup: stop using `the_repository` in `setup_git_directory()`
setup: stop using `the_repository` in `upgrade_repository_format()`
setup: stop using `the_repository` in `check_repository_format()`
setup: stop using `the_repository` in `initialize_repository_version()`
setup: stop using `the_repository` in `create_reference_database()`
setup: stop using `the_repository` in `init_db()`
gitlab-ci: upgrade macOS runners
gitlab-ci: update macOS image
odb/source-loose: move loose source into "odb/" subsystem
odb/source-loose: store pointer to "files" instead of generic source
odb/source-loose: start converting to a proper `struct odb_source`
odb/source-loose: wire up `reprepare()` callback
odb/source-loose: wire up `close()` callback
odb/source-loose: wire up `read_object_info()` callback
odb/source-loose: wire up `read_object_stream()` callback
odb/source-loose: wire up `for_each_object()` callback
odb/source-loose: wire up `find_abbrev_len()` callback
odb/source-loose: wire up `count_objects()` callback
odb/source-loose: drop `odb_source_loose_has_object()`
odb/source-loose: wire up `freshen_object()` callback
loose: refactor object map to operate on `struct odb_source_loose`
odb/source-loose: wire up `write_object()` callback
object-file: refactor writing objects to use loose source
odb/source-loose: wire up `write_object_stream()` callback
odb/source-loose: stub out remaining callbacks
odb/source-loose: drop pointer to the "files" source
gitlab-ci: rearrange Linux jobs to match GitHub's order
gitlab-ci: add missing Linux jobs
ci: unify Linux images across GitLab and GitHub
t7527: fix broken TAP output
t7810: turn MB_REGEX check into a lazy prereq
t/test-lib: silence EBUSY errors on Windows during test cleanup
t/lib-git-p4: silence output when killing p4d and its watchdog
t: let prove fail when parsing invalid TAP output
t0001: plug test gaps for git-init(1) with GIT_OBJECT_DIRECTORY
setup: drop `setup_git_env()`
setup: deduplicate logic to apply repository format
repository: stop initializing the object database in `repo_set_gitdir()`
setup: stop creating the object database in `setup_git_env()`
setup: stop initializing object database without repository
repository: stop reading loose object map twice on repo init
setup: construct object database in `apply_repository_format()`
Paul Tarjan (13):
t9210, t9211: disable GIT_TEST_SPLIT_INDEX for scalar clone tests
fsmonitor: fix khash memory leak in do_handle_client
fsmonitor: fix hashmap memory leak in fsmonitor_run_daemon
compat/win32: add pthread_cond_timedwait
fsmonitor: use pthread_cond_timedwait for cookie wait
fsmonitor: rename fsm-ipc-darwin.c to fsm-ipc-unix.c
fsmonitor: rename fsm-settings-darwin.c to fsm-settings-unix.c
fsmonitor: implement filesystem change listener for Linux
run-command: add close_fd_above_stderr option
fsmonitor: close inherited file descriptors and detach in daemon
fsmonitor: add timeout to daemon stop command
fsmonitor: add tests for Linux
fsmonitor: convert shown khash to strset in do_handle_client
Philippe Blain (3):
diff-format.adoc: remove mention of diff-tree specific output
diff-format.adoc: 'git diff-files' prints two lines for unmerged files
diff-format.adoc: mode and hash are 0* for unmerged paths from index only
Phillip Wood (5):
worktree: rename get_worktree_from_repository()
xdiff: reduce size of action arrays
xdiff: cleanup xdl_clean_mmatch()
xprepare: simplify error handling
xdiff: reduce the size of array
Pushkar Singh (1):
stash: add coverage for show --include-untracked
René Scharfe (10):
grep: fix --column --only-match for 2nd and later matches
sideband: clear full line when printing remote messages
strbuf: add strbuf_add_uint()
cat-file: use strbuf_add_uint()
ls-files: use strbuf_add_uint()
ls-tree: use strbuf_add_uint()
hex: add and use strbuf_add_oid_hex()
trailer: change strbuf in-place in unfold_value()
strbuf: use st_add3() in strbuf_grow()
use __builtin_add_overflow() in st_add() with Clang
Rob McDonald (1):
gitk: add horizontal scrollbar to the commit list pane
SZEDER Gábor (1):
t6112: avoid tilde expansion
Saagar Jha (1):
submodule-config: fix reading submodule.fetchJobs
Samo Pogačnik (1):
shallow: fix relative deepen on non-shallow repositories
Scott Bauersfeld (1):
index-pack, unpack-objects: increase input buffer from 4 KiB to 128 KiB
Scott L. Burson (1):
userdiff: extend Scheme support to cover other Lisp dialects
Sebastien Tardif (3):
daemon: fix IPv6 address corruption in lookup_hostname()
daemon: fix IPv6 address truncation in ip2str()
daemon: guard NULL REMOTE_PORT in execute() logging
Shreyansh Paliwal (3):
refs: add struct repository parameter in get_files_ref_lock_timeout_ms()
refs: remove the_hash_algo global state
refs/reftable-backend: drop uses of the_repository
Siddh Raman Pant (1):
Documentation/git-range-diff: add missing notes options in synopsis
Siddharth Asthana (1):
cat-file: add mailmap subcommand to --batch-command
Siddharth Shrimali (3):
t7004: drop hardcoded tag count for state verification
t7004: dynamically grab expected state in tests
t7004: avoid subshells to capture git exit codes
Taylor Blau (36):
t/helper: add 'test-tool bitmap write' subcommand
t5333: demonstrate various pseudo-merge bugs
pack-bitmap-write: sort pseudo-merge commit lookup table in pack order
pack-bitmap: fix inverted binary search in `pseudo_merge_at()`
pack-bitmap: fix pseudo-merge lookup for shared commits
pack-bitmap: parse commits in `find_pseudo_merge_group_for_ref()`
pack-bitmap: reject pseudo-merge "sampleRate" of 0
Documentation: fix broken `sampleRate` in gitpacking(7)
pack-bitmap: prevent pattern leak on pseudo-merge re-assignment
midx-write: handle noop writes when converting incremental chains
midx: use `strset` for retained MIDX files
midx: build `keep_hashes` array in order
midx: use `strvec` for `keep_hashes`
midx: introduce `--no-write-chain-file` for incremental MIDX writes
midx: support custom `--base` for incremental MIDX writes
repack: track the ODB source via existing_packs
midx: expose `midx_layer_contains_pack()`
repack-midx: factor out `repack_prepare_midx_command()`
repack-midx: extract `repack_fill_midx_stdin_packs()`
repack-geometry: prepare for incremental MIDX repacking
builtin/repack.c: convert `--write-midx` to an `OPT_CALLBACK`
packfile: ensure `close_pack_revindex()` frees in-memory revindex
repack: implement incremental MIDX repacking
repack: introduce `--write-midx=incremental`
repack: allow `--write-midx=incremental` without `--geometric`
path-walk: support `tree:0` filter
path-walk: support `object:type` filter
path-walk: support `combine` filter
pack-bitmap: pass object position to `fill_bitmap_tree()`
pack-bitmap: check subtree bits before recursing
pack-bitmap: reuse stored selected bitmaps
pack-bitmap: consolidate `find_object_pos()` success path
pack-bitmap: cache object positions during fill
pack-bitmap: sort bitmaps before XORing
pack-bitmap: remember pseudo-merge parents
pack-bitmap: build pseudo-merge bitmaps after regular bitmaps
Toon Claes (1):
generate-configlist: collapse depfile for older Ninja
Trieu Huynh (1):
promisor-remote: fix promisor.quiet to use the correct repository
Tuomas Ahola (5):
approxidate: make "today" wrap to midnight
t0006: add support for approxidate test date adjustment
approxidate: make "specials" respect fixed day-of-month
approxidate: use deferred mday adjustments for "specials"
docs: fix typos
Usman Akinyemi (3):
remote: fix sign-compare warnings in push_cas_option
remote: move remote group resolution to remote.c
push: support pushing to a remote group
Weijie Yuan (1):
docs: fix typos and grammar
Zakariyah Ali (1):
t2000: consolidate second scenario into a single test block
brian m. carlson (6):
docs: update version with default Rust support
ci: install cargo on Alpine
Linux: link against libdl
Enable Rust by default
commit: name UTF-8 function appropriately
commit: sign commit after mutating buffer
^ permalink raw reply
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