* Re: [PATCH] log: let --follow follow renames in merge commits
From: Miklos Vajna @ 2026-05-20 13:28 UTC (permalink / raw)
To: Elijah Newren, Jeff King; +Cc: git
In-Reply-To: <xmqqo6ib7vlp.fsf@gitster.g>
Hi Elijah, Jeff,
On Tue, May 19, 2026 at 03:37:54PM +0900, Junio C Hamano <gitster@pobox.com> wrote:
> > :-) Should I just wait more or should I resend this?
>
> Rather, ask other reviewers
I did a small improvement to how 'git log --follow' works, as in if the
rename happens inside the merge commit itself, then the rename was
detected "vs the first parent", but it wasn't detected "vs other
parents", which is painful with a "subtree" merge commit.
I'm not sure if it adds value, but I can append a one-paragraph summary
of Junio's comment in this thread to the end the commit message, to be
more explicit that the inherent limitation of the current log follow
design (single path, once a rename is detected, we only care about the
new path) is not changed with the patch, this is just a fix patch so
'git log' works better, similar to how 'git blame' already does.
May I ask you to review the patch?
Thanks,
Miklos
^ permalink raw reply
* [PATCH v3] remote: qualify "git pull" advice for non-upstream compareBranches
From: Harald Nordgren via GitGitGadget @ 2026-05-20 13:10 UTC (permalink / raw)
To: git; +Cc: Harald Nordgren, Harald Nordgren
In-Reply-To: <pull.2301.v2.git.git.1778665812261.gitgitgadget@gmail.com>
From: Harald Nordgren <haraldnordgren@gmail.com>
Enable ENABLE_ADVICE_PULL for push-branch comparisons too, not just
the upstream entry, so the "use git pull" hint prints when the local
branch is behind its push branch.
Spell out "git pull <remote> <branch>" so running the suggested
command actually pulls the ref the user was told about; plain
"git pull" would fetch the upstream instead.
Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
---
remote: qualify "git pull" advice for non-upstream branches
* Only suggest git pull <remote> <branch> when plain git pull wouldn't
do the right thing.
* Tests: when upstream and push are the same ref, the message stays
plain git pull.
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2301%2FHaraldNordgren%2Fstatus-pull-advice-qualified-v3
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2301/HaraldNordgren/status-pull-advice-qualified-v3
Pull-Request: https://github.com/git/git/pull/2301
Range-diff vs v2:
1: 1f06873f82 ! 1: 3703be9aac remote: qualify "git pull" advice for non-upstream branches
@@ Metadata
Author: Harald Nordgren <haraldnordgren@gmail.com>
## Commit message ##
- remote: qualify "git pull" advice for non-upstream branches
+ remote: qualify "git pull" advice for non-upstream compareBranches
- When "git status" reports the local branch is behind the push
- branch, the advice suggested a bare "git pull". That follows the
- upstream, which may live on a different remote, so emit
- "git pull <remote> <branch>" instead.
+ Enable ENABLE_ADVICE_PULL for push-branch comparisons too, not just
+ the upstream entry, so the "use git pull" hint prints when the local
+ branch is behind its push branch.
- Also enable the pull advice for push-branch comparisons; it was
- previously only set for the upstream.
+ Spell out "git pull <remote> <branch>" so running the suggested
+ command actually pulls the ref the user was told about; plain
+ "git pull" would fetch the upstream instead.
Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
@@ remote.c: int format_tracking_info(struct branch *branch, struct strbuf *sb,
flags |= ENABLE_ADVICE_DIVERGENCE;
+ if (is_push) {
+ flags |= ENABLE_ADVICE_PUSH;
-+ push_remote_name = pushremote_for_branch(branch, NULL);
-+ if (push_remote_name &&
-+ skip_prefix(full_ref, "refs/remotes/", &push_branch_name) &&
-+ skip_prefix(push_branch_name, push_remote_name, &push_branch_name) &&
-+ *push_branch_name == '/')
-+ push_branch_name++;
-+ else
-+ push_remote_name = NULL;
++ if (!upstream_ref || strcmp(upstream_ref, full_ref)) {
++ push_remote_name = pushremote_for_branch(branch, NULL);
++ if (push_remote_name &&
++ skip_prefix(full_ref, "refs/remotes/", &push_branch_name) &&
++ skip_prefix(push_branch_name, push_remote_name, &push_branch_name) &&
++ *push_branch_name == '/')
++ push_branch_name++;
++ else
++ push_remote_name = NULL;
++ }
+ }
format_branch_comparison(sb, !cmp, ours, theirs, short_ref,
+ push_remote_name, push_branch_name,
@@ t/t6040-tracking-info.sh: test_expect_success 'status.compareBranches with remap
test_cmp expect actual
'
-+test_expect_success 'status.compareBranches with behind push branch suggests qualified pull' '
++test_expect_success 'status.compareBranches behind both upstream and push' '
+ test_config -C test push.default current &&
+ test_config -C test remote.pushDefault origin &&
+ test_config -C test status.compareBranches "@{upstream} @{push}" &&
+ git -C test checkout -b feature13 upstream/main &&
+ (cd test && advance work13) &&
+ git -C test push origin &&
++ git -C test branch --set-upstream-to upstream/ahead &&
+ git -C test reset --hard HEAD^ &&
+ git -C test status >actual &&
+ cat >expect <<-EOF &&
+ On branch feature13
-+ Your branch is up to date with ${SQ}upstream/main${SQ}.
++ Your branch is behind ${SQ}upstream/ahead${SQ} by 1 commit, and can be fast-forwarded.
++ (use "git pull" to update your local branch)
+
+ Your branch is behind ${SQ}origin/feature13${SQ} by 1 commit, and can be fast-forwarded.
+ (use "git pull origin feature13" to update your local branch)
@@ t/t6040-tracking-info.sh: test_expect_success 'status.compareBranches with remap
+ EOF
+ test_cmp expect actual
+'
++
++test_expect_success 'status.compareBranches with behind push branch and no upstream' '
++ test_config -C test push.default current &&
++ test_config -C test remote.pushDefault origin &&
++ test_config -C test status.compareBranches "@{push}" &&
++ git -C test checkout --no-track -b feature15 upstream/main &&
++ (cd test && advance work15) &&
++ git -C test push origin &&
++ git -C test reset --hard HEAD^ &&
++ git -C test status >actual &&
++ cat >expect <<-EOF &&
++ On branch feature15
++ Your branch is behind ${SQ}origin/feature15${SQ} by 1 commit, and can be fast-forwarded.
++ (use "git pull origin feature15" to update your local branch)
++
++ nothing to commit, working tree clean
++ EOF
++ test_cmp expect actual
++'
++
++test_expect_success 'status.compareBranches behind upstream-equals-push suggests plain pull' '
++ test_config -C test status.compareBranches "@{upstream} @{push}" &&
++ git -C test checkout -b feature16 origin/main &&
++ (cd test && advance work16) &&
++ git -C test push origin HEAD:main &&
++ git -C test reset --hard HEAD^ &&
++ git -C test status >actual &&
++ cat >expect <<-EOF &&
++ On branch feature16
++ Your branch is behind ${SQ}origin/main${SQ} by 1 commit, and can be fast-forwarded.
++ (use "git pull" to update your local branch)
++
++ nothing to commit, working tree clean
++ EOF
++ test_cmp expect actual
++'
+
test_done
remote.c | 46 +++++++++++++++++++-----
t/t6040-tracking-info.sh | 78 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 115 insertions(+), 9 deletions(-)
diff --git a/remote.c b/remote.c
index a664cd166a..2b82f6b312 100644
--- a/remote.c
+++ b/remote.c
@@ -2267,6 +2267,8 @@ static void format_branch_comparison(struct strbuf *sb,
bool up_to_date,
int ours, int theirs,
const char *branch_name,
+ const char *push_remote_name,
+ const char *push_branch_name,
enum ahead_behind_flags abf,
unsigned flags)
{
@@ -2302,9 +2304,15 @@ static void format_branch_comparison(struct strbuf *sb,
"and can be fast-forwarded.\n",
theirs),
branch_name, theirs);
- if (use_pull_advice && advice_enabled(ADVICE_STATUS_HINTS))
- strbuf_addstr(sb,
- _(" (use \"git pull\" to update your local branch)\n"));
+ if (use_pull_advice && advice_enabled(ADVICE_STATUS_HINTS)) {
+ if (push_remote_name && push_branch_name)
+ strbuf_addf(sb,
+ _(" (use \"git pull %s %s\" to update your local branch)\n"),
+ push_remote_name, push_branch_name);
+ else
+ strbuf_addstr(sb,
+ _(" (use \"git pull\" to update your local branch)\n"));
+ }
} else {
strbuf_addf(sb,
Q_("Your branch and '%s' have diverged,\n"
@@ -2315,9 +2323,15 @@ static void format_branch_comparison(struct strbuf *sb,
"respectively.\n",
ours + theirs),
branch_name, ours, theirs);
- if (use_divergence_advice && advice_enabled(ADVICE_STATUS_HINTS))
- strbuf_addstr(sb,
- _(" (use \"git pull\" if you want to integrate the remote branch with yours)\n"));
+ if (use_divergence_advice && advice_enabled(ADVICE_STATUS_HINTS)) {
+ if (push_remote_name && push_branch_name)
+ strbuf_addf(sb,
+ _(" (use \"git pull %s %s\" if you want to integrate the remote branch with yours)\n"),
+ push_remote_name, push_branch_name);
+ else
+ strbuf_addstr(sb,
+ _(" (use \"git pull\" if you want to integrate the remote branch with yours)\n"));
+ }
}
}
@@ -2355,6 +2369,8 @@ int format_tracking_info(struct branch *branch, struct strbuf *sb,
int ours, theirs, cmp;
int is_upstream, is_push;
unsigned flags = 0;
+ const char *push_remote_name = NULL;
+ const char *push_branch_name = NULL;
full_ref = resolve_compare_branch(branch,
branches.items[i].string);
@@ -2396,13 +2412,25 @@ int format_tracking_info(struct branch *branch, struct strbuf *sb,
if (reported)
strbuf_addstr(sb, "\n");
- if (is_upstream)
+ if (is_upstream || is_push)
flags |= ENABLE_ADVICE_PULL;
- if (is_push)
- flags |= ENABLE_ADVICE_PUSH;
if (show_divergence_advice && is_upstream)
flags |= ENABLE_ADVICE_DIVERGENCE;
+ if (is_push) {
+ flags |= ENABLE_ADVICE_PUSH;
+ if (!upstream_ref || strcmp(upstream_ref, full_ref)) {
+ push_remote_name = pushremote_for_branch(branch, NULL);
+ if (push_remote_name &&
+ skip_prefix(full_ref, "refs/remotes/", &push_branch_name) &&
+ skip_prefix(push_branch_name, push_remote_name, &push_branch_name) &&
+ *push_branch_name == '/')
+ push_branch_name++;
+ else
+ push_remote_name = NULL;
+ }
+ }
format_branch_comparison(sb, !cmp, ours, theirs, short_ref,
+ push_remote_name, push_branch_name,
abf, flags);
reported = 1;
diff --git a/t/t6040-tracking-info.sh b/t/t6040-tracking-info.sh
index 0242b5bf7a..b613aba33a 100755
--- a/t/t6040-tracking-info.sh
+++ b/t/t6040-tracking-info.sh
@@ -646,4 +646,82 @@ test_expect_success 'status.compareBranches with remapped push and upstream remo
test_cmp expect actual
'
+test_expect_success 'status.compareBranches behind both upstream and push' '
+ test_config -C test push.default current &&
+ test_config -C test remote.pushDefault origin &&
+ test_config -C test status.compareBranches "@{upstream} @{push}" &&
+ git -C test checkout -b feature13 upstream/main &&
+ (cd test && advance work13) &&
+ git -C test push origin &&
+ git -C test branch --set-upstream-to upstream/ahead &&
+ git -C test reset --hard HEAD^ &&
+ git -C test status >actual &&
+ cat >expect <<-EOF &&
+ On branch feature13
+ Your branch is behind ${SQ}upstream/ahead${SQ} by 1 commit, and can be fast-forwarded.
+ (use "git pull" to update your local branch)
+
+ Your branch is behind ${SQ}origin/feature13${SQ} by 1 commit, and can be fast-forwarded.
+ (use "git pull origin feature13" to update your local branch)
+
+ nothing to commit, working tree clean
+ EOF
+ test_cmp expect actual
+'
+
+test_expect_success 'status.compareBranches with remapped push and behind push branch' '
+ test_config -C test remote.pushDefault origin &&
+ test_config -C test remote.origin.push refs/heads/feature14:refs/heads/remapped14 &&
+ test_config -C test status.compareBranches "@{push}" &&
+ git -C test checkout -b feature14 upstream/main &&
+ (cd test && advance work14) &&
+ git -C test push &&
+ git -C test reset --hard HEAD^ &&
+ git -C test status >actual &&
+ cat >expect <<-EOF &&
+ On branch feature14
+ Your branch is behind ${SQ}origin/remapped14${SQ} by 1 commit, and can be fast-forwarded.
+ (use "git pull origin remapped14" to update your local branch)
+
+ nothing to commit, working tree clean
+ EOF
+ test_cmp expect actual
+'
+
+test_expect_success 'status.compareBranches with behind push branch and no upstream' '
+ test_config -C test push.default current &&
+ test_config -C test remote.pushDefault origin &&
+ test_config -C test status.compareBranches "@{push}" &&
+ git -C test checkout --no-track -b feature15 upstream/main &&
+ (cd test && advance work15) &&
+ git -C test push origin &&
+ git -C test reset --hard HEAD^ &&
+ git -C test status >actual &&
+ cat >expect <<-EOF &&
+ On branch feature15
+ Your branch is behind ${SQ}origin/feature15${SQ} by 1 commit, and can be fast-forwarded.
+ (use "git pull origin feature15" to update your local branch)
+
+ nothing to commit, working tree clean
+ EOF
+ test_cmp expect actual
+'
+
+test_expect_success 'status.compareBranches behind upstream-equals-push suggests plain pull' '
+ test_config -C test status.compareBranches "@{upstream} @{push}" &&
+ git -C test checkout -b feature16 origin/main &&
+ (cd test && advance work16) &&
+ git -C test push origin HEAD:main &&
+ git -C test reset --hard HEAD^ &&
+ git -C test status >actual &&
+ cat >expect <<-EOF &&
+ On branch feature16
+ Your branch is behind ${SQ}origin/main${SQ} by 1 commit, and can be fast-forwarded.
+ (use "git pull" to update your local branch)
+
+ nothing to commit, working tree clean
+ EOF
+ test_cmp expect actual
+'
+
test_done
base-commit: 7bcaabddcf68bd0702697da5904c3b68c52f94cf
--
gitgitgadget
^ permalink raw reply related
* [PATCH v2] git-jump: pick a mode automatically when invoked without arguments
From: Greg Hurrell via GitGitGadget @ 2026-05-20 12:31 UTC (permalink / raw)
To: git; +Cc: Jeff King, Greg Hurrell, Erik Cervin Edin, Greg Hurrell,
Greg Hurrell
In-Reply-To: <pull.2108.git.1778231254871.gitgitgadget@gmail.com>
From: Greg Hurrell <greg.hurrell@datadoghq.com>
When `git jump` is invoked with no positional arguments (and no
arguments after `--stdout`) it currently prints usage and exits with
status 1.
But there are several situations where we can usefully infer the most
valuable and likely mode that a user would want to use, and select it
automatically:
1. When there are unmerged paths in the index, the user likely
wants `git jump merge`.
2. When the working tree has unstaged changes, the user likely
wants `git jump diff`.
3. In the presence of conflict markers or whitespace errors (as reported
by `git diff --check`), the user likely wants `git jump ws`.
In this commit we teach `git jump` a new "auto" mode which detects these
cases and dispatches to the corresponding mode automatically. The user
can either explicitly spell out `git jump auto`, or just leave it at
`git jump` (because "auto" is the default).
If none of the interesting cases listed above applies, then auto mode
falls back to the existing usage-and-exit behavior.
Signed-off-by: Greg Hurrell <greg.hurrell@datadoghq.com>
---
git-jump: pick a mode automatically when invoked without arguments
Changes since v0:
* Added explicit "auto" keyword/mode.
* Updated additional detail to usage info and README.
* (Bonus) Added ws usage example to README.
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2108%2Fwincent%2Fauto-jump-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2108/wincent/auto-jump-v2
Pull-Request: https://github.com/gitgitgadget/git/pull/2108
Range-diff vs v1:
1: 87fa66d233 ! 1: 5fbc8480ef git-jump: pick a mode automatically when invoked without arguments
@@ Commit message
arguments after `--stdout`) it currently prints usage and exits with
status 1.
- But there are two situations where we can usefully infer the most
+ But there are several situations where we can usefully infer the most
valuable and likely mode that a user would want to use, and select it
- automatically when they run `git jump` without arguments:
+ automatically:
1. When there are unmerged paths in the index, the user likely
wants `git jump merge`.
@@ Commit message
2. When the working tree has unstaged changes, the user likely
wants `git jump diff`.
- Detect these two cases and dispatch to the corresponding mode
- automatically, falling back to the existing usage-and-exit behavior
- when neither holds.
+ 3. In the presence of conflict markers or whitespace errors (as reported
+ by `git diff --check`), the user likely wants `git jump ws`.
+
+ In this commit we teach `git jump` a new "auto" mode which detects these
+ cases and dispatches to the corresponding mode automatically. The user
+ can either explicitly spell out `git jump auto`, or just leave it at
+ `git jump` (because "auto" is the default).
+
+ If none of the interesting cases listed above applies, then auto mode
+ falls back to the existing usage-and-exit behavior.
Signed-off-by: Greg Hurrell <greg.hurrell@datadoghq.com>
## contrib/git-jump/README ##
-@@ contrib/git-jump/README: To use it, just drop git-jump in your PATH, and then invoke it like
- this:
+@@ contrib/git-jump/README: git jump grep foo_bar
+ # arbitrary grep options
+ git jump grep -i foo_bar
- --------------------------------------------------
++# jump to places with conflict markers or whitespace errors
++# (as reported by # `git diff --check`)
++git jump ws
++
+ # use the silver searcher for git jump grep
+ git config jump.grepCmd "ag --column"
++
+# pick a mode automatically: "merge" if there are unmerged paths,
-+# "diff" if the worktree has unstaged changes, otherwise show usage
-+git jump
++# "diff" if the worktree has unstaged changes, "ws" if there are
++# whitespace problems; otherwise show usage
++git jump auto
+
- # jump to changes not yet staged for commit
- git jump diff
++# with no explicit mode, same as "auto"
++git jump
+ --------------------------------------------------
+ You can use the optional argument '--stdout' to print the listing to
## contrib/git-jump/git-jump ##
@@
@@ contrib/git-jump/git-jump
+usage: git jump [--stdout] [<mode>] [<args>]
Jump to interesting elements in an editor.
- The <mode> parameter is one of:
-@@ contrib/git-jump/git-jump: while test $# -gt 0; do
- shift
- done
- if test $# -lt 1; then
-- usage >&2
-- exit 1
+-The <mode> parameter is one of:
++The <mode> parameter is one of the following,
++defaulting to "auto" if omitted:
+
+ diff: elements are diff hunks. Arguments are given to diff.
+
+@@ contrib/git-jump/git-jump: grep: elements are grep hits. Arguments are given to git grep or, if
+
+ ws: elements are whitespace errors. Arguments are given to diff --check.
+
++auto: select one of the other modes based on worktree state;
++ "merge" if there are unmerged paths, "diff" if there are
++ unstaged changes, "ws" if there are whitespace errors.
++
+ If the optional argument `--stdout` is given, print the quickfix
+ lines to standard output instead of feeding it to the editor.
+ EOF
+@@ contrib/git-jump/git-jump: mode_ws() {
+ git diff --check "$@"
+ }
+
++mode_auto() {
+ if test "$(git rev-parse --is-inside-work-tree 2>/dev/null)" != "true"; then
+ usage >&2
+ exit 1
+ fi
-+ if test -n "$(git ls-files -u)"; then
-+ set -- merge
-+ elif ! git diff --quiet; then
-+ set -- diff
++ if test -n "$(git ls-files -u "$@")"; then
++ mode_merge "$@"
++ elif ! git diff --quiet "$@"; then
++ mode_diff "$@"
++ elif ! git diff --check >/dev/null 2>&1; then
++ mode_ws "$@"
+ else
+ usage >&2
+ exit 1
+ fi
++}
++
+ use_stdout=
+ while test $# -gt 0; do
+ case "$1" in
+@@ contrib/git-jump/git-jump: while test $# -gt 0; do
+ shift
+ done
+ if test $# -lt 1; then
+- usage >&2
+- exit 1
++ set -- auto
fi
mode=$1; shift
type "mode_$mode" >/dev/null 2>&1 || { usage >&2; exit 1; }
contrib/git-jump/README | 12 ++++++++++++
contrib/git-jump/git-jump | 29 +++++++++++++++++++++++++----
2 files changed, 37 insertions(+), 4 deletions(-)
diff --git a/contrib/git-jump/README b/contrib/git-jump/README
index 3211841305..ac35792e55 100644
--- a/contrib/git-jump/README
+++ b/contrib/git-jump/README
@@ -75,8 +75,20 @@ git jump grep foo_bar
# arbitrary grep options
git jump grep -i foo_bar
+# jump to places with conflict markers or whitespace errors
+# (as reported by # `git diff --check`)
+git jump ws
+
# use the silver searcher for git jump grep
git config jump.grepCmd "ag --column"
+
+# pick a mode automatically: "merge" if there are unmerged paths,
+# "diff" if the worktree has unstaged changes, "ws" if there are
+# whitespace problems; otherwise show usage
+git jump auto
+
+# with no explicit mode, same as "auto"
+git jump
--------------------------------------------------
You can use the optional argument '--stdout' to print the listing to
diff --git a/contrib/git-jump/git-jump b/contrib/git-jump/git-jump
index 8d1d5d79a6..43d3b42a41 100755
--- a/contrib/git-jump/git-jump
+++ b/contrib/git-jump/git-jump
@@ -2,10 +2,11 @@
usage() {
cat <<\EOF
-usage: git jump [--stdout] <mode> [<args>]
+usage: git jump [--stdout] [<mode>] [<args>]
Jump to interesting elements in an editor.
-The <mode> parameter is one of:
+The <mode> parameter is one of the following,
+defaulting to "auto" if omitted:
diff: elements are diff hunks. Arguments are given to diff.
@@ -16,6 +17,10 @@ grep: elements are grep hits. Arguments are given to git grep or, if
ws: elements are whitespace errors. Arguments are given to diff --check.
+auto: select one of the other modes based on worktree state;
+ "merge" if there are unmerged paths, "diff" if there are
+ unstaged changes, "ws" if there are whitespace errors.
+
If the optional argument `--stdout` is given, print the quickfix
lines to standard output instead of feeding it to the editor.
EOF
@@ -82,6 +87,23 @@ mode_ws() {
git diff --check "$@"
}
+mode_auto() {
+ if test "$(git rev-parse --is-inside-work-tree 2>/dev/null)" != "true"; then
+ usage >&2
+ exit 1
+ fi
+ if test -n "$(git ls-files -u "$@")"; then
+ mode_merge "$@"
+ elif ! git diff --quiet "$@"; then
+ mode_diff "$@"
+ elif ! git diff --check >/dev/null 2>&1; then
+ mode_ws "$@"
+ else
+ usage >&2
+ exit 1
+ fi
+}
+
use_stdout=
while test $# -gt 0; do
case "$1" in
@@ -99,8 +121,7 @@ while test $# -gt 0; do
shift
done
if test $# -lt 1; then
- usage >&2
- exit 1
+ set -- auto
fi
mode=$1; shift
type "mode_$mode" >/dev/null 2>&1 || { usage >&2; exit 1; }
base-commit: 1c00d2d8392f603a6263f11f1a50fde96ae5475e
--
gitgitgadget
^ permalink raw reply related
* Re: [PATCH v3] doc: add caveat about turning off commit-graph
From: Kristoffer Haugsbakk @ 2026-05-20 7:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Derrick Stolee, git, Oswald Buddenhagen
In-Reply-To: <xmqq8q9qwxrr.fsf@gitster.g>
On Mon, May 11, 2026, at 03:16, Junio C Hamano wrote:
>>>[snip]
>>
>> It’s certainly not necessary, yeah. :)
>>
>> I am basing this on a recollection of someone quoting this from
>> SubmittingPatches:
>>
>> 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.
>>
>> They said that this was outdated since Junio does it himself. But then
>> Junio replied and said that it’s good/better if the contributor does it.
>
> I used to say "let me do this to skip one extra roundtrip" but I
> stopped saying so. Perhaps I should be a bit more explicit and stop
> being silently nice to contributors who do not follow the guidelines
> to the letter in order to unconfuse you and your friends. It
> actually is a tempting thought.
I am personally okay with adding these trailers and think it’s nice to
document such review/ack/etc. interactions.
Just considering this part in isolation, I imagine that you not filling
in missing acks etc. will lead to less such trailers because (1) most
contributors don’t seem to follow up with such updates if the only
change is the trailers section, and (2) most people here (culturally)
don’t add explicit trailer lines in their replies (e.g. an “LGTM” is
clearly an ack, but not explicit).
>> Well, this is another instance that I may be trying to be too
>> helpful and over extending myself, which does not make the process
>> scale well (the other one being the "one final resend after the
>> list reached a consensus").
>>
>> If the authors collect Acks and Reviewed-by's and resend after the
>> list reached the concensus, it may take one extra iteration, but I
>> no longer have to keep track of these trailers myself, which couldOn Mon, May 11, 2026, at 03:16, Junio C Hamano wrote:
>>>[snip]
>>
>> It’s certainly not necessary, yeah. :)
>>
>> I am basing this on a recollection of someone quoting this from
>> SubmittingPatches:
>>
>> 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.
>>
>> They said that this was outdated since Junio does it himself. But then
>> Junio replied and said that it’s good/better if the contributor does it.
>
> I used to say "let me do this to skip one extra roundtrip" but I
> stopped saying so. Perhaps I should be a bit more explicit and stop
> being silently nice to contributors who do not follow the guidelines
> to the letter in order to unconfuse you and your friends. It
> actually is a tempting thought.
I am personally okay with adding these trailers and think it’s nice to
document such review/ack/etc. interactions.
Just considering this part in isolation, I imagine that you not filling
in missing acks etc. will lead to less such trailers because (1) most
contributors don’t seem to follow up with such updates if the only
change is the trailers section, and (2) most people here (culturally)
don’t add explicit trailer lines in their replies (e.g. an “LGTM” is
clearly an ack, but not explicit).
>> Well, this is another instance that I may be trying to be too
>> helpful and over extending myself, which does not make the process
>> scale well (the other one being the "one final resend after the
>> list reached a consensus").
>>
>> If the authors collect Acks and Reviewed-by's and resend after the
>> list reached the concensus, it may take one extra iteration, but I
>> no longer have to keep track of these trailers myself, which could
>> be a big win.
>>
>> So, I dunno.
>>
>> In conclusion for now: I dunno. :)
>
> I do not know either, but if we agree that everybody should do so
> themselves and I should refrain from applying the ones that lack
> Acks, I can adjust. There will be lot of unapplied patches left on
> the mailing list initially until the contributors adjust their
> behaviour, but in the long run it may be beneficial?
Okay, if the proposal is to *not* e.g. graduate series to `next` that
haven’t applied the acks etc. then I understand how it will likely lead
to some stalls until people adjust.
To be clear, I imagine this is how it would play out:
• The series in itself is ready for `next` and has no unapplied acks
etc.: it graduates to `next`
• The series in itself is ready for `next` but has unapplied acks etc.:
it does not graduate to `next` since the contributor should send a new
version with the trailer changes
***
There is also the paragraph previous to the trailer one:
After the list reached a consensus that it is a good idea to apply the
patch, re-send it with "To:" set to the maintainer{current-maintainer}
and "cc:" the list{git-ml} for inclusion. This is especially relevant
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:`, [...]
And I have only managed to follow that part maybe, probably one single time.
>> be a big win.
>>
>> So, I dunno.
>>
>> In conclusion for now: I dunno. :)
>
> I do not know either, but if we agree that everybody should do so
> themselves and I should refrain from applying the ones that lack
> Acks, I can adjust. There will be lot of unapplied patches left on
> the mailing list initially until the contributors adjust their
> behaviour, but in the long run it may be beneficial?
Okay, if the proposal is to *not* e.g. graduate series to `next` that
haven’t applied the acks etc. then I understand how it will likely lead
to some stalls until people adjust.
To be clear, I imagine this is how it would play out:
• The series in itself is ready for `next` and has no unapplied acks
etc.: it graduates to `next`
• The series in itself is ready for `next` but has unapplied acks etc.:
it does not graduate to `next` since the contributor should send a new
version with the trailer changes
***
There is also the paragraph previous to the trailer one:
After the list reached a consensus that it is a good idea to apply the
patch, re-send it with "To:" set to the maintainer{current-maintainer}
and "cc:" the list{git-ml} for inclusion. This is especially relevant
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:`, [...]
And I have only managed to follow that part maybe, probably one single time.
^ permalink raw reply
* Re: [PATCH 3/9] wrapper: add sleep_nanosec
From: Siddh Raman Pant @ 2026-05-20 7:07 UTC (permalink / raw)
To: gitster@pobox.com
Cc: git@vger.kernel.org, calvinwan@google.com, newren@gmail.com,
ps@pks.im, code@khaugsbakk.name
In-Reply-To: <87qzn7q7qj.fsf@gitster.g>
[-- Attachment #1: Type: text/plain, Size: 496 bytes --]
On Wed, May 20 2026 at 05:20:44 +0530, Junio C Hamano wrote:
> The space above the signed-off-by line should be utilized to explain
> why we want this change. For the purpose of this series, why do we
> want to sleep at nanosecond precision?
The current time returned by getnanotime() is in nanoseconds which is
used for deadline, so to avoid re-casting in helper code path we try to
stay in nanosecond world. The caller can store in ns once and reuse it
everytime.
Thanks,
Siddh
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 1/9] Documentation/git-range-diff: add missing notes options in synopsis
From: Siddh Raman Pant @ 2026-05-20 7:00 UTC (permalink / raw)
To: gitster@pobox.com
Cc: git@vger.kernel.org, newren@gmail.com, ps@pks.im,
code@khaugsbakk.name
In-Reply-To: <87v7cjq7vc.fsf@gitster.g>
[-- Attachment #1: Type: text/plain, Size: 383 bytes --]
On Wed, May 20 2026 at 05:17:51 +0530, Junio C Hamano wrote:
> This has nothing to do with "external notes" topic, no?
Yeah, but since I added the command line flag I found it doesn't
mention the existing flags.
Fixing it in the "external notes" commit would be bad, so I put it
before that, since it also then provides a logical place to add new
flags.
Thanks,
Siddh
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 7/9] notes: support an external command to display notes
From: Siddh Raman Pant @ 2026-05-20 6:59 UTC (permalink / raw)
To: gitster@pobox.com
Cc: git@vger.kernel.org, calvinwan@google.com, newren@gmail.com,
ps@pks.im, code@khaugsbakk.name
In-Reply-To: <87fr3nq74l.fsf@gitster.g>
[-- Attachment #1: Type: text/plain, Size: 3052 bytes --]
On Wed, May 20 2026 at 05:33:54 +0530, Junio C Hamano wrote:
> Siddh Raman Pant <siddh.raman.pant@oracle.com> writes:
>
> > This problem excaberates on scale.
> >
> > One solution to this is a realtime fetch or faster updation via
> > external means, but unfortunately we lose the coherence in the
> > display of information, and the user would end up reinventing
> > git log.
> >
> > So let's add support for an external command to display the notes.
>
> It is unclear how we would arrive at "So let's" from the previous
> paragraph. It is not limited to notes but multiple people updating
> the same thing racing against each other happens all the time in the
> main part of the history, no? Isn't a better solution for such
> racing situation usually based on a better merge support, I have to
> wonder?
Sorry, I should have been clear.
The issue I meant to describe is not primarily about two people
updating the same note object at the same time.
The workflow I have in mind is different. In kernel work, the same
logical upstream fix can appear as different commit objects across many
downstream branches, such as the stable branches and vendor-specific
branches (based on which the released kernel is actually built).
Different developers may be working on those branches in parallel, and
a review decision recorded for one backport is useful context for the
others.
Today, seeing that decision in ordinary history output requires first
synchronizing the local notes ref, and then interpreting those notes
for the branch being inspected. The latter step is workflow-specific
and can be cheap, but keeping the local notes state fresh enough can be
expensive in a large kernel repository with a large shared notes
history (and if we are to extrapolate, a slow git server conn/ops can
be a factor too).
That is the synchronization problem I was trying to describe: not that
Git should solve all concurrent note updates, but that users can be
looking at stale note-derived information simply because their local
notes state has not caught up yet and catching up is expensive.
The intended role of the external command is to move that freshness
policy out of Git's notes ref synchronization path. A site-specific
helper can decide how to obtain current note text for the commit being
displayed, such as consulting an external service, doing a targeted
lookup, or using its own cache/update policy. Git still owns the
coherent git log/show presentation; the helper only supplies the note
text to display.
> > We split the addition of documentation and tests from this commit for
> > easier review. The new help text added in Documentation/ in the next
> > commit should make the usage clear.
>
> It is unclear why a large body of code that is not documented or
> whose uses are not illustrated by examples found in the test scripts
> is easier to review, though.
Okay my bad. I'll squash them in v2 after this discussion, along with
rewording the commit.
Thanks,
Siddh
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2] remote: qualify "git pull" advice for non-upstream branches
From: Harald Nordgren @ 2026-05-20 6:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Harald Nordgren via GitGitGadget, git
In-Reply-To: <xmqqbjeb7qfv.fsf@gitster.g>
> Hmph, shouldn't this be done conditionally, though? Most new users
> follow the recommended pattern to set branch.<name>.merge so that
> "git pull" would do the right thing for them, I presume, even when
> they are using triangular workflow to push to a different remote
> than the remote they pull from, so the new and more verbose message
> would not help the users any more than the existing message, right?
>
> Can the code tell the situation where the extra part of the message
> would help and give it only then?
Yes, that's a good idea.
Harald
^ permalink raw reply
* Re: [PATCH] apply: plug strbuf leak
From: Junio C Hamano @ 2026-05-20 6:48 UTC (permalink / raw)
To: git
In-Reply-To: <xmqq33zm4msa.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
> Depending on how read_patch_file() fails, it may already have read
> many bytes into the supplied strbuf. Either the caller or the callee
> should release the strbuf.
>
> Here we choose to make the sole caller of the function responsible
> for releasing it, as it makes the error handling slightly simpler.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> apply.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/apply.c b/apply.c
> index 4aa1694cfa..0167902325 100644
> --- a/apply.c
> +++ b/apply.c
> @@ -4881,8 +4881,10 @@ static int apply_patch(struct apply_state *state,
>
> state->patch_input_file = filename;
> state->linenr = 1;
> - if (read_patch_file(&buf, fd) < 0)
> + if (read_patch_file(&buf, fd) < 0) {
> + strbuf_release(&buf);
> return -128;
> + }
Ah, my mistake. This was one of the two "oh, we found longstanding
issues immediately after enabling EXPENSIVE tests on" fixes Peff
already fixed for us.
> offset = 0;
> while (offset < buf.len) {
> struct patch *patch;
^ permalink raw reply
* Re: What's cooking in git.git (May 2026, #05)
From: Junio C Hamano @ 2026-05-20 6:38 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20260520054436.GA3849892@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, May 20, 2026 at 02:19:24PM +0900, Junio C Hamano wrote:
>
>> * jk/commit-graph-lazy-load-fallback (2026-05-18) 1 commit
>> - commit: fall back to full read when maybe_tree is NULL
>>
>> 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.
>>
>> Will merge to 'next'?
>> source: <20260519050513.GA1635924@coredump.intra.peff.net>
>
> I posted an updated patch in response to your suggestion to use
> parse_oid_hex_algop(), but it looks like the topic in your repo has the
> original.
Indeed, with sufficient amount of front matter before the scissors
line, I missed the patch X-<.
Applied. Thanks.
^ permalink raw reply
* [PATCH] apply: plug strbuf leak
From: Junio C Hamano @ 2026-05-20 6:28 UTC (permalink / raw)
To: git
Depending on how read_patch_file() fails, it may already have read
many bytes into the supplied strbuf. Either the caller or the callee
should release the strbuf.
Here we choose to make the sole caller of the function responsible
for releasing it, as it makes the error handling slightly simpler.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
apply.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/apply.c b/apply.c
index 4aa1694cfa..0167902325 100644
--- a/apply.c
+++ b/apply.c
@@ -4881,8 +4881,10 @@ static int apply_patch(struct apply_state *state,
state->patch_input_file = filename;
state->linenr = 1;
- if (read_patch_file(&buf, fd) < 0)
+ if (read_patch_file(&buf, fd) < 0) {
+ strbuf_release(&buf);
return -128;
+ }
offset = 0;
while (offset < buf.len) {
struct patch *patch;
--
2.54.0-398-ga4b2d32071
^ permalink raw reply related
* Re: [PATCH v8] revision.c: implement --max-count-oldest
From: Junio C Hamano @ 2026-05-20 6:02 UTC (permalink / raw)
To: Mirko Faina
Cc: git, Jeff King, Jean-Noël Avila, Patrick Steinhardt,
Tian Yuchen, Ben Knoble, Johannes Sixt, Chris Torek
In-Reply-To: <8210d60832b9a58aa4d71fc3790e44d8989564ce.1779152064.git.mroik@delayed.space>
Mirko Faina <mroik@delayed.space> writes:
> --max-count is a commit limiting option sets a maximum amount of commits
> to be shown. If a user wants to see only the first N commits of the
> history (the oldest commits) they'd have to do something like
>
> git log $(git rev-list HEAD | tail -n N | head -n 1)
>
> This is not very user-friendly.
>
> Teach get_revision() the --max-count-oldest option.
>
> Signed-off-by: Mirko Faina <mroik@delayed.space>
> ---
This breaks CI
https://github.com/git/git/actions/runs/26138986677/job/76880268854#step:4:2072
Squash something like this to fix.
--- >8 ---
Subject: [PATCH] SQUASH??? test portability and other fixes
* "test_when_finished" should use "rm -f", not an error-detecting
"rm", as the execution may not have reached to the point to create
the "actual" file it is removing.
* Do not hide exit status of "git log" by piping its output into
another process.
* Do not expect output of "wc -l" is portable. macOS puts extra
whitespaces in front, while GNU/Linux does not.
---
t/t4202-log.sh | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/t/t4202-log.sh b/t/t4202-log.sh
index c3c1b862d3..75edb0eb38 100755
--- a/t/t4202-log.sh
+++ b/t/t4202-log.sh
@@ -1916,11 +1916,10 @@ test_expect_success 'log --max-count-oldest=1000 --graph --boundary' '
'
test_expect_success 'log --oneline --graph --boundary --max-count-oldest=1' '
- test_when_finished rm actual &&
- echo 2 >expect &&
- git log --oneline --graph --boundary --max-count-oldest=1 HEAD~1..HEAD \
- | wc -l >actual &&
- test_cmp expect actual
+ test_when_finished rm -f actual &&
+ git log --oneline --graph --boundary --max-count-oldest=1 \
+ HEAD~1..HEAD >actual &&
+ test_line_count = 2 actual
'
cat >expect <<-\EOF
--
2.54.0-398-ga4b2d32071
^ permalink raw reply related
* Re: [PATCH v3 1/2] builtin/maintenance: fix locking with "--detach"
From: Patrick Steinhardt @ 2026-05-20 5:52 UTC (permalink / raw)
To: Jeff King
Cc: Taylor Blau, Junio C Hamano, git, Jean-Christophe Manciot,
Mikael Magnusson, Derrick Stolee
In-Reply-To: <20260520054716.GB3849892@coredump.intra.peff.net>
On Wed, May 20, 2026 at 01:47:16AM -0400, Jeff King wrote:
> On Tue, May 19, 2026 at 08:10:26PM -0400, Taylor Blau wrote:
>
> > Thanks, Patrick, for making the change. I think that this series is in a
> > good spot, though I'd like to hear from Peff who had some comments on
> > the second patch from the previous round.
>
> What's in v3 of the series looks good to me (both patches).
Thanks, both!
Patrick
^ permalink raw reply
* Re: [PATCH v3 1/2] builtin/maintenance: fix locking with "--detach"
From: Jeff King @ 2026-05-20 5:47 UTC (permalink / raw)
To: Taylor Blau
Cc: Junio C Hamano, Patrick Steinhardt, git, Jean-Christophe Manciot,
Mikael Magnusson, Derrick Stolee
In-Reply-To: <agz78jjYEAif4lZt@nand.local>
On Tue, May 19, 2026 at 08:10:26PM -0400, Taylor Blau wrote:
> Thanks, Patrick, for making the change. I think that this series is in a
> good spot, though I'd like to hear from Peff who had some comments on
> the second patch from the previous round.
What's in v3 of the series looks good to me (both patches).
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (May 2026, #05)
From: Jeff King @ 2026-05-20 5:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqo6ia4q03.fsf@gitster.g>
On Wed, May 20, 2026 at 02:19:24PM +0900, Junio C Hamano wrote:
> * jk/commit-graph-lazy-load-fallback (2026-05-18) 1 commit
> - commit: fall back to full read when maybe_tree is NULL
>
> 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.
>
> Will merge to 'next'?
> source: <20260519050513.GA1635924@coredump.intra.peff.net>
I posted an updated patch in response to your suggestion to use
parse_oid_hex_algop(), but it looks like the topic in your repo has the
original.
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (May 2026, #05)
From: Junio C Hamano @ 2026-05-20 5:27 UTC (permalink / raw)
To: git
In-Reply-To: <xmqqo6ia4q03.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
> Here are the topics that have been cooking in my tree. Commits
> prefixed with '+' are in 'next' (being in 'next' is a sign that a
> topic is stable enough to be used and is a candidate to be in a
> future release).
The following shows status of various topics. The information
contained there can mechanically be produced from the contents of
the "What's cooking" report I am responding to, but I am sending it
out as an experiment to see if people find it easier to grok to have
something like this near the top as "table of contents", perhaps
before the main report.
------------------------------------------------------------
Comments?
- cs/subtree-split-recursion 03-05 #3
<20260305-cs-subtree-split-recursion-v2-0-7266be870ba9@howdoi.land>
- jd/unpack-trees-wo-the-repository 03-31 #2
<pull.2258.v2.git.git.1774971267.gitgitgadget@gmail.com>
- th/promisor-quiet-per-repo 04-06 #1
<20260406183041.783800-1-vikingtc4@gmail.com>
- mm/line-log-cleanup 04-27 #3
<xmqqfr3xp98b.fsf@gitster.g>
<pull.2094.git.1777349126.gitgitgadget@gmail.com>
- ua/push-remote-group 05-03 #3
<20260503153402.1333220-1-usmanakinyemi202@gmail.com>
- rs/strbuf-add-uint 05-12 #4
<20260512115603.80780-1-l.s.r@web.de>
- hn/status-pull-advice-qualified 05-13 #1
<pull.2301.v2.git.git.1778665812261.gitgitgadget@gmail.com>
- mm/doc-word-diff 05-13 #1
<pull.2113.git.1778686956622.gitgitgadget@gmail.com>
- rs/strbuf-add-oid-hex 05-13 #1
<183aa0fd-d455-4ec9-9c42-d511fac8b3e4@web.de>
- ps/maintenance-daemonize-lockfix 05-13 #2
<20260513-pks-maintenance-fix-lock-with-detach-v3-0-f27a1ac82891@pks.im>
- hn/branch-prune-merged 05-13 #5
<pull.2285.v9.git.git.1778700883.gitgitgadget@gmail.com>
- ds/path-walk-filters 05-13 #14
<pull.2101.v4.git.1778707135.gitgitgadget@gmail.com>
- ta/approxidate-noon-fix 05-16 #4
<20260516151540.9611-1-taahol@utu.fi>
- hn/config-typo-advice 05-16 #1
<pull.2302.v2.git.git.1778935976330.gitgitgadget@gmail.com>
- ja/doc-synopsis-style-again 05-17 #5
<pull.2117.git.1779049615.gitgitgadget@gmail.com>
- jt/config-lock-timeout 05-17 #1
<xmqqzf1xbl4i.fsf@gitster.g>
<20260517132111.1014901-1-joerg@thalheim.io>
- hn/checkout-track-fetch 05-18 #1
<pull.2301.git.git.1778623888178.gitgitgadget@gmail.com>
<pull.2281.v10.git.git.1779091483321.gitgitgadget@gmail.com>
- mf/revision-max-count-oldest 05-18 #1
<8210d60832b9a58aa4d71fc3790e44d8989564ce.1779152064.git.mroik@delayed.space>
- cc/promisor-auto-config-url-more 05-19 #9
<20260519153808.494105-1-christian.couder@gmail.com>
Expecting a reroll.
- ob/more-repo-config-values 04-23 #8
<CAD=f0L8-_3sDGGkCzF4WA0xmUtaY_qiz__3zq5AemLgwTsqvsg@mail.gmail.com>
<xmqqlddqu013.fsf@gitster.g>
<20260423165432.143598-1-belkid98@gmail.com>
- js/parseopt-subcommand-autocorrection 04-27 #11
<xmqqcxz2tzpr.fsf@gitster.g>
<SY0P300MB0801677A2A1E0FD38D06A841CE2A2@SY0P300MB0801.AUSP300.PROD.OUTLOOK.COM>
Need to wait for the base topic.
- ps/odb-in-memory 04-10 #18
<20260410-b4-pks-odb-source-inmemory-v3-0-22fd0fad58fe@pks.im>
Needs review.
- kh/doc-trailers 04-13 #9
<xmqq1pfivfa3.fsf@gitster.g>
<V2_CV_doc_int-tr_key_format.613@msgid.xyz>
- lp/repack-propagate-promisor-debugging-info 04-18 #6
<xmqqse7xm8av.fsf@gitster.g>
<cover.1776384902.git.lorenzo.pegorari2002@gmail.com>
- en/ort-harden-against-corrupt-trees 04-20 #5
<pull.2096.git.1776731171.gitgitgadget@gmail.com>
- pw/status-rebase-todo 05-01 #2
<cover.1777648598.git.phillip.wood@dunelm.org.uk>
On hold to help the base topic with wider exposure.
- jc/neuter-sideband-post-3.0 03-05 #2
<20260305233452.3727126-8-gitster@pobox.com>
Unclassified.
- ed/check-connected-close-err-fd-2.53 05-14 #1
<pull.2303.git.git.1778827194448.gitgitgadget@gmail.com>
- aj/stash-patch-optimize-temporary-index 05-19 #1
<pull.2306.git.git.1779194605735.gitgitgadget@gmail.com>
- tb/bitmap-build-performance 05-19 #9
<cover.1779207127.git.me@ttaylorr.com>
Waiting for response(s) to review comment(s).
- ps/shift-root-in-graph 04-27 #1
<20260513230216.GA1378627@coredump.intra.peff.net>
<20260427102838.44867-2-pabloosabaterr@gmail.com>
- st/daemon-sockaddr-fixes 05-14 #3
<agGLRC1ziF5F8Okh@pks.im>
<pull.2300.git.git.1778773592.gitgitgadget@gmail.com>
Will merge to 'master'.
+ kh/doc-log-decorate-list 04-27/05-15 #2
+ za/t2000-modernise-more 04-29/05-15 #1
+ mm/git-url-parse 05-01/05-15 #8
+ kn/refs-generic-helpers 05-04/05-15 #9
+ pw/xdiff-shrink-memory-consumption 05-04/05-15 #5
+ aw/validate-proxy-url-scheme 05-05/05-15 #1
+ jc/ci-enable-expensive 05-10/05-15 #2
+ sp/shallow-deepen-on-non-shallow-repo-fix 05-11/05-15 #1
+ ag/sequencer-remove-unused-struct-member 05-11/05-17 #1
+ kk/paint-down-to-common-optim 05-11/05-17 #2
+ jk/dumb-http-alternate-fix 05-12/05-17 #1
+ jk/pretty-no-strbuf-presizing 05-12/05-17 #1
+ mm/diff-U-takes-no-negative-values 05-12/05-17 #4
+ dk/doc-exclude-is-shared-per-repo 05-12/05-17 #1
+ tb/pseudo-merge-bugfixes 05-11/05-19 #9
+ kk/limit-list-optim 05-14/05-19 #1
+ kk/merge-octopus-optim 05-11/05-20 #1
+ en/batch-prefetch 05-14/05-20 #4
+ jk/apply-leakfix 05-15/05-20 #1
+ jk/commit-sign-overflow-fix 05-15/05-20 #1
+ pb/doc-diff-format-updates 05-15/05-20 #3
+ rs/trailer-fold-optim 05-15/05-20 #1
+ ps/t3903-cover-stash-include-untracked 05-16/05-20 #1
Will merge to 'next'.
- jt/odb-transaction-write 05-14 #7
- kn/refs-fsck-skip-lock-files 05-17 #1
- jk/connect-service-enum 05-18 #1
- jk/sq-dequote-cleanup 05-18 #3
- rs/use-builtin-add-overflow-explicitly-on-clang 05-18 #2
- ds/fetch-negotiation-options 05-19 #8
- tb/incremental-midx-part-3.3 05-19 #16
Will merge to 'next'?
- ps/graph-lane-limit 03-27 #3
<bdff0a5d-b738-4053-9b72-08eba88156de@kdbg.org>
<20260328001113.1275291-1-pabloosabaterr@gmail.com>
- sa/cat-file-batch-mailmap-switch 04-15 #1
<20260416033250.4327-2-siddharthasthana31@gmail.com>
- pt/fsmonitor-linux 04-15 #13
<xmqqa4u5nnxq.fsf@gitster.g>
<pull.2147.v15.git.git.1776259657.gitgitgadget@gmail.com>
- cl/conditional-config-on-worktree-path 05-13 #2
<2989eb07-2933-4b5a-9e5c-33ef9b805528@gmail.com>
<20260513-includeif-worktree-v4-0-f8e6212d1fba@black-desk.cn>
- jr/bisect-custom-terms-in-output 05-14 #3
<20260514-bisect-terms-v4-0-b3e3cf1b06ce@schlaraffenlan.de>
- tc/generate-configlist-fix-for-older-ninja 05-15 #1
<20260515-toon-fix-almalinux8-v3-1-b545a0647f0f@iotcl.com>
- ed/check-connected-close-err-fd 05-16 #1
- kk/tips-reachable-from-bases-optim 05-16 #2
<pull.2116.v3.git.1778947182.gitgitgadget@gmail.com>
- jk/commit-graph-lazy-load-fallback 05-18 #1
<20260519050513.GA1635924@coredump.intra.peff.net>
- ps/setup-wo-the-repository 05-19 #18
<20260519-pks-setup-wo-the-repository-v3-0-a00d8ea8b07f@pks.im>
^ permalink raw reply
* What's cooking in git.git (May 2026, #05)
From: Junio C Hamano @ 2026-05-20 5:19 UTC (permalink / raw)
To: git
Here are the topics that have been cooking in my tree. Commits
prefixed with '+' are in 'next' (being in 'next' is a sign that a
topic is stable enough to be used and is a candidate to be in a
future release). Commits prefixed with '-' are only in 'seen', and
aren't considered "accepted" at all and may be annotated with a URL
to a message that raises issues but they are by no means exhaustive.
A topic without enough support may be discarded after a long period
of no activity (of course they can be resubmitted when new interests
arise).
Copies of the source code to Git live in many repositories, and the
following is a list of the ones I push into or their mirrors. Some
repositories have only a subset of branches.
With maint, master, next, seen, todo:
git://git.kernel.org/pub/scm/git/git.git/
git://repo.or.cz/alt-git.git/
https://kernel.googlesource.com/pub/scm/git/git/
https://github.com/git/git/
https://gitlab.com/git-scm/git/
With all the integration branches and topics broken out:
https://github.com/gitster/git/
Even though the preformatted documentation in HTML and man format
are not sources, they are published in these repositories for
convenience (replace "htmldocs" with "manpages" for the manual
pages):
git://git.kernel.org/pub/scm/git/git-htmldocs.git/
https://github.com/gitster/git-htmldocs.git/
Release tarballs are available at:
https://www.kernel.org/pub/software/scm/git/
--------------------------------------------------
[New Topics]
* jk/commit-graph-lazy-load-fallback (2026-05-18) 1 commit
- commit: fall back to full read when maybe_tree is NULL
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.
Will merge to 'next'?
source: <20260519050513.GA1635924@coredump.intra.peff.net>
* jk/connect-service-enum (2026-05-18) 1 commit
- connect: use "service" enum for "name" argument
The "name" argument in git_connect() and related functions has been
converted to a "service" enum to improve type safety and clarify its
purpose.
Will merge to 'next'.
source: <20260519052219.GA1703179@coredump.intra.peff.net>
* jk/sq-dequote-cleanup (2026-05-18) 3 commits
- quote: simplify internals of dequoting
- quote: drop sq_dequote_to_argv()
- quote.h: bump strvec forward declaration to the top
Code simplification.
Will merge to 'next'.
source: <20260519011837.GA1615637@coredump.intra.peff.net>
* aj/stash-patch-optimize-temporary-index (2026-05-19) 1 commit
- stash: reuse cached index entries in --patch temporary index
"git stash -p" has been optimized by reusing cached index
entries in its temporary index, avoiding unnecessary lstat()
calls on unchanged files.
source: <pull.2306.git.git.1779194605735.gitgitgadget@gmail.com>
* tb/bitmap-build-performance (2026-05-19) 9 commits
- pack-bitmap: build pseudo-merge bitmaps after regular bitmaps
- pack-bitmap: remember pseudo-merge parents
- pack-bitmap: sort bitmaps before XORing
- pack-bitmap: cache object positions during fill
- pack-bitmap: consolidate `find_object_pos()` success path
- pack-bitmap: reuse stored selected bitmaps
- pack-bitmap: check subtree bits before recursing
- pack-bitmap: pass object position to `fill_bitmap_tree()`
- Merge branch 'tb/pseudo-merge-bugfixes' into tb/bitmap-build-performance
(this branch uses tb/pseudo-merge-bugfixes.)
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.
source: <cover.1779207127.git.me@ttaylorr.com>
--------------------------------------------------
[Graduated to 'master']
* ag/rebase-update-refs-limit-to-branches (2026-05-10) 1 commit
(merged to 'next' on 2026-05-12 at 5222da09bb)
+ rebase: ignore non-branch update-refs
"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.
source: <20260510224111.64467-2-mail@abhinavg.net>
* bc/sign-commit-with-custom-encoding (2026-04-27) 2 commits
(merged to 'next' on 2026-05-13 at e82a4966c0)
+ commit: sign commit after mutating buffer
+ commit: name UTF-8 function appropriately
Signing commit with custom encoding was passing the data to be
signed at a wrong stage in the pipeline, which has been corrected.
cf. <xmqqtssdnpf7.fsf@gitster.g>
source: <20260427221834.1824543-1-sandals@crustytoothpaste.net>
* en/diffstat-utf8-truncation-fix (2026-04-20) 1 commit
(merged to 'next' on 2026-05-13 at adf801eb1d)
+ diff: fix out-of-bounds reads and NULL deref in diffstat UTF-8 truncation
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).
source: <pull.2093.v3.git.1776699778177.gitgitgadget@gmail.com>
* en/xdiff-cleanup-3 (2026-04-29) 6 commits
(merged to 'next' on 2026-05-12 at e4e72e0f34)
+ xdiff/xdl_cleanup_records: make execution of action easier to follow
+ xdiff/xdl_cleanup_records: make setting action easier to follow
+ xdiff/xdl_cleanup_records: make limits more clear
+ xdiff/xdl_cleanup_records: use unambiguous types
+ xdiff: use unambiguous types in xdl_bogo_sqrt()
+ xdiff/xdl_cleanup_records: delete local recs pointer
(this branch is used by pw/xdiff-shrink-memory-consumption.)
Preparation of the xdiff/ codebase to work with Rust.
source: <pull.2156.v6.git.git.1777500495.gitgitgadget@gmail.com>
* jh/alias-i18n-fixes (2026-04-24) 1 commit
(merged to 'next' on 2026-05-13 at c7cd30d414)
+ alias: restore support for simple dotted aliases
Further update to the i18n alias support to avoid regressions.
source: <20260424161707.1514255-1-jonatan@jontes.page>
* js/adjust-tests-to-explicitly-access-bare-repo (2026-04-26) 8 commits
(merged to 'next' on 2026-05-13 at 48695e1cb0)
+ safe.bareRepository: default to "explicit" with WITH_BREAKING_CHANGES
+ status tests: filter `.gitconfig` from status output
+ ls-files tests: filter `.gitconfig` from `--others` output
+ t5601: restore `.gitconfig` after includeIf test
+ t1305: use `--git-dir=.` for bare repo in include cycle test
+ t1300: remove global config settings injected by test-lib.sh
+ t7900: do not let `$HOME/.gitconfig` interfere with XDG tests
+ test-lib: allow bare repository access when breaking changes are enabled
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.
source: <pull.2098.v2.git.1777214316.gitgitgadget@gmail.com>
* js/mingw-no-nedmalloc (2026-05-08) 3 commits
(merged to 'next' on 2026-05-13 at 2116a6bcc9)
+ mingw: remove the vendored compat/nedmalloc/ subtree
+ mingw: drop the build-system plumbing for nedmalloc
+ mingw: stop using nedmalloc
Stop using unmaintained custom allocator in Windows build which was
the last user of the code.
source: <pull.2104.v3.git.1778244661.gitgitgadget@gmail.com>
* js/objects-larger-than-4gb-on-windows (2026-05-08) 11 commits
(merged to 'next' on 2026-05-13 at 843d2ac470)
+ ci: run expensive tests on push builds to integration branches
+ t5608: mark >4GB tests as EXPENSIVE
+ test-tool synthesize: add precomputed SHA-256 pack for 4 GiB + 1
+ test-tool synthesize: precompute pack for 4 GiB + 1
+ test-tool synthesize: use the unsafe hash for speed
+ t5608: add regression test for >4GB object clone
+ test-tool: add a helper to synthesize large packfiles
+ delta, packfile: use size_t for delta header sizes
+ odb, packfile: use size_t for streaming object sizes
+ git-zlib: handle data streams larger than 4GB
+ index-pack, unpack-objects: use size_t for object size
(this branch is used by jc/ci-enable-expensive.)
Update code paths that assumed "unsigned long" was long enough for
"size_t".
source: <pull.2102.v3.git.1778228209.gitgitgadget@gmail.com>
* kh/doc-commit-graph (2026-05-07) 1 commit
(merged to 'next' on 2026-05-12 at b9cafeb32d)
+ doc: add caveat about turning off commit-graph
Ramifications of turning off commit-graph has been documented a bit
more clearly.
source: <V3_caveat_commit-graph.6b6@msgid.xyz>
* kh/doc-restore-double-underscores-fix (2026-05-05) 1 commit
(merged to 'next' on 2026-05-12 at 2e8fc7cdac)
+ doc: restore: remove double underscore
Doc update.
source: <double_underscore.670@msgid.xyz>
* kh/name-rev-custom-format (2026-05-11) 5 commits
(merged to 'next' on 2026-05-12 at c944d6131e)
+ format-rev: introduce builtin for on-demand pretty formatting
+ name-rev: make dedicated --annotate-stdin --name-only test
+ name-rev: factor code for sharing with a new command
+ name-rev: run clang-format before factoring code
+ name-rev: wrap both blocks in braces
A new builtin "git format-rev" is introduced for pretty formatting
one revision expression per line or commit object names found in
running text.
source: <V5_CV_format-rev.6c9@msgid.xyz>
* mc/http-emptyauth-negotiate-fix (2026-04-30) 4 commits
(merged to 'next' on 2026-05-12 at 843ae82cd0)
+ doc: clarify http.emptyAuth values
(merged to 'next' on 2026-04-20 at 6539524ca2)
+ t5563: add tests for http.emptyAuth with Negotiate
+ http: attempt Negotiate auth in http.emptyAuth=auto mode
+ http: extract http_reauth_prepare() from retry paths
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'.
source: <e0f236767f81ea60f90749d1bc00ab78081efd0e.1777546472.git.gitgitgadget@gmail.com>
source: <pull.2087.git.1776331259.gitgitgadget@gmail.com>
* ps/history-fixup (2026-04-26) 3 commits
(merged to 'next' on 2026-05-13 at e6154b6272)
+ builtin/history: introduce "fixup" subcommand
+ builtin/history: generalize function to commit trees
+ replay: allow callers to control what happens with empty commits
"git history" learned "fixup" command.
cf. <xmqq33zxp4aq.fsf@gitster.g>
source: <20260427-b4-pks-history-fixup-v3-0-cb908f06264b@pks.im>
* rs/sideband-clear-line-before-print (2026-05-10) 1 commit
(merged to 'next' on 2026-05-12 at 83880f8ce6)
+ sideband: clear full line when printing remote messages
Tweak the way how sideband messages from remote are printed while
we talk with a remote repository to avoid tickling terminal
emulator glitches.
source: <9826dabf-c9a6-4397-8ae6-a24f9c507f1b@web.de>
* sb/unpack-index-pack-buffer-resize (2026-04-28) 1 commit
(merged to 'next' on 2026-05-13 at 2edd54bcfe)
+ index-pack, unpack-objects: increase input buffer from 4 KiB to 128 KiB
Use a larger buffer size in the code paths to ingest pack stream.
cf. <xmqqy0hpnpkb.fsf@gitster.g>
source: <pull.2282.v4.git.git.1777387660841.gitgitgadget@gmail.com>
* sg/t6112-unwanted-tilde-expansion-fix (2026-04-21) 1 commit
(merged to 'next' on 2026-05-12 at ad2d08eb44)
+ t6112: avoid tilde expansion
Test fix.
source: <20260421192132.51172-1-szeder.dev@gmail.com>
* sj/submodule-update-clone-config-fix (2026-05-09) 1 commit
(merged to 'next' on 2026-05-12 at 5a0094838a)
+ submodule-config: fix reading submodule.fetchJobs
The configuration variable submodule.fetchJobs was not read correctly,
which has been corrected.
source: <pull.2287.v4.git.git.1778385022964.gitgitgadget@gmail.com>
--------------------------------------------------
[Cooking]
* hn/status-pull-advice-qualified (2026-05-13) 1 commit
- remote: qualify "git pull" advice for non-upstream branches
Advice shown by "git status" when the local branch is behind or has
diverged from its push branch has been updated to suggest "git pull
<remote> <branch>".
Comments?
source: <pull.2301.v2.git.git.1778665812261.gitgitgadget@gmail.com>
* jk/dumb-http-alternate-fix (2026-05-12) 1 commit
(merged to 'next' on 2026-05-17 at c1a51214fb)
+ http: handle absolute-path alternates from server root
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/").
Will merge to 'master'.
source: <20260512162619.GA69813@coredump.intra.peff.net>
* jk/pretty-no-strbuf-presizing (2026-05-12) 1 commit
(merged to 'next' on 2026-05-17 at ee684c614f)
+ pretty: drop strbuf pre-sizing from add_rfc2047()
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.
Will merge to 'master'.
source: <20260512162022.GA69669@coredump.intra.peff.net>
* kk/merge-octopus-optim (2026-05-11) 1 commit
(merged to 'next' on 2026-05-20 at afe427dc66)
+ merge: use repo_in_merge_bases for octopus up-to-date check
The logic to determine that branches in an octopus merge are
independent has been optimized.
Will merge to 'master'.
cf. <c5b333f1-0db6-4aec-a369-6503cb924e7f@gmail.com>
source: <pull.2110.git.1778566286543.gitgitgadget@gmail.com>
* rs/strbuf-add-uint (2026-05-12) 4 commits
- ls-tree: use strbuf_add_uint()
- ls-files: use strbuf_add_uint()
- cat-file: use strbuf_add_uint()
- strbuf: add strbuf_add_uint()
Adding a decimal integer with strbuf_addf("%u") appears commonly;
they have been optimized by using a custom formatter.
Comments?
source: <20260512115603.80780-1-l.s.r@web.de>
* ta/approxidate-noon-fix (2026-05-16) 4 commits
- approxidate: use deferred mday adjustments for "specials"
- approxidate: make "specials" respect fixed day-of-month
- t0006: add support for approxidate test date adjustment
- approxidate: make "today" wrap to midnight
"Friday noon" asked in the morning on Sunday was parsed to be one
day before the specified time, which has been corrected.
Comments?
source: <20260516151540.9611-1-taahol@utu.fi>
* mm/doc-word-diff (2026-05-13) 1 commit
- doc: clarify that --word-diff operates on line-level hunks
The documentation for "--word-diff" has been extended with a bit of
implementation detail of where these different words come from.
Comments?
source: <pull.2113.git.1778686956622.gitgitgadget@gmail.com>
* rs/strbuf-add-oid-hex (2026-05-13) 1 commit
- hex: add and use strbuf_add_oid_hex()
Formatting object name in full hexadecimal form has been optimized
by using a new strbuf_add_oid_hex() helper function.
Comments?
source: <183aa0fd-d455-4ec9-9c42-d511fac8b3e4@web.de>
* kk/limit-list-optim (2026-05-14) 1 commit
(merged to 'next' on 2026-05-19 at f17450dd1b)
+ revision: use priority queue in limit_list()
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.
Will merge to 'master'.
source: <pull.2114.git.1778777491939.gitgitgadget@gmail.com>
* ed/check-connected-close-err-fd (2026-05-16) 1 commit
- Merge branch 'ed/check-connected-close-err-fd-2.53' into ed/check-connected-close-err-fd
(this branch uses ed/check-connected-close-err-fd-2.53.)
File descriptor leak fix.
Will merge to 'next'?
(this branch uses ed/check-connected-close-err-fd-2.53.)
* ed/check-connected-close-err-fd-2.53 (2026-05-14) 1 commit
- connected: close err_fd in promisor fast-path
(this branch is used by ed/check-connected-close-err-fd.)
File descriptor leak fix (for 2.54 maintenance track).
Will be merged together with ed/check-connected-close-err-fd topic.
source: <pull.2303.git.git.1778827194448.gitgitgadget@gmail.com>
* jk/apply-leakfix (2026-05-15) 1 commit
(merged to 'next' on 2026-05-20 at 725a20bf93)
+ apply: plug leak on "patch too large" error
Leakfix.
Will merge to 'master'.
source: <20260516021622.GA744303@coredump.intra.peff.net>
* jk/commit-sign-overflow-fix (2026-05-15) 1 commit
(merged to 'next' on 2026-05-20 at e1a320d4e5)
+ commit: handle large commit messages in utf8 verification
Leakfix.
Will merge to 'master'.
source: <20260516022310.GB744303@coredump.intra.peff.net>
* kk/tips-reachable-from-bases-optim (2026-05-16) 2 commits
- t6600: add tests for duplicate tips in tips_reachable_from_bases()
- commit-reach: use object flags for tips_reachable_from_bases()
Revision traversal optimization.
Will merge to 'next'?
source: <pull.2116.v3.git.1778947182.gitgitgadget@gmail.com>
* pb/doc-diff-format-updates (2026-05-15) 3 commits
(merged to 'next' on 2026-05-20 at fe8d31e9f9)
+ diff-format.adoc: mode and hash are 0* for unmerged paths from index only
+ diff-format.adoc: 'git diff-files' prints two lines for unmerged files
+ diff-format.adoc: remove mention of diff-tree specific output
Doc updates.
Will merge to 'master'.
source: <pull.2304.git.git.1778860091.gitgitgadget@gmail.com>
* ps/t3903-cover-stash-include-untracked (2026-05-16) 1 commit
(merged to 'next' on 2026-05-20 at f1e7ac1cbd)
+ stash: add coverage for show --include-untracked
Test coverage has been added to "git stash --include-untracked".
Will merge to 'master'.
source: <20260516183347.4323-2-pushkarkumarsingh1970@gmail.com>
* rs/trailer-fold-optim (2026-05-15) 1 commit
(merged to 'next' on 2026-05-20 at 38c9fb15c2)
+ trailer: change strbuf in-place in unfold_value()
Code simplification.
Will merge to 'master'.
source: <816be07e-2cd6-48fe-ae93-57fa0f2543ed@web.de>
* rs/use-builtin-add-overflow-explicitly-on-clang (2026-05-18) 2 commits
- use __builtin_add_overflow() in st_add() with Clang
- strbuf: use st_add3() in strbuf_grow()
Micro optimization of codepaths that compute allocation sizes carefully.
Will merge to 'next'.
source: <20260518202502.25682-1-l.s.r@web.de>
* tc/generate-configlist-fix-for-older-ninja (2026-05-15) 1 commit
- generate-configlist: collapse depfile for older Ninja
Build update.
Will merge to 'next'?
source: <20260515-toon-fix-almalinux8-v3-1-b545a0647f0f@iotcl.com>
* hn/config-typo-advice (2026-05-16) 1 commit
- config: suggest the correct form when key contains "=" in set context
"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.
Comments?
source: <pull.2302.v2.git.git.1778935976330.gitgitgadget@gmail.com>
* ja/doc-synopsis-style-again (2026-05-17) 5 commits
- doc: convert git-imap-send synopsis and options to new style
- doc: convert git-apply synopsis and options to new style
- doc: convert git-am synopsis and options to new style
- doc: convert git-grep synopsis and options to new style
- doc: convert git-bisect to synopsis style
A batch of documentation pages has been updated to use the modern
synopsis style.
Comments?
source: <pull.2117.git.1779049615.gitgitgadget@gmail.com>
* kn/refs-fsck-skip-lock-files (2026-05-17) 1 commit
- refs/files: skip lock files during consistency checks
The consistency checks for the files reference backend have been updated
to skip lock files earlier, avoiding unnecessary parsing of
intermediate files.
Will merge to 'next'.
source: <20260517-refs-fsck-skip-lock-files-v3-1-b24dfd673c7e@gmail.com>
* jt/config-lock-timeout (2026-05-17) 1 commit
- config: retry acquiring config.lock, configurable via core.configLockTimeout
Configuration file locking now retries for a short period, avoiding
failures when multiple processes attempt to update the configuration
simultaneously.
Comments?
cf. <xmqqzf1xbl4i.fsf@gitster.g>
source: <20260517132111.1014901-1-joerg@thalheim.io>
* sp/shallow-deepen-on-non-shallow-repo-fix (2026-05-11) 1 commit
(merged to 'next' on 2026-05-15 at 67dd491aae)
+ shallow: fix relative deepen on non-shallow repositories
"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.
Will merge to 'master'.
source: <20260511192044.169557-1-samo_pogacnik@t-2.net>
* ag/sequencer-remove-unused-struct-member (2026-05-11) 1 commit
(merged to 'next' on 2026-05-17 at 8553437ae1)
+ sequencer: remove todo_add_branch_context.commit
Code clean-up.
Will merge to 'master'.
cf. <agLKVn6RF4UBYd_8@pks.im>
source: <pull.2111.git.1778502113485.gitgitgadget@gmail.com>
* ps/maintenance-daemonize-lockfix (2026-05-13) 2 commits
- run-command: honor "gc.auto" for auto-maintenance
- builtin/maintenance: fix locking with "--detach"
"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..
Comments?
source: <20260513-pks-maintenance-fix-lock-with-detach-v3-0-f27a1ac82891@pks.im>
* aw/validate-proxy-url-scheme (2026-05-05) 1 commit
(merged to 'next' on 2026-05-15 at da9c1b71d7)
+ http: reject unsupported proxy URL schemes
Misspelt proxy URL (e.g., httt://...) did not trigger any warning
or failure, which has been corrected.
Will merge to 'master'.
source: <20260505091941.1825-2-aminnimaj@gmail.com>
* hn/branch-prune-merged (2026-05-13) 5 commits
- branch: add --all-remotes flag
- branch: add branch.<name>.pruneMerged opt-out
- branch: add --prune-merged <remote>
- branch: let delete_branches warn instead of error on bulk refusal
- branch: add --forked <remote>
"git branch" command learned "--prune-merged" option to remove
local branches that have already been merged to the remote-tracking
branches they track.
Comments?
source: <pull.2285.v9.git.git.1778700883.gitgitgadget@gmail.com>
* mm/diff-U-takes-no-negative-values (2026-05-12) 4 commits
(merged to 'next' on 2026-05-17 at d81439a049)
+ parse-options: clarify what "negated" means for PARSE_OPT_NONEG
+ xdiff: guard against negative context lengths
+ diff: reject negative values for -U/--unified
+ diff: reject negative values for --inter-hunk-context
The command line parser for "git diff" learned a few options take
only non-negative integers.
Will merge to 'master'.
source: <pull.2105.v2.git.1778609423.gitgitgadget@gmail.com>
* mm/git-url-parse (2026-05-01) 8 commits
(merged to 'next' on 2026-05-15 at 416deceeeb)
+ t9904: add tests for the new url-parse builtin
+ doc: describe the url-parse builtin
+ builtin: create url-parse command
+ urlmatch: define url_parse function
+ url: return URL_SCHEME_UNKNOWN instead of dying
+ url: move scheme detection to URL header/source
+ url: move url_is_local_not_ssh to url.h
+ connect: rename enum protocol to url_scheme
The internal URL parsing logic has been made accessible via a new
subcommand "git url-parse".
Will merge to 'master'.
cf. <xmqqjyt9p9pk.fsf@gitster.g>
cf. <20260512085734.GA26769@tb-raspi4>
source: <pull.1715.v3.git.git.1777699722.gitgitgadget@gmail.com>
* dk/doc-exclude-is-shared-per-repo (2026-05-12) 1 commit
(merged to 'next' on 2026-05-17 at ddc761aec6)
+ ignore: note info/exclude lives in GIT_COMMON_DIR, not GIT_DIR
Document the fact that .git/info/exclude is shared across worktrees
linked to the same repository.
Will merge to 'master'.
cf. <bea48414-217b-4860-9279-fe94e3687c28@gmail.com>
source: <ec97ad3f054e90b675f099a36a81a23bb4b2a0ed.1778620784.git.ben.knoble+github@gmail.com>
* kk/paint-down-to-common-optim (2026-05-11) 2 commits
(merged to 'next' on 2026-05-17 at 2e39c767e5)
+ commit-reach: early exit paint_down_to_common for single merge-base
+ commit-reach: introduce merge_base_flags enum
"git merge-base" optimization.
Will merge to 'master'.
source: <pull.2109.v4.git.1778504352.gitgitgadget@gmail.com>
* st/daemon-sockaddr-fixes (2026-05-14) 3 commits
- daemon: guard NULL REMOTE_PORT in execute() logging
- daemon: fix IPv6 address truncation in ip2str()
- daemon: fix IPv6 address corruption in lookup_hostname()
Correct use of sockaddr API in "git daemon".
Waiting for response(s) to review comment(s).
cf. <agGLRC1ziF5F8Okh@pks.im>
source: <pull.2300.git.git.1778773592.gitgitgadget@gmail.com>
* jc/ci-enable-expensive (2026-05-10) 2 commits
(merged to 'next' on 2026-05-15 at d258bb5e55)
+ ci: enable EXPENSIVE for contributor builds
+ Merge branch 'js/objects-larger-than-4gb-on-windows' into jc/ci-enable-expensive
Enable expensive tests to catch topics that may cause breakages on
integration branches closer to their origin in the contributor PR
builds.
Will merge to 'master'.
source: <xmqqjyta9630.fsf@gitster.g>
* kn/refs-generic-helpers (2026-05-04) 9 commits
(merged to 'next' on 2026-05-15 at 62cb4e0ce2)
+ refs: use peeled tag values in reference backends
+ refs: add peeled object ID to the `ref_update` struct
+ refs: move object parsing to the generic layer
+ update-ref: handle rejections while adding updates
+ update-ref: move `print_rejected_refs()` up
+ refs: return `ref_transaction_error` from `ref_transaction_update()`
+ refs: extract out reflog config to generic layer
+ refs: introduce `ref_store_init_options`
+ refs: remove unused typedef 'ref_transaction_commit_fn'
Refactor service routines in the ref subsystem backends.
Will merge to 'master'.
cf. <afmFmGo_Sg33Rv6V@pks.im>
cf. <87o6isqq4q.fsf@toon--20250203-5JQV3.mail-host-address-is-not-set>
source: <20260504-refs-move-to-generic-layer-v4-0-936ac2f0b1a3@gmail.com>
* ob/more-repo-config-values (2026-04-23) 8 commits
- env: move "warn_on_object_refname_ambiguity" into `struct repo_config_values`
- env: move "sparse_expect_files_outside_of_patterns" into `repo_config_values`
- env: move "core_sparse_checkout_cone" into `struct repo_config_values`
- environment: move "precomposed_unicode" into `struct repo_config_values`
- environment: move "pack_compression_level" into `struct repo_config_values`
- environment: move `zlib_compression_level` into `struct repo_config_values`
- environment: move "check_stat" into `struct repo_config_values`
- environment: move "trust_ctime" into `struct repo_config_values`
Expecting a reroll.
cf. <CAD=f0L8-_3sDGGkCzF4WA0xmUtaY_qiz__3zq5AemLgwTsqvsg@mail.gmail.com>
cf. <xmqqlddqu013.fsf@gitster.g>
source: <20260423165432.143598-1-belkid98@gmail.com>
* cc/promisor-auto-config-url-more (2026-05-19) 9 commits
- doc: promisor: improve acceptFromServer entry
- promisor-remote: auto-configure unknown remotes
- promisor-remote: trust known remotes matching acceptFromServerUrl
- promisor-remote: introduce promisor.acceptFromServerUrl
- promisor-remote: add 'local_name' to 'struct promisor_info'
- urlmatch: add url_normalize_pattern() helper
- urlmatch: change 'allow_globs' arg to bool
- t5710: simplify 'mkdir X' followed by 'git -C X init'
- Merge branch 'cc/promisor-auto-config-url' into cc/promisor-auto-config-url-more
The handling of promisor-remote protocol capability has been
loosened to allow the other side to add to the list of promisor
remotes via the promisor.acceptFromServerURL configuration
variable.
Comments?
source: <20260519153808.494105-1-christian.couder@gmail.com>
* kh/doc-log-decorate-list (2026-04-27) 2 commits
(merged to 'next' on 2026-05-15 at f740311a37)
+ doc: log: use the same delimiter in description list
+ doc: log: fix --decorate description list
Doc update.
Will merge to 'master'.
cf. <xmqqpl31np0l.fsf@gitster.g>
source: <CV_doc_log_--decorate_list.626@msgid.xyz>
* za/t2000-modernise-more (2026-04-29) 1 commit
(merged to 'next' on 2026-05-15 at 3b524d0ba5)
+ t2000: consolidate second scenario into a single test block
Test update.
Will merge to 'master'.
cf. <xmqqfr3xnofn.fsf@gitster.g>
source: <20260429103607.406339-1-zakariyahali100@gmail.com>
* hn/checkout-track-fetch (2026-05-18) 1 commit
- checkout: extend --track with a "fetch" mode to refresh start-point
"git checkout --track=..." learned to optionally fetch the branch
from the remote the new branch will work with.
Comments?
cf. <pull.2301.git.git.1778623888178.gitgitgadget@gmail.com>
source: <pull.2281.v10.git.git.1779091483321.gitgitgadget@gmail.com>
* mf/revision-max-count-oldest (2026-05-18) 1 commit
- revision.c: implement --max-count-oldest
"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.
Comments?
source: <8210d60832b9a58aa4d71fc3790e44d8989564ce.1779152064.git.mroik@delayed.space>
* mm/line-log-cleanup (2026-04-27) 3 commits
- line-log: allow non-patch diff formats with -L
- line-log: integrate -L output with the standard log-tree pipeline
- revision: move -L setup before output_format-to-diff derivation
Code clean-up.
Comments?
cf. <xmqqfr3xp98b.fsf@gitster.g>
source: <pull.2094.git.1777349126.gitgitgadget@gmail.com>
* ds/path-walk-filters (2026-05-13) 14 commits
- path-walk: support `combine` filter
- path-walk: support `object:type` filter
- path-walk: support `tree:0` filter
- t6601: tag otherwise-unreachable trees
- pack-objects: support sparse:oid filter with path-walk
- path-walk: add pl_sparse_trees to control tree pruning
- path-walk: support blob size limit filter
- backfill: die on incompatible filter options
- path-walk: support blobless filter
- path-walk: always emit directly-requested objects
- t/perf: add pack-objects filter and path-walk benchmark
- pack-objects: pass --objects with --path-walk
- t5620: make test work with path-walk var
- Merge branch 'en/backfill-fixes-and-edges' into ds/path-walk-filters
The "git pack-objects --path-walk" traversal has been integrated
with several object filters, including blobless and sparse filters.
Comments?
source: <pull.2101.v4.git.1778707135.gitgitgadget@gmail.com>
* en/ort-harden-against-corrupt-trees (2026-04-20) 5 commits
- cache-tree: fix verify_cache() to catch non-adjacent D/F conflicts
- merge-ort: abort merge when trees have duplicate entries
- merge-ort: free diff pairs queue in clear_or_reinit_internal_opts()
- merge-ort: drop unnecessary show_all_errors from collect_merge_info()
- merge-ort: propagate callback errors from traverse_trees_wrapper()
"ort" merge backend handles merging corrupt trees better by
aborting when it should.
Needs review.
source: <pull.2096.git.1776731171.gitgitgadget@gmail.com>
* pw/status-rebase-todo (2026-05-01) 2 commits
- status: improve rebase todo list parsing
- sequencer: factor out parsing of todo commands
The display of the rebase todo list in "git status" has been
improved to correctly abbreviate object IDs for more commands and
avoid misinterpreting refs as object IDs.
Needs review.
source: <cover.1777648598.git.phillip.wood@dunelm.org.uk>
* tb/pseudo-merge-bugfixes (2026-05-11) 9 commits
(merged to 'next' on 2026-05-19 at ecee155d5c)
+ pack-bitmap: prevent pattern leak on pseudo-merge re-assignment
+ Documentation: fix broken `sampleRate` in gitpacking(7)
+ pack-bitmap: reject pseudo-merge "sampleRate" of 0
+ pack-bitmap: parse commits in `find_pseudo_merge_group_for_ref()`
+ pack-bitmap: fix pseudo-merge lookup for shared commits
+ pack-bitmap: fix inverted binary search in `pseudo_merge_at()`
+ pack-bitmap-write: sort pseudo-merge commit lookup table in pack order
+ t5333: demonstrate various pseudo-merge bugs
+ t/helper: add 'test-tool bitmap write' subcommand
(this branch is used by tb/bitmap-build-performance.)
Fixes many bugs in pseudo-merge code.
Will merge to 'master'.
source: <cover.1778546804.git.me@ttaylorr.com>
* ds/fetch-negotiation-options (2026-05-19) 8 commits
- send-pack: pass negotiation config in push
- remote: add remote.*.negotiationInclude config
- fetch: add --negotiation-include option for negotiation
- negotiator: add have_sent() interface
- remote: add remote.*.negotiationRestrict config
- transport: rename negotiation_tips
- fetch: add --negotiation-restrict option
- t5516: fix test order flakiness
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.
Will merge to 'next'.
source: <pull.2085.v6.git.1779207896.gitgitgadget@gmail.com>
* en/batch-prefetch (2026-05-14) 4 commits
(merged to 'next' on 2026-05-20 at 722acf81c8)
+ grep: prefetch necessary blobs
+ builtin/log: prefetch necessary blobs for `git cherry`
+ patch-ids.h: add missing trailing parenthesis in documentation comment
+ promisor-remote: document caller filtering contract
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.
Will merge to 'master'.
cf. <0da4f159-8d4b-49e2-93c1-25aa0bf69371@gmail.com>
source: <pull.2089.v3.git.1778775928.gitgitgadget@gmail.com>
* ps/odb-in-memory (2026-04-10) 18 commits
- t/unit-tests: add tests for the in-memory object source
- odb: generic in-memory source
- odb/source-inmemory: stub out remaining functions
- odb/source-inmemory: implement `freshen_object()` callback
- odb/source-inmemory: implement `count_objects()` callback
- odb/source-inmemory: implement `find_abbrev_len()` callback
- odb/source-inmemory: implement `for_each_object()` callback
- odb/source-inmemory: convert to use oidtree
- oidtree: add ability to store data
- cbtree: allow using arbitrary wrapper structures for nodes
- odb/source-inmemory: implement `write_object_stream()` callback
- odb/source-inmemory: implement `write_object()` callback
- odb/source-inmemory: implement `read_object_stream()` callback
- odb/source-inmemory: implement `read_object_info()` callback
- odb: fix unnecessary call to `find_cached_object()`
- odb/source-inmemory: implement `free()` callback
- odb: introduce "in-memory" source
- Merge branch 'jt/odb-transaction-write' into ps/odb-in-memory
(this branch uses jt/odb-transaction-write.)
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").
Need to wait for the base topic.
source: <20260410-b4-pks-odb-source-inmemory-v3-0-22fd0fad58fe@pks.im>
* cl/conditional-config-on-worktree-path (2026-05-13) 2 commits
- config: add "worktree" and "worktree/i" includeIf conditions
- config: refactor include_by_gitdir() into include_by_path()
The [includeIf "condition"] conditional inclusion facility for
configuration files has learned to use the location of worktree
in its condition.
Will merge to 'next'?
cf. <2989eb07-2933-4b5a-9e5c-33ef9b805528@gmail.com>
source: <20260513-includeif-worktree-v4-0-f8e6212d1fba@black-desk.cn>
* ps/shift-root-in-graph (2026-04-27) 1 commit
- graph: add indentation for commits preceded by a parentless commit
In a history with more than one root commit, "git log --graph
--oneline" stuffed an unrelated commit immediately below a root
commit, which has been corrected by making the spot below a root
unavailable.
Waiting for response(s) to review comment(s).
cf. <20260513230216.GA1378627@coredump.intra.peff.net>
source: <20260427102838.44867-2-pabloosabaterr@gmail.com>
* lp/repack-propagate-promisor-debugging-info (2026-04-18) 6 commits
- repack-promisor: add missing headers
- t7703: test for promisor file content after geometric repack
- t7700: test for promisor file content after repack
- repack-promisor: preserve content of promisor files after repack
- repack-promisor add helper to fill promisor file after repack
- pack-write: add explanation to promisor file content
When fetching objects into a lazily cloned repository, .promisor
files are created with information meant to help debugging. "git
repack" has been taught to carry this information forward to
packfiles that are newly created.
Needs review.
cf. <xmqqse7xm8av.fsf@gitster.g>
source: <cover.1776384902.git.lorenzo.pegorari2002@gmail.com>
* th/promisor-quiet-per-repo (2026-04-06) 1 commit
- promisor-remote: fix promisor.quiet to use the correct repository
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.
Comments?
source: <20260406183041.783800-1-vikingtc4@gmail.com>
* jt/odb-transaction-write (2026-05-14) 7 commits
- odb/transaction: make `write_object_stream()` pluggable
- object-file: generalize packfile writes to use odb_write_stream
- object-file: avoid fd seekback by checking object size upfront
- object-file: remove flags from transaction packfile writes
- odb: update `struct odb_write_stream` read() callback
- odb/transaction: use pluggable `begin_transaction()`
- odb: split `struct odb_transaction` into separate header
(this branch is used by ps/odb-in-memory.)
ODB transaction interface is being reworked to explicitly handle
object writes.
Will merge to 'next'.
source: <20260514183740.1505171-1-jltobler@gmail.com>
* sa/cat-file-batch-mailmap-switch (2026-04-15) 1 commit
- cat-file: add mailmap subcommand to --batch-command
"git cat-file --batch" learns an in-line command "mailmap"
that lets the user toggle use of mailmap.
Will merge to 'next'?
source: <20260416033250.4327-2-siddharthasthana31@gmail.com>
* tb/incremental-midx-part-3.3 (2026-05-19) 16 commits
- repack: allow `--write-midx=incremental` without `--geometric`
- repack: introduce `--write-midx=incremental`
- repack: implement incremental MIDX repacking
- packfile: ensure `close_pack_revindex()` frees in-memory revindex
- builtin/repack.c: convert `--write-midx` to an `OPT_CALLBACK`
- repack-geometry: prepare for incremental MIDX repacking
- repack-midx: extract `repack_fill_midx_stdin_packs()`
- repack-midx: factor out `repack_prepare_midx_command()`
- midx: expose `midx_layer_contains_pack()`
- repack: track the ODB source via existing_packs
- midx: support custom `--base` for incremental MIDX writes
- midx: introduce `--no-write-chain-file` for incremental MIDX writes
- midx: use `strvec` for `keep_hashes`
- midx: build `keep_hashes` array in order
- midx: use `strset` for retained MIDX files
- midx-write: handle noop writes when converting incremental chains
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.
Will merge to 'next'.
source: <cover.1779206239.git.me@ttaylorr.com>
* jd/unpack-trees-wo-the-repository (2026-03-31) 2 commits
- unpack-trees: use repository from index instead of global
- unpack-trees: use repository from index instead of global
A handful of inappropriate uses of the_repository have been
rewritten to use the right repository structure instance in the
unpack-trees.c codepath.
Comments?
source: <pull.2258.v2.git.git.1774971267.gitgitgadget@gmail.com>
* ps/setup-wo-the-repository (2026-05-19) 18 commits
- setup: stop using `the_repository` in `init_db()`
- setup: stop using `the_repository` in `create_reference_database()`
- setup: stop using `the_repository` in `initialize_repository_version()`
- setup: stop using `the_repository` in `check_repository_format()`
- setup: stop using `the_repository` in `upgrade_repository_format()`
- setup: stop using `the_repository` in `setup_git_directory()`
- setup: stop using `the_repository` in `setup_git_directory_gently()`
- setup: stop using `the_repository` in `setup_git_env()`
- setup: stop using `the_repository` in `set_git_work_tree()`
- setup: stop using `the_repository` in `setup_work_tree()`
- setup: stop using `the_repository` in `enter_repo()`
- setup: stop using `the_repository` in `verify_non_filename()`
- setup: stop using `the_repository` in `verify_filename()`
- setup: stop using `the_repository` in `path_inside_repo()`
- setup: stop using `the_repository` in `prefix_path()`
- setup: stop using `the_repository` in `is_inside_work_tree()`
- setup: stop using `the_repository` in `is_inside_git_dir()`
- setup: replace use of `the_repository` in static functions
Many uses of the_repository has been updated to use a more
appropriate struct repository instance in setup.c codepath.
Will merge to 'next'?
source: <20260519-pks-setup-wo-the-repository-v3-0-a00d8ea8b07f@pks.im>
* kh/doc-trailers (2026-04-13) 9 commits
- doc: interpret-trailers: document comment line treatment
- doc: interpret-trailers: commit to “trailer block” term
- doc: interpret-trailers: add key format example
- doc: interpret-trailers: explain key format
- doc: interpret-trailers: explain the format after the intro
- doc: interpret-trailers: not just for commit messages
- doc: interpret-trailers: use “metadata” in Name as well
- doc: interpret-trailers: replace “lines” with “metadata”
- doc: interpret-trailers: stop fixating on RFC 822
Documentation updates.
Needs review.
cf. <xmqq1pfivfa3.fsf@gitster.g>
source: <V2_CV_doc_int-tr_key_format.613@msgid.xyz>
* ps/graph-lane-limit (2026-03-27) 3 commits
- graph: add truncation mark to capped lanes
- graph: add --graph-lane-limit option
- graph: limit the graph width to a hard-coded max
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.
Will merge to 'next'?
cf. <bdff0a5d-b738-4053-9b72-08eba88156de@kdbg.org>
source: <20260328001113.1275291-1-pabloosabaterr@gmail.com>
* jr/bisect-custom-terms-in-output (2026-05-14) 3 commits
- rev-parse: use selected alternate terms to look up refs
- bisect: print bisect terms in single quotes
- bisect: use selected alternate terms in status output
"git bisect" now uses the selected terms (e.g., old/new) more
consistently in its output.
Will merge to 'next'?
source: <20260514-bisect-terms-v4-0-b3e3cf1b06ce@schlaraffenlan.de>
* ua/push-remote-group (2026-05-03) 3 commits
- push: support pushing to a remote group
- remote: move remote group resolution to remote.c
- remote: fix sign-compare warnings in push_cas_option
"git push" learned to take a "remote group" name to push to, which
causes pushes to multiple places, just like "git fetch" would do.
Comments?
source: <20260503153402.1333220-1-usmanakinyemi202@gmail.com>
* js/parseopt-subcommand-autocorrection (2026-04-27) 11 commits
- SQUASH???
- doc: document autocorrect API
- parseopt: add tests for subcommand autocorrection
- parseopt: enable subcommand autocorrection for git-remote and git-notes
- parseopt: autocorrect mistyped subcommands
- autocorrect: provide config resolution API
- autocorrect: rename AUTOCORRECT_SHOW to AUTOCORRECT_HINT
- autocorrect: use mode and delay instead of magic numbers
- help: move tty check for autocorrection to autocorrect.c
- help: make autocorrect handling reusable
- parseopt: extract subcommand handling from parse_options_step()
The parse-options library learned to auto-correct misspelled
subcommand names.
Expecting a reroll.
cf. <xmqqcxz2tzpr.fsf@gitster.g>
source: <SY0P300MB0801677A2A1E0FD38D06A841CE2A2@SY0P300MB0801.AUSP300.PROD.OUTLOOK.COM>
* jc/neuter-sideband-post-3.0 (2026-03-05) 2 commits
- sideband: delay sanitizing by default to Git v3.0
- Merge branch 'jc/neuter-sideband-fixup' into jc/neuter-sideband-post-3.0
The final step, split from earlier attempt by Dscho, to loosen the
sideband restriction for now and tighten later at Git v3.0 boundary.
On hold to help the base topic with wider exposure.
(this branch uses jc/neuter-sideband-fixup.)
source: <20260305233452.3727126-8-gitster@pobox.com>
* cs/subtree-split-recursion (2026-03-05) 3 commits
- contrib/subtree: reduce recursion during split
- contrib/subtree: functionalize split traversal
- contrib/subtree: reduce function side-effects
When processing large history graphs on Debian or Ubuntu, "git
subtree" can die with a "recursion depth reached" error.
Comments?
source: <20260305-cs-subtree-split-recursion-v2-0-7266be870ba9@howdoi.land>
* pt/fsmonitor-linux (2026-04-15) 13 commits
- fsmonitor: convert shown khash to strset in do_handle_client
- fsmonitor: add tests for Linux
- fsmonitor: add timeout to daemon stop command
- fsmonitor: close inherited file descriptors and detach in daemon
- run-command: add close_fd_above_stderr option
- fsmonitor: implement filesystem change listener for Linux
- fsmonitor: rename fsm-settings-darwin.c to fsm-settings-unix.c
- fsmonitor: rename fsm-ipc-darwin.c to fsm-ipc-unix.c
- fsmonitor: use pthread_cond_timedwait for cookie wait
- compat/win32: add pthread_cond_timedwait
- fsmonitor: fix hashmap memory leak in fsmonitor_run_daemon
- fsmonitor: fix khash memory leak in do_handle_client
- t9210, t9211: disable GIT_TEST_SPLIT_INDEX for scalar clone tests
The fsmonitor daemon has been implemented for Linux.
Will merge to 'next'?
cf. <xmqqa4u5nnxq.fsf@gitster.g>
source: <pull.2147.v15.git.git.1776259657.gitgitgadget@gmail.com>
* pw/xdiff-shrink-memory-consumption (2026-05-04) 5 commits
(merged to 'next' on 2026-05-15 at 7a867909d2)
+ xdiff: reduce the size of array
+ xprepare: simplify error handling
+ xdiff: cleanup xdl_clean_mmatch()
+ xdiff: reduce size of action arrays
+ Merge branch 'en/xdiff-cleanup-3' into pw/xdiff-shrink-memory-consumption
Shrink wasted memory in Myers diff that does not account for common
prefix and suffix removal.
Will merge to 'master'.
source: <cover.1777903579.git.phillip.wood@dunelm.org.uk>
^ permalink raw reply
* Re: [PATCH v3 00/18] setup: drop uses of `the_repository`
From: Junio C Hamano @ 2026-05-20 3:31 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Karthik Nayak, Elijah Newren, Tian Yuchen
In-Reply-To: <20260519-pks-setup-wo-the-repository-v3-0-a00d8ea8b07f@pks.im>
Patrick Steinhardt <ps@pks.im> writes:
> Changes in v3:
> - Reverse the order of the commits that refactor `is_inside_gitdir()`
> and `is_inside_work_tree()` and clarify the logic around why we do
> (or do not) have to use realpath(3p). The code is ultimately not
> changed though, we still resolve the realpath for both even though
> it's not strictly necessary to do so for the working tree.
> - Link to v2: https://patch.msgid.link/20260518-pks-setup-wo-the-repository-v2-0-6933c0f1d568@pks.im
Looking good. Let me mark the topic for 'next'.
Thanks.
^ permalink raw reply
* Re: [PATCH v5 1/1] cat-file: add mailmap subcommand to --batch-command
From: Junio C Hamano @ 2026-05-20 3:26 UTC (permalink / raw)
To: Siddharth Asthana; +Cc: git, karthik.188, christian.couder, ps, toon, jn.avila
In-Reply-To: <20260416033250.4327-2-siddharthasthana31@gmail.com>
Siddharth Asthana <siddharthasthana31@gmail.com> writes:
> git-cat-file(1)'s --batch-command works with the --use-mailmap option,
> but this option needs to be set when the process is created. This means
> we cannot change this option mid-operation.
>
> At GitLab, Gitaly keeps interacting with a long-lived git-cat-file
> process and it would be useful if --batch-command supported toggling
> mailmap dynamically on an existing process.
>
> Add a `mailmap` subcommand to --batch-command that takes a boolean
> argument (usual ways you can specify a boolean value like 'yes', 'true',
> etc., are supported). Mailmap data is loaded lazily and kept in memory,
> while a helper centralizes the one-time load path used both at startup
> and from the batch-command handler.
>
> Extend tests to cover runtime toggling, startup option interactions
> (`--mailmap`/`--no-mailmap`), accepted boolean forms, and invalid values.
>
> Signed-off-by: Siddharth Asthana <siddharthasthana31@gmail.com>
> ---
> CI: https://gitlab.com/gitlab-org/git/-/pipelines/2456596910
I do not think we have heard any comment on this iteration, and it
seems to address the points raised in the reviews in previous
rounds. Shall we mark the topic for 'next'?
Thanks.
^ permalink raw reply
* Re: What's cooking in git.git (May 2026, #04)
From: Junio C Hamano @ 2026-05-20 2:37 UTC (permalink / raw)
To: Justin Tobler; +Cc: git
In-Reply-To: <agzGKQCfc7JYOyQx@denethor>
Justin Tobler <jltobler@gmail.com> writes:
> On 26/05/18 10:32AM, Junio C Hamano wrote:
>> * jt/odb-transaction-write (2026-05-14) 7 commits
>> - odb/transaction: make `write_object_stream()` pluggable
>> - object-file: generalize packfile writes to use odb_write_stream
>> - object-file: avoid fd seekback by checking object size upfront
>> - object-file: remove flags from transaction packfile writes
>> - odb: update `struct odb_write_stream` read() callback
>> - odb/transaction: use pluggable `begin_transaction()`
>> - odb: split `struct odb_transaction` into separate header
>> (this branch is used by ps/odb-in-memory.)
>>
>> ODB transaction interface is being reworked to explicitly handle
>> object writes.
>>
>> Will merge to 'next'?
>> source: <20260514183740.1505171-1-jltobler@gmail.com>
>
> I think this series should be ready to go now. The last version
> submitted fixed the leak reported by Peff.
Great. As there is another topic that builds on it, finally seeing
the topic stabilized enough is a great thing.
Let's merge it down to 'next'.
^ permalink raw reply
* Re: What's cooking in git.git (May 2026, #04)
From: Junio C Hamano @ 2026-05-20 2:35 UTC (permalink / raw)
To: Jeff King; +Cc: Taylor Blau, git
In-Reply-To: <20260519191941.GB2269222@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, May 19, 2026 at 12:26:13PM -0400, Taylor Blau wrote:
>
>> > * tb/incremental-midx-part-3.3 (2026-04-29) 16 commits
>> [...]
>> Apologies, I didn't realize you were waiting on these until seeing this
>> WC report. I sent an extremely tiny reroll
>>
>> https://lore.kernel.org/git/cover.1779206239.git.me@ttaylorr.com/
>>
>> that addresses the two outstanding comments you linked. They are very
>> minor changes, and queueing either version of the series would be
>> equally fine IMHO.
>
> I peeked at the v4 range diff, and it looks good to me.
Thanks.
I went back to the list archive to check, because these "cf."
entries are not meant to be exhaustive and "I've addressed only
them" was a bad sign in general, but it seems that the latest round
is in very good shape.
Let's mark the topic for 'next'.
^ permalink raw reply
* Re: [PATCH v6 0/8] fetch: rework negotiation tip options
From: Junio C Hamano @ 2026-05-20 2:34 UTC (permalink / raw)
To: Matthew John Cheetham
Cc: Derrick Stolee via GitGitGadget, git, ps, Derrick Stolee
In-Reply-To: <MRWPR03MB116167F956F0616EE71F527EEC0002@MRWPR03MB11616.eurprd03.prod.outlook.com>
Matthew John Cheetham <mjcheetham@outlook.com> writes:
> On 2026-05-19 17:24, Derrick Stolee via GitGitGadget wrote:
>
>> Updates in v6
>> =============
>>
>> Corrected reviewed-by annotations in commit messages.
>>
>> Thanks, -Stolee
>>
>
> v6 look good to me!
>
> Thanks,
> Matthew
Thanks.
^ permalink raw reply
* Re: [PATCH] stash: reuse cached index entries in --patch temporary index
From: Junio C Hamano @ 2026-05-20 2:26 UTC (permalink / raw)
To: Adam Johnson via GitGitGadget
Cc: git, Thomas Gummerer, Elijah Newren, Phillip Wood, Victoria Dye,
Adam Johnson
In-Reply-To: <pull.2306.git.git.1779194605735.gitgitgadget@gmail.com>
"Adam Johnson via GitGitGadget" <gitgitgadget@gmail.com> writes:
> 2 files changed, 83 insertions(+), 6 deletions(-)
>
> diff --git a/builtin/stash.c b/builtin/stash.c
> index 32dbc97b47..48189cb9f7 100644
> --- a/builtin/stash.c
> +++ b/builtin/stash.c
> @@ -372,6 +372,57 @@ static int reset_tree(struct object_id *i_tree, int update, int reset)
> return 0;
> }
>
> +static int create_index_from_tree(const struct object_id *tree_id,
> + const char *index_path)
> +{
> + int nr_trees = 1;
> + int ret = 0;
> + struct unpack_trees_options opts;
> + struct tree_desc t[MAX_UNPACK_TREES];
> + struct tree *tree;
> + struct index_state dst_istate = INDEX_STATE_INIT(the_repository);
> + struct lock_file lock_file = LOCK_INIT;
> +
> + repo_read_index_preload(the_repository, NULL, 0);
> + if (refresh_index(the_repository->index, REFRESH_QUIET, NULL, NULL, NULL))
> + return -1;
Is this "non-zero return from refresh_index() leads to a failure"
intended? The old "git read-tree HEAD" wouldn't have cared if the
original index were unmerged, for example, but with this update, we
will see an immediate failure. There are other conditions that
refresh_index() flips its local variable has_errors on, which leads
to its non-zero return.
Since "git stash -p" is almost always invoked when the user has
unstaged modifications, I am not sure allowing refresh_index() to
notice and barf is what we want here.
^ permalink raw reply
* Re: [PATCH] stash: reuse cached index entries in --patch temporary index
From: Junio C Hamano @ 2026-05-20 2:08 UTC (permalink / raw)
To: Adam Johnson via GitGitGadget
Cc: git, Thomas Gummerer, Elijah Newren, Phillip Wood, Victoria Dye,
Adam Johnson
In-Reply-To: <pull.2306.git.git.1779194605735.gitgitgadget@gmail.com>
"Adam Johnson via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Adam Johnson <me@adamj.eu>
>
> `git stash -p` prepares the interactive selection by creating a
> temporary index at HEAD, switching `GIT_INDEX_FILE` to it, and then
> running the `add -p` machinery.
>
> That temporary index was created by running `git read-tree HEAD`. The
> resulting index had no useful cached stat data or fsmonitor-valid bits
> from the real index. When `run_add_p()` refreshed that temporary index
> before showing the first prompt, it could end up lstat(2)-ing every
> tracked file, even in a repository where `git diff` and `git restore -p`
> can use fsmonitor to avoid that work.
>
> Create the temporary index in-process instead. Use `unpack_trees()` to
> reset the real index contents to HEAD while writing the result to the
> temporary index path. For paths whose index entries already match HEAD,
> `oneway_merge()` reuses the existing cache entries, preserving their
> cached stat data and `CE_FSMONITOR_VALID` state.
Clever. As the fsmonitor_valid bit is in-core only, updating the
index in-process would be an obvious and probably the only sensible
way to preserve it.
I however have to wonder if simply replacing the external process
invocation with "git read-tree -m HEAD" (i.e., oneway merge) gives
a similar speed-up.
> This makes the refresh performed by `run_add_p()` behave like the one
> used by `git restore -p`: unchanged paths can be skipped via fsmonitor
> instead of being scanned again.
>
> In a 206k file repository with `core.fsmonitor` enabled and a one-line
> change in one file, time to first prompt dropped from 34.774 seconds to
> 0.659 seconds.
Interesting.
> diff --git a/t/t3904-stash-patch.sh b/t/t3904-stash-patch.sh
> index 90a4ff2c10..4b3241c8cd 100755
> --- a/t/t3904-stash-patch.sh
> +++ b/t/t3904-stash-patch.sh
> @@ -84,6 +84,24 @@ test_expect_success 'none of this moved HEAD' '
> verify_saved_head
> '
>
> +test_expect_success 'stash -p with unmodified tracked files present' '
> + git reset --hard &&
> + echo line1 >alpha &&
> + echo line1 >beta &&
> + git add alpha beta &&
> + git commit -m "add alpha and beta" &&
> + echo line2 >>alpha &&
> + echo y | git stash -p &&
> + echo line1 >expect &&
> + test_cmp expect alpha &&
> + test_cmp expect beta &&
> + git stash pop &&
> + printf "line1\nline2\n" >expect &&
> + test_cmp expect alpha &&
> + echo line1 >expect &&
> + test_cmp expect beta
> +'
What I read from the proposed log message is that the change is
purely about performance and should not change any behaviour. Why
do we need a new test in t/t3904? I would not have surprised if we
saw a new test in t/perf/, though.
Thanks.
^ permalink raw reply
* Re: [PATCH v3 4/8] promisor-remote: add 'local_name' to 'struct promisor_info'
From: Junio C Hamano @ 2026-05-20 0:12 UTC (permalink / raw)
To: Christian Couder
Cc: git, Patrick Steinhardt, Taylor Blau, Karthik Nayak,
Elijah Newren, Toon Claes, Christian Couder
In-Reply-To: <20260519153808.494105-5-christian.couder@gmail.com>
Christian Couder <christian.couder@gmail.com> writes:
> struct promisor_info {
> - const char *name;
> + const char *name; /* name the server advertised */
> + const char *local_name; /* name used locally (may be auto-generated) */
OK.
> @@ -449,6 +450,7 @@ struct promisor_info {
> static void promisor_info_free(struct promisor_info *p)
> {
> free((char *)p->name);
> + free((char *)p->local_name);
> free((char *)p->url);
> free((char *)p->filter);
> free((char *)p->token);
Having to cast away constness is irritating, but to the users of the
struct it may be safer to mark the members const so that they do not
touch them, perhaps. It is not a new problem with this patch but is
inherited from the existing code, so let's not worry too much about
it.
> +static const char *promisor_info_internal_name(struct promisor_info *p)
> +{
> + return p->local_name ? p->local_name : p->name;
> +}
Hmph.
> @@ -829,7 +836,7 @@ static bool promisor_store_advertised_fields(struct promisor_info *advertised,
> {
> struct promisor_info *p;
> struct string_list_item *item;
> - const char *remote_name = advertised->name;
> + const char *remote_name = promisor_info_internal_name(advertised);
Is this really a "remote_name", though? As ...
> @@ -937,7 +944,8 @@ static void filter_promisor_remote(struct repository *repo,
> /* Apply accepted remotes to the stable repo state */
> for_each_string_list_item(item, accepted_remotes) {
> struct promisor_info *info = item->util;
> - struct promisor_remote *r = repo_promisor_remote_find(repo, info->name);
> + const char *local = promisor_info_internal_name(info);
... this name "local" is "the name the thing is locally known to
us", promisor_info_local_name() might be a better name? I dunno.
I jsut found it odd that the return value of the same function is
stored in variables named "remote" and "local" at the same time ;-)
^ 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