* Re: [PATCH] sequencer: Skip copying notes for commits that disappear during rebase
From: Phillip Wood @ 2026-06-19 10:13 UTC (permalink / raw)
To: Uwe Kleine-König, Junio C Hamano; +Cc: git, Phillip Wood
In-Reply-To: <ajKimV1TDCgE-GzK@monoceros>
Hi Uwe and Junio
On 17/06/2026 14:58, Uwe Kleine-König wrote:
>
>> It is not yet clear to me if we want to _always_ discard a note from
>> a commit that would become "empty" during a rebase session (in other
>> words, a commit that becomes empty during a rebase is _always_ a
>> sign that the change it brings in is _already_ in the new base of
>> the rebase
>
> Yeah, or in a patch that was picked before.
>
>> and the necessary information the note wanted to carry to
>> the target branch is there without need to _duplicate_ it by copying
>> the note). But assuming that we want the behaviour, the code change
>> to sequencer.c looks very reasonable to me, except for one thing that
>> I am not clear about.
>
> I think given the commit goes away, it's natural that the note goes
> away, too. And to come back to your question above: I think it doesn't
> need documentation, that if a commit disappears its notes go away, too.
> But that might be subjective?!
I tend to agree with this - if we're throwing away the commit message
without asking the user I think it makes sense to do the same for the
notes. We have "--empty=ask" if the user does not want commits that
become empty to be automatically discarded.
>>> diff --git a/sequencer.c b/sequencer.c
>>> index 57855b0066ac..da2185a37c5d 100644
>>> --- a/sequencer.c
>>> +++ b/sequencer.c
>>> ...
>>> @@ -4965,7 +4965,7 @@ static int pick_one_commit(struct repository *r,
>>> return error_with_patch(r, commit,
>>> arg, item->arg_len, opts, res, !res);
>>> }
>>> - if (is_rebase_i(opts) && !res)
>>> + if (is_rebase_i(opts) && !res && !dropped_commit)
>>> record_in_rewritten(&item->commit->object.oid,
>>> peek_command(todo_list, 1));
>>
>> If we have a sequence of commits where a commit that was *not*
>> dropped is followed by a fixup commit that *is* dropped (e.g.,
>> because it became empty/redundant), wouldn't it prevent the
>> previously pending commit from being flushed to skip
>> `record_in_rewritten` entirely for the dropped fixup commit?
That's a good point - we should call flush_rewritten_pending() in that
case. Looking at the code there are some other bugs related to dropping
commits either because they become empty or the user runs "git rebase
--skip"
- If we drop the final fixup we don't cleanup the commit message
- If we drop an "edit" command then "git rebase --continue" records it
as being rewritten HEAD so we'll copy the notes to the wrong commit
- Running "git rebase --skip" causes the commit that had conflicts
to also be recorded as as being rewritten to HEAD leading to the
same issue.
> Huh, sounds possible. I wonder if that makes the change so complicated
> that my time isn't well spend working on that given that I'm not used to
> git's source code and it's better addressed by someone with deeper
> knowledge. Sounds as if we need a state signaling "Current commit is
> done".
I'm happy to take this forward and try and fix at least some of the
other bugs I've listed above. Uwe - if I don't cc you on some patches
within the next couple of weeks please feel free to send a reminder.
Thanks
Phillip
>> Wouldn't it map the note for `X` to rewritten `C`?
>>
>>> diff --git a/t/t3322-notes-rebase.sh b/t/t3322-notes-rebase.sh
>>> new file mode 100755
>>> index 000000000000..0eddde7f9961
>>> --- /dev/null
>>> +++ b/t/t3322-notes-rebase.sh
>>> @@ -0,0 +1,37 @@
>>> +#!/bin/sh
>>> +
>>> +test_description='Test notes on rebase'
>>> +
>>> +. ./test-lib.sh
>>> +
>>> +test_expect_success setup '
>>> + git init &&
>>> + git config notes.rewriteRef refs/notes/commits &&
>>> + git version > version &&
>>> + echo A > A &&
>>
>> Style. In our codebase, redirection operator sticks to the
>> redirection target without SP in between, i.e.
>>
>> git version >version &&
>> echo A >A &&
>>
>>> + git notes add -m "This is B" @ &&
>>
>> '@' is hard to read; when you refer to HEAD, please write HEAD.
>>
>>
>>> +test_expect_success 'rebase B + C on top of BD' '
>>> + git rebase @ master
>>> +'
>>> +
>>> +test_expect_success 'assert there is no note on BD' '
>>> + if git notes list branch >/tmp/lalaa; then return 1; fi
>>> +'
>>
>> Do not step outside of $TRASH_DIRECTORY without a good reason.
>
> Oh, that is a debug thing that shouldn't have made it into the patch.
>
>> Style. In our codebase, shell scripts do not use ';' and written
>> more like
>>
>> if git notes list branch >notes-list
>> then
>> return 1
>> fi
>>
>> But more importantly, if you want to make sure the command makes a
>> controlled exit (not crash), use
>>
>> test_must_fail git notes list branch
>
> Ah, I really wondered if I'm missing something because it should be
> easier to say "this command should fail".
>
> Best regards
> Uwe
^ permalink raw reply
* [PATCH v3 8/8] fetch: fixup a misaligned comment
From: Matt Hunter @ 2026-06-19 9:44 UTC (permalink / raw)
To: git; +Cc: Bence Ferdinandy, Jeff King, Junio C Hamano
In-Reply-To: <20260619094751.2996804-1-m@lfurio.us>
Signed-off-by: Matt Hunter <m@lfurio.us>
---
builtin/fetch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 3c8210d1776f..25ab8803a819 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -1793,7 +1793,7 @@ static int set_head(const struct ref *remote_refs, struct remote *remote,
strbuf_addf(&b_head, "refs/remotes/%s/HEAD", remote->name);
strbuf_addf(&b_remote_head, "refs/remotes/%s/%s", remote->name, head_name);
}
- /* make sure it's valid */
+ /* make sure it's valid */
if (!baremirror && !refs_ref_exists(refs, b_remote_head.buf)) {
result = 1;
goto cleanup;
--
2.54.0
^ permalink raw reply related
* [PATCH v3 7/8] fetch: add configuration variable fetch.followRemoteHEAD
From: Matt Hunter @ 2026-06-19 9:44 UTC (permalink / raw)
To: git; +Cc: Bence Ferdinandy, Jeff King, Junio C Hamano
In-Reply-To: <20260619094751.2996804-1-m@lfurio.us>
'fetch.followRemoteHEAD' is added as a generic setting used by all
remotes for which 'remote.<name>.followRemoteHEAD' is undefined. If
both variables are undefined, a builtin default of "create" is in
effect, matching the previous behavior.
As mentioned in the previous patch, 'fetch.followRemoteHEAD' supports
all of the values that its 'remote' counterpart does _except_
warn-if-not-$branch, due to its tighter coupling to individual remote
repositories.
This setting interacts with the do_fetch mechanism in the same way as
the previous does, but there are opportunities for improved
user-experience discussed in [1]. See the included NEEDSWORK comment as
well.
Documentation and advice messages for both of the followRemoteHEAD
variables are reworded to better capture the relationship between the
two.
The added tests assert feature parity between the two followRemoteHEAD
variables, as well as the fact that 'remote.<name>.followRemoteHEAD'
always supersedes this new configurable default.
[1]: https://lore.kernel.org/git/xmqqh5n213bw.fsf@gitster.g/
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Matt Hunter <m@lfurio.us>
---
Documentation/config/fetch.adoc | 19 ++++++
Documentation/config/remote.adoc | 21 +++----
builtin/fetch.c | 41 ++++++++++--
t/t5510-fetch.sh | 105 +++++++++++++++++++++++++++++++
4 files changed, 169 insertions(+), 17 deletions(-)
diff --git a/Documentation/config/fetch.adoc b/Documentation/config/fetch.adoc
index 04ac90912d3a..00435e9a16d9 100644
--- a/Documentation/config/fetch.adoc
+++ b/Documentation/config/fetch.adoc
@@ -126,3 +126,22 @@ the new bundle URI.
The creation token values are chosen by the provider serving the specific
bundle URI. If you modify the URI at `fetch.bundleURI`, then be sure to
remove the value for the `fetch.bundleCreationToken` value before fetching.
+
+`fetch.followRemoteHEAD`::
+ When fetching using a default refspec, this setting determines how to handle
+ differences between a fetched remote's `HEAD` and the local
+ `remotes/<name>/HEAD` symbolic-ref. Its value is one of
++
+--
+`create`;;
+ Create `remotes/<name>/HEAD` if a ref exists on the remote, but not locally.
+ An existing symbolic-ref will not be touched. This is the default value.
+`warn`;;
+ Display a warning if the remote advertises a different `HEAD` than what is
+ set locally. Behaves like "create" if the local symbolic-ref doesn't exist.
+`always`;;
+ Silently update `remotes/<name>/HEAD` whenever the remote advertises a new
+ value.
+`never`;;
+ Never create or modify the `remotes/<name>/HEAD` symbolic-ref.
+--
diff --git a/Documentation/config/remote.adoc b/Documentation/config/remote.adoc
index eb9c8a3c4884..04724bc51628 100644
--- a/Documentation/config/remote.adoc
+++ b/Documentation/config/remote.adoc
@@ -157,15 +157,12 @@ Blank values signal to ignore all previous values, allowing a reset of
the list from broader config scenarios.
remote.<name>.followRemoteHEAD::
- How linkgit:git-fetch[1] should handle updates to `remotes/<name>/HEAD`
- when fetching using the configured refspecs of a remote.
- The default value is "create", which will create `remotes/<name>/HEAD`
- if it exists on the remote, but not locally; this will not touch an
- already existing local reference. Setting it to "warn" will print
- a message if the remote has a different value than the local one;
- in case there is no local reference, it behaves like "create".
- A variant on "warn" is "warn-if-not-$branch", which behaves like
- "warn", but if `HEAD` on the remote is `$branch` it will be silent.
- Setting it to "always" will silently update `remotes/<name>/HEAD` to
- the value on the remote. Finally, setting it to "never" will never
- change or create the local reference.
+ When fetching this remote using its default refspec, this setting determines
+ how to handle differences between the remote's `HEAD` and the local
+ `remotes/<name>/HEAD` symbolic-ref. Overrides the value of
+ `fetch.followRemoteHEAD`. See `fetch.followRemoteHEAD` for a description of
+ accepted values.
++
+In addition to the values supported by `fetch.followRemoteHEAD`, this setting
+may also take on the value "warn-if-not-`$branch`", which behaves like "warn",
+but ignores the warning if the remote's `HEAD` is `remotes/<name>/$branch`.
diff --git a/builtin/fetch.c b/builtin/fetch.c
index ad63ca943c33..3c8210d1776f 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -103,6 +103,7 @@ static struct string_list negotiation_include = STRING_LIST_INIT_NODUP;
struct fetch_config {
enum display_format display_format;
+ enum follow_remote_head_settings follow_remote_head;
int all;
int prune;
int prune_tags;
@@ -174,6 +175,22 @@ static int git_fetch_config(const char *k, const char *v,
return 0;
}
+ if (!strcmp(k, "fetch.followremotehead")) {
+ if (!v)
+ return config_error_nonbool(k);
+ else if (!strcmp(v, "never"))
+ fetch_config->follow_remote_head = FOLLOW_REMOTE_NEVER;
+ else if (!strcmp(v, "create"))
+ fetch_config->follow_remote_head = FOLLOW_REMOTE_CREATE;
+ else if (!strcmp(v, "warn"))
+ fetch_config->follow_remote_head = FOLLOW_REMOTE_WARN;
+ else if (!strcmp(v, "always"))
+ fetch_config->follow_remote_head = FOLLOW_REMOTE_ALWAYS;
+ else
+ warning(_("unrecognized fetch.followRemoteHEAD value '%s' ignored"), v);
+ return 0;
+ }
+
return git_default_config(k, v, ctx, cb);
}
@@ -1698,11 +1715,13 @@ static const char *strip_refshead(const char *name){
static void set_head_advice_msg(const char *remote, const char *head_name)
{
const char message_advice_set_head[] =
- N_("Run 'git remote set-head %s %s' to follow the change, or set\n"
- "'remote.%s.followRemoteHEAD' configuration option to a different value\n"
- "if you do not want to see this message. Specifically running\n"
- "'git config set remote.%s.followRemoteHEAD warn-if-not-%s'\n"
- "will disable the warning until the remote changes HEAD to something else.");
+ N_("Run 'git remote set-head %s %s' to follow the change, or modify\n"
+ "either of the 'remote.%s.followRemoteHEAD' or 'fetch.followRemoteHEAD'\n"
+ "configuration variables to handle the situation differently.\n\n"
+
+ "Using this specific setting\n\n"
+ " git config set remote.%s.followRemoteHEAD warn-if-not-%s\n\n"
+ "will suppress the warning until the remote changes HEAD to something else.");
advise_if_enabled(ADVICE_FETCH_SET_HEAD_WARN, _(message_advice_set_head),
remote, head_name, remote, remote, head_name);
@@ -1918,8 +1937,19 @@ static int do_fetch(struct transport *transport,
goto cleanup;
}
+ /*
+ * NEEDSWORK: By the time this function executes, we have already parsed
+ * all such followRemoteHEAD values from the external configuration,
+ * potentially emitting warning messages for bogus values. Ideally, if
+ * this fetch ends up not needing to consult these values, then git would
+ * not ever output a value warning. (eg: when pulling from a URL directly -
+ * rather than a configured remote, or when a remote's followRemoteHEAD
+ * overrides the fallback fetch setting)
+ */
if (transport->remote->follow_remote_head)
follow_remote_head = transport->remote->follow_remote_head;
+ else if (config->follow_remote_head)
+ follow_remote_head = config->follow_remote_head;
else
follow_remote_head = BUILTIN_FOLLOW_REMOTE_HEAD_DFLT;
@@ -2478,6 +2508,7 @@ int cmd_fetch(int argc,
{
struct fetch_config config = {
.display_format = DISPLAY_FORMAT_FULL,
+ .follow_remote_head = FOLLOW_REMOTE_UNCONFIGURED,
.prune = -1,
.prune_tags = -1,
.show_forced_updates = 1,
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index 43190630e714..6f0ae1bdd798 100755
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -140,6 +140,16 @@ test_expect_success "fetch test remote HEAD change" '
)
'
+test_expect_success "fetch test default followRemoteHEAD never" '
+ git -C two update-ref --no-deref -d refs/remotes/origin/HEAD &&
+ test_config -C two fetch.followRemoteHEAD "never" &&
+ GIT_TRACE_PACKET=$PWD/trace.out git -C two fetch &&
+ # Confirm that we do not even ask for HEAD when we are
+ # not going to act on it.
+ test_grep ! "ref-prefix HEAD" trace.out &&
+ test_must_fail git -C two rev-parse --verify refs/remotes/origin/HEAD
+'
+
test_expect_success "fetch test followRemoteHEAD never" '
git -C two update-ref --no-deref -d refs/remotes/origin/HEAD &&
test_config -C two remote.origin.followRemoteHEAD "never" &&
@@ -150,6 +160,21 @@ test_expect_success "fetch test followRemoteHEAD never" '
test_must_fail git -C two rev-parse --verify refs/remotes/origin/HEAD
'
+test_expect_success "fetch test default followRemoteHEAD warn no change" '
+ git -C two rev-parse --verify refs/remotes/origin/other &&
+ git -C two remote set-head origin other &&
+ git -C two rev-parse --verify refs/remotes/origin/HEAD &&
+ git -C two rev-parse --verify refs/remotes/origin/main &&
+ test_config -C two fetch.followRemoteHEAD "warn" &&
+ git -C two fetch >output &&
+ echo "${SQ}HEAD${SQ} at ${SQ}origin${SQ} is ${SQ}main${SQ}," \
+ "but we have ${SQ}other${SQ} locally." >expect &&
+ test_cmp expect output &&
+ head=$(git -C two rev-parse refs/remotes/origin/HEAD) &&
+ branch=$(git -C two rev-parse refs/remotes/origin/other) &&
+ test "z$head" = "z$branch"
+'
+
test_expect_success "fetch test followRemoteHEAD warn no change" '
git -C two rev-parse --verify refs/remotes/origin/other &&
git -C two remote set-head origin other &&
@@ -165,6 +190,17 @@ test_expect_success "fetch test followRemoteHEAD warn no change" '
test "z$head" = "z$branch"
'
+test_expect_success "fetch test default followRemoteHEAD warn create" '
+ git -C two update-ref --no-deref -d refs/remotes/origin/HEAD &&
+ test_config -C two fetch.followRemoteHEAD "warn" &&
+ git -C two rev-parse --verify refs/remotes/origin/main &&
+ output=$(git -C two fetch) &&
+ test "z" = "z$output" &&
+ head=$(git -C two rev-parse refs/remotes/origin/HEAD) &&
+ branch=$(git -C two rev-parse refs/remotes/origin/main) &&
+ test "z$head" = "z$branch"
+'
+
test_expect_success "fetch test followRemoteHEAD warn create" '
git -C two update-ref --no-deref -d refs/remotes/origin/HEAD &&
test_config -C two remote.origin.followRemoteHEAD "warn" &&
@@ -176,6 +212,18 @@ test_expect_success "fetch test followRemoteHEAD warn create" '
test "z$head" = "z$branch"
'
+test_expect_success "fetch test default followRemoteHEAD warn detached" '
+ git -C two update-ref --no-deref -d refs/remotes/origin/HEAD &&
+ git -C two update-ref refs/remotes/origin/HEAD HEAD &&
+ HEAD=$(git -C two log --pretty="%H") &&
+ test_config -C two fetch.followRemoteHEAD "warn" &&
+ git -C two fetch >output &&
+ echo "${SQ}HEAD${SQ} at ${SQ}origin${SQ} is ${SQ}main${SQ}," \
+ "but we have a detached HEAD pointing to" \
+ "${SQ}${HEAD}${SQ} locally." >expect &&
+ test_cmp expect output
+'
+
test_expect_success "fetch test followRemoteHEAD warn detached" '
git -C two update-ref --no-deref -d refs/remotes/origin/HEAD &&
git -C two update-ref refs/remotes/origin/HEAD HEAD &&
@@ -188,6 +236,19 @@ test_expect_success "fetch test followRemoteHEAD warn detached" '
test_cmp expect output
'
+test_expect_success "fetch test default followRemoteHEAD warn quiet" '
+ git -C two rev-parse --verify refs/remotes/origin/other &&
+ git -C two remote set-head origin other &&
+ git -C two rev-parse --verify refs/remotes/origin/HEAD &&
+ git -C two rev-parse --verify refs/remotes/origin/main &&
+ test_config -C two fetch.followRemoteHEAD "warn" &&
+ output=$(git -C two fetch --quiet) &&
+ test "z" = "z$output" &&
+ head=$(git -C two rev-parse refs/remotes/origin/HEAD) &&
+ branch=$(git -C two rev-parse refs/remotes/origin/other) &&
+ test "z$head" = "z$branch"
+'
+
test_expect_success "fetch test followRemoteHEAD warn quiet" '
git -C two rev-parse --verify refs/remotes/origin/other &&
git -C two remote set-head origin other &&
@@ -229,6 +290,18 @@ test_expect_success "fetch test followRemoteHEAD warn-if-not-branch branch is di
test "z$head" = "z$branch"
'
+test_expect_success "fetch test default followRemoteHEAD always" '
+ git -C two rev-parse --verify refs/remotes/origin/other &&
+ git -C two remote set-head origin other &&
+ git -C two rev-parse --verify refs/remotes/origin/HEAD &&
+ git -C two rev-parse --verify refs/remotes/origin/main &&
+ test_config -C two fetch.followRemoteHEAD "always" &&
+ git -C two fetch &&
+ head=$(git -C two rev-parse refs/remotes/origin/HEAD) &&
+ branch=$(git -C two rev-parse refs/remotes/origin/main) &&
+ test "z$head" = "z$branch"
+'
+
test_expect_success "fetch test followRemoteHEAD always" '
git -C two rev-parse --verify refs/remotes/origin/other &&
git -C two remote set-head origin other &&
@@ -241,6 +314,28 @@ test_expect_success "fetch test followRemoteHEAD always" '
test "z$head" = "z$branch"
'
+test_expect_success 'per-remote followRemoteHEAD takes priority over fetch default' '
+ git -C two rev-parse --verify refs/remotes/origin/other &&
+ git -C two remote set-head origin other &&
+ git -C two rev-parse --verify refs/remotes/origin/HEAD &&
+ git -C two rev-parse --verify refs/remotes/origin/main &&
+ test_config -C two fetch.followRemoteHEAD "never" &&
+ test_config -C two remote.origin.followRemoteHEAD "always" &&
+ git -C two fetch &&
+ head=$(git -C two rev-parse refs/remotes/origin/HEAD) &&
+ branch=$(git -C two rev-parse refs/remotes/origin/main) &&
+ test "z$head" = "z$branch"
+'
+
+test_expect_success 'default followRemoteHEAD does not kick in with refspecs' '
+ git -C two remote set-head origin other &&
+ test_config -C two fetch.followRemoteHEAD always &&
+ git -C two fetch origin refs/heads/main:refs/remotes/origin/main &&
+ echo refs/remotes/origin/other >expect &&
+ git -C two symbolic-ref refs/remotes/origin/HEAD >actual &&
+ test_cmp expect actual
+'
+
test_expect_success 'followRemoteHEAD does not kick in with refspecs' '
git -C two remote set-head origin other &&
test_config -C two remote.origin.followRemoteHEAD always &&
@@ -250,6 +345,16 @@ test_expect_success 'followRemoteHEAD does not kick in with refspecs' '
test_cmp expect actual
'
+test_expect_success 'default followRemoteHEAD create does not overwrite dangling symref' '
+ test_when_finished "git -C two remote remove custom-head" &&
+ git -C two remote add -m does-not-exist custom-head ../one &&
+ test_config -C two fetch.followRemoteHEAD create &&
+ git -C two fetch custom-head &&
+ echo refs/remotes/custom-head/does-not-exist >expect &&
+ git -C two symbolic-ref refs/remotes/custom-head/HEAD >actual &&
+ test_cmp expect actual
+'
+
test_expect_success 'followRemoteHEAD create does not overwrite dangling symref' '
test_when_finished "git -C two remote remove custom-head" &&
git -C two remote add -m does-not-exist custom-head ../one &&
--
2.54.0
^ permalink raw reply related
* [PATCH v3 6/8] fetch: refactor do_fetch handling of followRemoteHEAD
From: Matt Hunter @ 2026-06-19 9:44 UTC (permalink / raw)
To: git; +Cc: Bence Ferdinandy, Jeff King, Junio C Hamano
In-Reply-To: <20260619094751.2996804-1-m@lfurio.us>
Update enum follow_remote_head_settings to include the value
FOLLOW_REMOTE_UNCONFIGURED as the new zero-initialized value for
followRemoteHEAD. This will allow us to distinguish between the
variable being unset vs. explicitly set to 'create', which is ultimately
the system default. The unnecessary indentation is removed.
The do_fetch function is likewise updated to perform its own decision
making to determine the effective followRemoteHEAD mode, falling back to
the system default if necessary. This will enable the next patch to
introduce a user-configurable default.
Function set_head now accepts the mode as an argument rather than only
considering the value defined by the remote.
The use of the 'warn-if-not-$branch' value is awkward in the context of
a global default, since the branches will differ between individual
remotes. For this reason, it's left out of this scheme and handling of
the no_warn_branch variable is untouched. Since a remote-specific
value for followRemoteHEAD takes priority, we can assume that if
remote->no_warn_branch is set, then the remote is also asserting
FOLLOW_REMOTE_WARN as the effective operating mode, and it will be
honored by do_fetch.
Signed-off-by: Matt Hunter <m@lfurio.us>
---
builtin/fetch.c | 14 ++++++++++----
remote.h | 14 ++++++++------
2 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 1036e8edbc59..ad63ca943c33 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -1730,12 +1730,12 @@ static void warn_set_head(const char *remote, const char *head_name,
strbuf_release(&buf_prefix);
}
-static int set_head(const struct ref *remote_refs, struct remote *remote)
+static int set_head(const struct ref *remote_refs, struct remote *remote,
+ int follow_remote_head)
{
int result = 0, create_only, baremirror, was_detached;
struct strbuf b_head = STRBUF_INIT, b_remote_head = STRBUF_INIT,
b_local_head = STRBUF_INIT;
- int follow_remote_head = remote->follow_remote_head;
const char *no_warn_branch = remote->no_warn_branch;
char *head_name = NULL;
struct ref *ref, *matches;
@@ -1902,6 +1902,7 @@ static int do_fetch(struct transport *transport,
struct ref_update_display_info_array display_array = { 0 };
struct strmap rejected_refs = STRMAP_INIT;
int summary_width = 0;
+ int follow_remote_head;
if (tags == TAGS_DEFAULT) {
if (transport->remote->fetch_tags == 2)
@@ -1917,6 +1918,11 @@ static int do_fetch(struct transport *transport,
goto cleanup;
}
+ if (transport->remote->follow_remote_head)
+ follow_remote_head = transport->remote->follow_remote_head;
+ else
+ follow_remote_head = BUILTIN_FOLLOW_REMOTE_HEAD_DFLT;
+
if (rs->nr) {
refspec_ref_prefixes(rs, &transport_ls_refs_options.ref_prefixes);
} else {
@@ -1925,7 +1931,7 @@ static int do_fetch(struct transport *transport,
if (transport->remote->fetch.nr) {
refspec_ref_prefixes(&transport->remote->fetch,
&transport_ls_refs_options.ref_prefixes);
- if (transport->remote->follow_remote_head != FOLLOW_REMOTE_NEVER)
+ if (follow_remote_head != FOLLOW_REMOTE_NEVER)
do_set_head = 1;
}
if (branch && branch_has_merge_config(branch) &&
@@ -2132,7 +2138,7 @@ static int do_fetch(struct transport *transport,
* Way too many cases where this can go wrong so let's just
* ignore errors and fail silently for now.
*/
- set_head(remote_refs, transport->remote);
+ set_head(remote_refs, transport->remote, follow_remote_head);
}
cleanup:
diff --git a/remote.h b/remote.h
index 54b17e4b028b..72a54d84ad51 100644
--- a/remote.h
+++ b/remote.h
@@ -62,12 +62,14 @@ struct remote_state {
void remote_state_clear(struct remote_state *remote_state);
struct remote_state *remote_state_new(void);
- enum follow_remote_head_settings {
- FOLLOW_REMOTE_NEVER = -1,
- FOLLOW_REMOTE_CREATE = 0,
- FOLLOW_REMOTE_WARN = 1,
- FOLLOW_REMOTE_ALWAYS = 2,
- };
+#define BUILTIN_FOLLOW_REMOTE_HEAD_DFLT FOLLOW_REMOTE_CREATE
+enum follow_remote_head_settings {
+ FOLLOW_REMOTE_UNCONFIGURED = 0,
+ FOLLOW_REMOTE_NEVER,
+ FOLLOW_REMOTE_CREATE,
+ FOLLOW_REMOTE_WARN,
+ FOLLOW_REMOTE_ALWAYS,
+};
struct remote {
struct hashmap_entry ent;
--
2.54.0
^ permalink raw reply related
* [PATCH v3 2/8] doc: explain fetchRemoteHEADWarn advice
From: Matt Hunter @ 2026-06-19 9:44 UTC (permalink / raw)
To: git; +Cc: Bence Ferdinandy, Jeff King, Junio C Hamano
In-Reply-To: <20260619094751.2996804-1-m@lfurio.us>
When the user sets 'remote.<name>.followRemoteHEAD' to
'warn[-if-not-$branch]', git-fetch will report when a fetched HEAD
disagrees with the locally-configured remote's HEAD. This additional
advice instructs the user how to deal with these warnings, but was
previously undocumented in git-config.
Signed-off-by: Matt Hunter <m@lfurio.us>
---
Documentation/config/advice.adoc | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/config/advice.adoc b/Documentation/config/advice.adoc
index 257db5891817..c3c190ba6a4f 100644
--- a/Documentation/config/advice.adoc
+++ b/Documentation/config/advice.adoc
@@ -48,6 +48,10 @@ all advice messages.
to create a local branch after the fact.
diverging::
Shown when a fast-forward is not possible.
+ fetchRemoteHEADWarn::
+ Shown when linkgit:git-fetch[1] reveals that a remote `HEAD`
+ differs from what is set locally and the user has opted into
+ receiving a warning in this situation.
fetchShowForcedUpdates::
Shown when linkgit:git-fetch[1] takes a long time
to calculate forced updates after ref updates, or to warn
--
2.54.0
^ permalink raw reply related
* [PATCH v3 5/8] fetch: return 0 on known git_fetch_config
From: Matt Hunter @ 2026-06-19 9:44 UTC (permalink / raw)
To: git; +Cc: Bence Ferdinandy, Jeff King, Junio C Hamano
In-Reply-To: <20260619094751.2996804-1-m@lfurio.us>
The git config callback for git-fetch should only forward calls to
git_default_config when an unknown key is given. Prevent this in the
case of 'fetch.output' by returning '0', as the other known keys do.
Signed-off-by: Matt Hunter <m@lfurio.us>
---
builtin/fetch.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 9a45e1e7a44d..1036e8edbc59 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -171,6 +171,7 @@ static int git_fetch_config(const char *k, const char *v,
else
die(_("invalid value for '%s': '%s'"),
"fetch.output", v);
+ return 0;
}
return git_default_config(k, v, ctx, cb);
--
2.54.0
^ permalink raw reply related
* [PATCH v3 4/8] fetch: rename function report_set_head
From: Matt Hunter @ 2026-06-19 9:44 UTC (permalink / raw)
To: git; +Cc: Bence Ferdinandy, Jeff King, Junio C Hamano
In-Reply-To: <20260619094751.2996804-1-m@lfurio.us>
Update to the slightly more obvious name 'warn_set_head', which matches
the verbiage of the followRemoteHEAD options.
Signed-off-by: Matt Hunter <m@lfurio.us>
---
builtin/fetch.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 82969e230f5a..9a45e1e7a44d 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -1707,7 +1707,7 @@ static void set_head_advice_msg(const char *remote, const char *head_name)
remote, head_name, remote, remote, head_name);
}
-static void report_set_head(const char *remote, const char *head_name,
+static void warn_set_head(const char *remote, const char *head_name,
struct strbuf *buf_prev, int updateres) {
struct strbuf buf_prefix = STRBUF_INIT;
const char *prev_head = NULL;
@@ -1787,7 +1787,7 @@ static int set_head(const struct ref *remote_refs, struct remote *remote)
if (verbosity >= 0 &&
follow_remote_head == FOLLOW_REMOTE_WARN &&
(!no_warn_branch || strcmp(no_warn_branch, head_name)))
- report_set_head(remote->name, head_name, &b_local_head, was_detached);
+ warn_set_head(remote->name, head_name, &b_local_head, was_detached);
cleanup:
free(head_name);
--
2.54.0
^ permalink raw reply related
* [PATCH v3 1/8] fetch: fixup set_head advice for warn-if-not-branch
From: Matt Hunter @ 2026-06-19 9:44 UTC (permalink / raw)
To: git; +Cc: Bence Ferdinandy, Jeff King, Junio C Hamano
In-Reply-To: <20260619094751.2996804-1-m@lfurio.us>
Specifying the word 'branch' in the command is not correct - a mismatch
with both the implementation in remote.c and the documentation.
Signed-off-by: Matt Hunter <m@lfurio.us>
---
builtin/fetch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index c1d7c672f4e0..82969e230f5a 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -1700,7 +1700,7 @@ static void set_head_advice_msg(const char *remote, const char *head_name)
N_("Run 'git remote set-head %s %s' to follow the change, or set\n"
"'remote.%s.followRemoteHEAD' configuration option to a different value\n"
"if you do not want to see this message. Specifically running\n"
- "'git config set remote.%s.followRemoteHEAD warn-if-not-branch-%s'\n"
+ "'git config set remote.%s.followRemoteHEAD warn-if-not-%s'\n"
"will disable the warning until the remote changes HEAD to something else.");
advise_if_enabled(ADVICE_FETCH_SET_HEAD_WARN, _(message_advice_set_head),
--
2.54.0
^ permalink raw reply related
* [PATCH v3 0/8] Introduce fetch.followRemoteHEAD config variable
From: Matt Hunter @ 2026-06-19 9:44 UTC (permalink / raw)
To: git; +Cc: Bence Ferdinandy, Jeff King, Junio C Hamano
In-Reply-To: <20260612055947.1499497-1-m@lfurio.us>
git-fetch presently offers some useful ways to control how remote HEAD
symbolic-refs are (or aren't) updated when fetching from remote
repositories. Namely this is done via the
'remote.<name>.followRemoteHEAD' configuration variable.
However, this setting can be somewhat painful to use if you prefer a
default other than "create" and often work with multiple different
remote repositories.
This series introduces the variable 'fetch.followRemoteHEAD', which
provides a configurable default in place of per-remote settings.
'fetch.followRemoteHEAD' functions exactly the same as the original
variable, except that it doesn't allow warning suppression via
'warn-if-not-$branch'. Given that different remotes will vary their
HEAD and set of branches independently, setting a false-positive
globally in this way doesn't make logical sense.
While it is not mentioned by any of the patches in this series, note
also that the behavior introduced by 012bc566bad7 (remote set-head: set
followRemoteHEAD to "warn" if "always") is unaffected by this series,
and this feature continues to work for only the
'remote.<name>.followRemoteHEAD' variable.
---
Hi Junio,
The changes we discussed are implemented, but I also included a last
second related fix to control flow of git-fetch config parsing.
See patch 5/8 (fetch: return 0 on known git_fetch_config),
as well as a similar line squashed into
7/8 (fetch: add configuration variable fetch.followRemoteHEAD)
Thanks.
Changes in v3:
- Produce warning when fetch.followRemoteHEAD is set to a bogus value.
- Leave NEEDSWORK comment detailing future improvements.
- Avoid calling git_default_config unnecessarily in git-fetch.
- Link to v2: https://patch.msgid.link/20260616222606.1003521-1-m@lfurio.us
Changes in v2:
- Don't die() if the value of fetch.followRemoteHEAD is unrecognized.
- Use case-sensitive matching for fetch.followRemoteHEAD values.
- Avoid the phrase "configuration option".
- Minor documentation wording changes.
- Link to v1: https://patch.msgid.link/20260612055947.1499497-1-m@lfurio.us
Matt Hunter (8):
fetch: fixup set_head advice for warn-if-not-branch
doc: explain fetchRemoteHEADWarn advice
t5510: cleanup remote in followRemoteHEAD dangling ref test
fetch: rename function report_set_head
fetch: return 0 on known git_fetch_config
fetch: refactor do_fetch handling of followRemoteHEAD
fetch: add configuration variable fetch.followRemoteHEAD
fetch: fixup a misaligned comment
Documentation/config/advice.adoc | 4 ++
Documentation/config/fetch.adoc | 19 ++++++
Documentation/config/remote.adoc | 21 +++---
builtin/fetch.c | 62 ++++++++++++++----
remote.h | 14 ++--
t/t5510-fetch.sh | 106 +++++++++++++++++++++++++++++++
6 files changed, 196 insertions(+), 30 deletions(-)
Range-diff against v2:
1: 2106228f7b98 = 1: 48b23e0e2008 fetch: fixup set_head advice for warn-if-not-branch
2: b1c58c06e0c7 = 2: a68e5edf92b7 doc: explain fetchRemoteHEADWarn advice
3: c1d11e8883e6 = 3: bfe7891e6105 t5510: cleanup remote in followRemoteHEAD dangling ref test
4: 6306c8212fc0 = 4: 8bc1e56dafca fetch: rename function report_set_head
-: ------------ > 5: 3568b03adc97 fetch: return 0 on known git_fetch_config
5: 3c7257094686 = 6: b6c919d821d0 fetch: refactor do_fetch handling of followRemoteHEAD
6: af9f99b1ceb2 ! 7: dc1e05646887 fetch: add configuration variable fetch.followRemoteHEAD
@@ Commit message
warn-if-not-$branch, due to its tighter coupling to individual remote
repositories.
+ This setting interacts with the do_fetch mechanism in the same way as
+ the previous does, but there are opportunities for improved
+ user-experience discussed in [1]. See the included NEEDSWORK comment as
+ well.
+
Documentation and advice messages for both of the followRemoteHEAD
variables are reworded to better capture the relationship between the
two.
@@ Commit message
variables, as well as the fact that 'remote.<name>.followRemoteHEAD'
always supersedes this new configurable default.
+ [1]: https://lore.kernel.org/git/xmqqh5n213bw.fsf@gitster.g/
+
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Matt Hunter <m@lfurio.us>
@@ builtin/fetch.c: static struct string_list negotiation_include = STRING_LIST_INI
int prune;
int prune_tags;
@@ builtin/fetch.c: static int git_fetch_config(const char *k, const char *v,
- "fetch.output", v);
+ return 0;
}
+ if (!strcmp(k, "fetch.followremotehead")) {
@@ builtin/fetch.c: static int git_fetch_config(const char *k, const char *v,
+ fetch_config->follow_remote_head = FOLLOW_REMOTE_WARN;
+ else if (!strcmp(v, "always"))
+ fetch_config->follow_remote_head = FOLLOW_REMOTE_ALWAYS;
++ else
++ warning(_("unrecognized fetch.followRemoteHEAD value '%s' ignored"), v);
++ return 0;
+ }
+
return git_default_config(k, v, ctx, cb);
@@ builtin/fetch.c: static const char *strip_refshead(const char *name){
advise_if_enabled(ADVICE_FETCH_SET_HEAD_WARN, _(message_advice_set_head),
remote, head_name, remote, remote, head_name);
@@ builtin/fetch.c: static int do_fetch(struct transport *transport,
+ goto cleanup;
+ }
++ /*
++ * NEEDSWORK: By the time this function executes, we have already parsed
++ * all such followRemoteHEAD values from the external configuration,
++ * potentially emitting warning messages for bogus values. Ideally, if
++ * this fetch ends up not needing to consult these values, then git would
++ * not ever output a value warning. (eg: when pulling from a URL directly -
++ * rather than a configured remote, or when a remote's followRemoteHEAD
++ * overrides the fallback fetch setting)
++ */
if (transport->remote->follow_remote_head)
follow_remote_head = transport->remote->follow_remote_head;
+ else if (config->follow_remote_head)
7: 5c80107f6488 = 8: f9555a0d5cea fetch: fixup a misaligned comment
base-commit: 95e20213faefeb95df29277c58ac1980ab68f701
--
2.54.0
^ permalink raw reply
* [PATCH v3 3/8] t5510: cleanup remote in followRemoteHEAD dangling ref test
From: Matt Hunter @ 2026-06-19 9:44 UTC (permalink / raw)
To: git; +Cc: Bence Ferdinandy, Jeff King, Junio C Hamano
In-Reply-To: <20260619094751.2996804-1-m@lfurio.us>
A later patch will introduce a new test which closely mirrors this one.
Update this test to remove the 'custom-head' remote it creates.
Otherwise, the two tests will conflict with each other, as the second
one to execute will fail to create this remote (which already exists,
thanks to the first test).
Signed-off-by: Matt Hunter <m@lfurio.us>
---
t/t5510-fetch.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index eca9a973b5cb..43190630e714 100755
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -251,6 +251,7 @@ test_expect_success 'followRemoteHEAD does not kick in with refspecs' '
'
test_expect_success 'followRemoteHEAD create does not overwrite dangling symref' '
+ test_when_finished "git -C two remote remove custom-head" &&
git -C two remote add -m does-not-exist custom-head ../one &&
test_config -C two remote.custom-head.followRemoteHEAD create &&
git -C two fetch custom-head &&
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2] Makefile: dedup archives in $(LIBS) so link recipes don't repeat them
From: Harald Nordgren @ 2026-06-19 8:00 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget; +Cc: git
In-Reply-To: <pull.2314.v2.git.git.1780610623006.gitgitgadget@gmail.com>
Hi!
I think this would be quite nice to fix for all the macOS developers
(I don't know how many we have who are active on this list), but when
running repeated tests it does take up some space on the terminal:
````
❯ git rebase --keep-base -x 'make -s && cd t && prove -j8
t345?-history*.sh && echo'
Executing: make -s && cd t && prove -j8 t345?-history*.sh && echo
GIT_VERSION=2.55.0.rc1.20.g1e31474ef6
ld: warning: ignoring duplicate libraries: 'libgit.a',
'target/release/libgitcore.a'
ld: warning: ignoring duplicate libraries: 'libgit.a',
'target/release/libgitcore.a'
t3450-history.sh ......... ok
t3453-history-fixup.sh ... ok
t3451-history-reword.sh .. ok
t3452-history-split.sh ... ok
All tests successful.
Files=4, Tests=69, 7 wallclock secs ( 0.02 usr 0.01 sys + 4.14 cusr
5.39 csys = 9.56 CPU)
Result: PASS
Executing: make -s && cd t && prove -j8 t345?-history*.sh && echo
GIT_VERSION=2.55.0.rc1.21.g498da64046
ld: warning: ignoring duplicate libraries: 'libgit.a',
'target/release/libgitcore.a'
ld: warning: ignoring duplicate libraries: 'libgit.a',
'target/release/libgitcore.a'
t3450-history.sh ......... ok
t3453-history-fixup.sh ... ok
t3451-history-reword.sh .. ok
t3452-history-split.sh ... ok
All tests successful.
Files=4, Tests=69, 7 wallclock secs ( 0.02 usr 0.01 sys + 4.16 cusr
5.41 csys = 9.60 CPU)
Result: PASS
Executing: make -s && cd t && prove -j8 t345?-history*.sh && echo
GIT_VERSION=2.55.0.rc1.22.g0050368e96
ld: warning: ignoring duplicate libraries: 'libgit.a',
'target/release/libgitcore.a'
ld: warning: ignoring duplicate libraries: 'libgit.a',
'target/release/libgitcore.a'
t3450-history.sh ......... ok
t3455-history-squash.sh .. ok
t3453-history-fixup.sh ... ok
t3451-history-reword.sh .. ok
t3452-history-split.sh ... ok
All tests successful.
Files=5, Tests=86, 7 wallclock secs ( 0.03 usr 0.01 sys + 4.89 cusr
6.36 csys = 11.29 CPU)
Result: PASS
Executing: make -s && cd t && prove -j8 t345?-history*.sh && echo
GIT_VERSION=2.55.0.rc1.23.gb86b93bda1
ld: warning: ignoring duplicate libraries: 'libgit.a',
'target/release/libgitcore.a'
ld: warning: ignoring duplicate libraries: 'libgit.a',
'target/release/libgitcore.a'
t3450-history.sh ......... ok
t3455-history-squash.sh .. ok
t3453-history-fixup.sh ... ok
t3451-history-reword.sh .. ok
t3452-history-split.sh ... ok
All tests successful.
Files=5, Tests=88, 7 wallclock secs ( 0.03 usr 0.01 sys + 5.01 cusr
6.54 csys = 11.59 CPU)
Result: PASS
Successfully rebased and updated refs/heads/rebase-fixup-fold.
```
Harald
On Fri, Jun 5, 2026 at 12:03 AM Harald Nordgren via GitGitGadget
<gitgitgadget@gmail.com> wrote:
>
> From: Harald Nordgren <haraldnordgren@gmail.com>
>
> A handful of link recipes listed archive files twice: once explicitly
> via $(filter %.a,$^) and again implicitly through $(LIBS), which
> expanded to $(filter-out %.o,$(GITLIBS)) $(EXTLIBS). On macOS the
> linker warned about the duplicates:
>
> ld: warning: ignoring duplicate libraries: 'libgit.a', 'target/release/libgitcore.a'
>
> Redefine $(LIBS) to list archive prerequisites from $^ first, then
> the rest of the library list with those archives filtered out so each
> appears only once.
>
> Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
> ---
> Makefile: drop duplicate %.a from test-helper link rule
>
> Redefine $(LIBS) to list archive prerequisites from $^ first, then the
> rest of the library list to avoid brittleness in the future.
>
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2314%2FHaraldNordgren%2Fmakefile-test-helper-dedup-libs-v2
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2314/HaraldNordgren/makefile-test-helper-dedup-libs-v2
> Pull-Request: https://github.com/git/git/pull/2314
>
> Range-diff vs v1:
>
> 1: f6166450b0 ! 1: 0ef442ea05 Makefile: drop duplicate %.a from link recipes
> @@ Metadata
> Author: Harald Nordgren <haraldnordgren@gmail.com>
>
> ## Commit message ##
> - Makefile: drop duplicate %.a from link recipes
> + Makefile: dedup archives in $(LIBS) so link recipes don't repeat them
>
> - Three link recipes list archive files twice on the link line: once
> - via $(filter %.a,$^) and again through $(LIBS), which expands to
> - $(filter-out %.o,$(GITLIBS)) $(EXTLIBS). On macOS the linker warns
> - about the duplicates:
> + A handful of link recipes listed archive files twice: once explicitly
> + via $(filter %.a,$^) and again implicitly through $(LIBS), which
> + expanded to $(filter-out %.o,$(GITLIBS)) $(EXTLIBS). On macOS the
> + linker warned about the duplicates:
>
> ld: warning: ignoring duplicate libraries: 'libgit.a', 'target/release/libgitcore.a'
>
> - Drop the redundant filter from the test-helper, fuzz-program, and
> - unit-test recipes so they match the pattern used by other link
> - recipes in the file.
> + Redefine $(LIBS) to list archive prerequisites from $^ first, then
> + the rest of the library list with those archives filtered out so each
> + appears only once.
>
> Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
>
> ## Makefile ##
> +@@ Makefile: endif
> + #
> + # where we use it as a dependency. Since we also pull object files
> + # from the dependency list, that would make each entry appear twice.
> +-LIBS = $(filter-out %.o, $(GITLIBS)) $(EXTLIBS)
> ++# Archives from $^ come first, then the rest with those archives
> ++# filtered out so each appears only once.
> ++LIBS = $(filter %.a,$^) $(filter-out $(filter %.a,$^),$(filter-out %.o,$(GITLIBS)) $(EXTLIBS))
> +
> + BASIC_CFLAGS += $(COMPAT_CFLAGS)
> + LIB_OBJS += $(COMPAT_OBJS)
> @@ Makefile: perf: all
> t/helper/test-tool$X: $(patsubst %,t/helper/%,$(TEST_BUILTINS_OBJS)) $(UNIT_TEST_DIR)/test-lib.o
>
>
>
> Makefile | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index b31ecb0756..a828a66f28 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -2503,7 +2503,9 @@ endif
> #
> # where we use it as a dependency. Since we also pull object files
> # from the dependency list, that would make each entry appear twice.
> -LIBS = $(filter-out %.o, $(GITLIBS)) $(EXTLIBS)
> +# Archives from $^ come first, then the rest with those archives
> +# filtered out so each appears only once.
> +LIBS = $(filter %.a,$^) $(filter-out $(filter %.a,$^),$(filter-out %.o,$(GITLIBS)) $(EXTLIBS))
>
> BASIC_CFLAGS += $(COMPAT_CFLAGS)
> LIB_OBJS += $(COMPAT_OBJS)
> @@ -3392,7 +3394,7 @@ perf: all
> t/helper/test-tool$X: $(patsubst %,t/helper/%,$(TEST_BUILTINS_OBJS)) $(UNIT_TEST_DIR)/test-lib.o
>
> t/helper/test-%$X: t/helper/test-%.o GIT-LDFLAGS $(GITLIBS)
> - $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(filter %.a,$^) $(LIBS)
> + $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
>
> check-sha1:: t/helper/test-tool$X
> t/helper/test-sha1.sh
> @@ -4015,13 +4017,13 @@ fuzz-all: $(FUZZ_PROGRAMS)
> $(FUZZ_PROGRAMS): %: %.o oss-fuzz/dummy-cmd-main.o $(GITLIBS) GIT-LDFLAGS
> $(QUIET_LINK)$(FUZZ_CXX) $(FUZZ_CXXFLAGS) -o $@ $(ALL_LDFLAGS) \
> -Wl,--allow-multiple-definition \
> - $(filter %.o,$^) $(filter %.a,$^) $(LIBS) $(LIB_FUZZING_ENGINE)
> + $(filter %.o,$^) $(LIBS) $(LIB_FUZZING_ENGINE)
>
> $(UNIT_TEST_PROGS): $(UNIT_TEST_BIN)/%$X: $(UNIT_TEST_DIR)/%.o $(UNIT_TEST_OBJS) \
> $(GITLIBS) GIT-LDFLAGS
> $(call mkdir_p_parent_template)
> $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) \
> - $(filter %.o,$^) $(filter %.a,$^) $(LIBS)
> + $(filter %.o,$^) $(LIBS)
>
> GIT-TEST-SUITES: FORCE
> @FLAGS='$(CLAR_TEST_SUITES)'; \
>
> base-commit: 9ac3f193c05c2237e2b14ebaa1149e9fc8a1abe0
> --
> gitgitgadget
^ permalink raw reply
* Re: [PATCH] zlib: properly clamp to uLong
From: Johannes Schindelin @ 2026-06-19 7:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin via GitGitGadget, git
In-Reply-To: <xmqqzf0rrdbp.fsf@gitster.g>
Hi Junio,
On Thu, 18 Jun 2026, Junio C Hamano wrote:
> [...]
>
> > @@ -60,7 +65,7 @@ static void zlib_post_call(git_zstream *s, int status)
> > * We track our own totals and verify only the low bits match.
> > */
> > if ((s->z.total_out & ULONG_MAX_VALUE) !=
> > - ((s->total_out + bytes_produced) & ULONG_MAX_VALUE))
> > + ((zlib_uLong_cap(s->total_out) + bytes_produced) & ULONG_MAX_VALUE))
> > BUG("total_out mismatch");
>
> Because we now clamp (not "taking lower bits of") s->total_out to a
> value between 0..4GB and store it in s->z.total_out in pre-call, let
> zlib do its thing that increments s->z.total_out modulo 4GB, and we
> clamp the s->total_out (before incrementing) the same way in post_call
> here, both sides of "!=" above even out.
Technically, the range is 0..(4GB-1), but yes, that's exactly the idea.
If we clamped bit-wise, i.e. to the lower bits as is currently done, we
would _also_ stay within that range, but we'd restrict the total size
unnecessarily in most cases (i.e. in all cases where `total_out` isn't one
less than an exact multiple of 4GB). In the worst case, we'd restrict to 0
bytes, in which case we would run into an infinite loop because zlib has
no space to work with and we'd try again and again to whittle away a chunk
of that large input.
> But the comment before this comparison that claims that "we ... verify
> only the low bits match" is a bit off the reality, I suspect.
I am afraid that the comment is still true. The thing is, we're trying to
compare the _real_ `total_out + bytes_produced` to zlib's necessarily
restricted `total_out` (we cannot change the data type of that attribute
of `struct z_stream_s`, it's not ours to change, it'll remain `uLong`
because zlib made the same mistake as Git to choose that imprecise data
type for memory size calculations). The sum `total_out + bytes_produced`
is of type `size_t`, the attribute `s->z.total_out` is of type `uLong`.
Therefore, we still need to clamp bit-wise, as the _real_ `total_out +
bytes_produced` may very well exceed the maximal value of
`s->z.total_out`, and the zlib operation will _still_ have produced the
expected number of bytes, i.e. that sanity check should _pass_.
If anything, we _could_ consider dropping that masking of `s->z.total_out`
to the maximal `unsigned long` value, seeing as `s->z.total_out` _is_ of
that data type and therefore cannot reasonably exceed that. But then,
there might emerge a zlib variant in the future that recapitulates Git's
effort to use `size_t` where `size_t` is due, and compiling/linking
against _that_ zlib variant would need this mask, otherwise the sanity
check could fail for completely bogus reasons.
So: The comment is still correct, even with the adjusted logic.
Ciao,
Johannes
>
> > @@ -68,7 +73,7 @@ static void zlib_post_call(git_zstream *s, int status)
> > */
> > if (status != Z_NEED_DICT &&
> > (s->z.total_in & ULONG_MAX_VALUE) !=
> > - ((s->total_in + bytes_consumed) & ULONG_MAX_VALUE))
> > + ((zlib_uLong_cap(s->total_in) + bytes_consumed) & ULONG_MAX_VALUE))
> > BUG("total_in mismatch");
> >
> > s->total_out += bytes_produced;
> >
> > base-commit: 7a094d68a27e321a99c8ab6b700909e503904bd9
>
^ permalink raw reply
* Re: Pinned references?
From: Patrick Steinhardt @ 2026-06-19 7:38 UTC (permalink / raw)
To: Erik Östlund; +Cc: git
In-Reply-To: <CANE2Nt_LP9odF9tVsy8di54eSH=QJxif2WQfHC+TQGGFeVcjvg@mail.gmail.com>
On Thu, Jun 18, 2026 at 08:37:26PM +0200, Erik Östlund wrote:
> I'd like to be able to express a reference together with an expected
> object ID, for example with strawman syntax like:
>
> refs/tags/v1.2.3?oid=a1b2c3d4
>
> The intended semantics would be that both the reference and object ID
> must exist, and Git should fail if the reference does not resolve to the
> specified object ID.
>
> Tags are nice because they convey human meaning. Object IDs are nice
> because they are immutable. As it is, I often have to choose between the
> two, or represent them separately in external tooling.
>
> Is there existing terminology, prior discussion, or an accepted Git-native
> approach for this kind of "ref plus expected OID" invariant? I
> searched both the Git reference documentation and the mailing list
> archives, but couldn't find what I was looking for.
You can already kind of do this:
$ git rev-parse v2.54.0
0b13e48a3a30cdfa94e8ef842e24d6045ab3d015
$ git rev-parse v2.54.0-0-g0b13e48a3
0b13e48a3a30cdfa94e8ef842e24d6045ab3d015
$ git rev-parse v2.54.0-0-g95e20213f
95e20213faefeb95df29277c58ac1980ab68f701
This is described under gitrevisions(7), `<describeOutput>`. The only
gotcha is that this format will not verify that the tag and the object
ID actually match. But other than that it gives you the ability to have
both the human-readable name and the machine-readable commit ID in
there.
As said, we don't verify that those two revisions actually match. So in
the case where they don't the result is certainly going to be lots of
confusion. It certainly is one of the more surprising syntaxes that we
have in Git.
Patrick
^ permalink raw reply
* Re: [PATCH v5 2/2] graph: indent visual root in graph
From: Kristofer Karlsson @ 2026-06-19 7:34 UTC (permalink / raw)
To: Jeff King
Cc: Pablo Sabater, git, ayu.chandekar, chandrapratap3519,
christian.couder, gitster, jltobler, karthik.188, phillip.wood,
siddharthasthana31
In-Reply-To: <20260618160504.GA818042@coredump.intra.peff.net>
On Thu, 18 Jun 2026 at 18:05, Jeff King <peff@peff.net> wrote:
>
> Thanks for looking into it. I meant to also cc the Kristofer, the author
> of dd4bc01c0a, for any thoughts (adding him now).
>
Thanks for the CC. I took a look at how this interacts with my
change.
dd4bc01c0a doesn't hurt here I think, but future followup changes
might. From what I can tell --graph triggers topo_order, so
the walk mode is either REV_WALK_TOPO or REV_WALK_LIMITED
and the prio_queue change only applies to REV_WALK_STREAMING.
That said, graph_peek_next_visible() reaching directly into
revs->commits feels fragile -- especially if we drop revs->commits
in the future. One option would be to add a thin abstraction in
revision.c that dispatches per walk mode, something like:
int revision_has_more_commits(struct rev_info *revs)
{
if (revs->topo_walk_info)
return revs->topo_walk_info->topo_queue.nr > 0;
return revs->commits != NULL;
}
struct commit *revision_peek_next_commit(struct rev_info *revs)
{
if (revs->topo_walk_info)
return prio_queue_peek(&revs->topo_walk_info->topo_queue);
if (revs->commits)
return revs->commits->item;
return NULL;
}
That way graph.c does not need to know which data structure the
walker uses, and if the internals change later the API adapts in
one place.
This would perhaps be an intermediate safety net -- once we have
fully rolled it out, those functions could be removed again.
As for the multi-element peek question, I think I would either opt
for draining into a buffer if it's really needed, though when looking
at the code here I think multi-element peeking is not truly needed.
It seems like the logic just checks if there is at least another
element after the peek, but it does not try to read the actual value,
so we can just check the queue size instead.
Thanks,
Kristofer
^ permalink raw reply
* Re: git-2.55.0-rc1 t4216 broken TAP failures on non-x86 arch
From: Patrick Steinhardt @ 2026-06-19 7:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Todd Zullinger, git, Taylor Blau
In-Reply-To: <xmqqeci3nz7h.fsf@gitster.g>
On Thu, Jun 18, 2026 at 05:36:18PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > ... But since 389c83025d (t:
> > let prove fail when parsing invalid TAP output, 2026-06-04) it will
> > cause a test failure.
>
> Thanks. That was the piece I was missing.
I've sent a patch via [1]. Thanks!
Patrick
[1]: <20260619-pks-t4216-drop-unused-prereq-v1-1-2ce0d7bea088@pks.im>
^ permalink raw reply
* [PATCH] t4216: fix no-op test that breaks TAP output
From: Patrick Steinhardt @ 2026-06-19 7:20 UTC (permalink / raw)
To: git; +Cc: Todd Zullinger, Taylor Blau, Junio C Hamano, Jeff King
In t4216 we have have a prerequisite that is active in case the system's
`char` type is signed by default. This prerequisite isn't really used by
anything though: while it is used to guard one of our tests, that
specific test is essentially a no-op. So all this infrastructure does is
to provide some debugging hint to a reader that pays a lot of attention.
Besides that, the way we set up the prerequisite also results in broken
TAP output on systems where `char` is unsigned by default: we use
`test_cmp()` to diff two files outside of of any test body, and if the
files differ we enable the prerequisite. If so, the call to `test_cmp()`
would also print output, and that output is of course not valid TAP
output.
That wasn't a problem before 389c83025d (t: let prove fail when parsing
invalid TAP output, 2026-06-04), because our TAP parser was configured
to be lenient. But starting with that commit, t4216 is now failing on
systems with unsigned chars.
Drop the whole infrastructure. The prerequisite is not used anywhere
else, and the only location where it's used doesn't really provide much
value.
Reported-by: Todd Zullinger <tmz@pobox.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
Hi,
as reported in [1]. Thanks!
Patrick
<20260617220330.n6byiFQr@teonanacatl.net>
---
t/t4216-log-bloom.sh | 21 ---------------------
1 file changed, 21 deletions(-)
diff --git a/t/t4216-log-bloom.sh b/t/t4216-log-bloom.sh
index 1064990de3..16bc39c359 100755
--- a/t/t4216-log-bloom.sh
+++ b/t/t4216-log-bloom.sh
@@ -569,27 +569,6 @@ test_expect_success 'set up repo with high bit path, version 1 changed-path' '
git -C highbit1 commit-graph write --reachable --changed-paths
'
-test_expect_success 'setup check value of version 1 changed-path' '
- (
- cd highbit1 &&
- echo "52a9" >expect &&
- get_first_changed_path_filter >actual
- )
-'
-
-# expect will not match actual if char is unsigned by default. Write the test
-# in this way, so that a user running this test script can still see if the two
-# files match. (It will appear as an ordinary success if they match, and a skip
-# if not.)
-if test_cmp highbit1/expect highbit1/actual
-then
- test_set_prereq SIGNED_CHAR_BY_DEFAULT
-fi
-test_expect_success SIGNED_CHAR_BY_DEFAULT 'check value of version 1 changed-path' '
- # Only the prereq matters for this test.
- true
-'
-
test_expect_success 'setup make another commit' '
# "git log" does not use Bloom filters for root commits - see how, in
# revision.c, rev_compare_tree() (the only code path that eventually calls
---
base-commit: 95e20213faefeb95df29277c58ac1980ab68f701
change-id: 20260619-pks-t4216-drop-unused-prereq-5793107a0249
^ permalink raw reply related
* Re: [PATCH v2 7/8] refs: fix recursing `get_main_ref_store()` with "onbranch" config
From: Patrick Steinhardt @ 2026-06-19 6:25 UTC (permalink / raw)
To: Jeff King; +Cc: git, Karthik Nayak
In-Reply-To: <20260618164035.GA1218204@coredump.intra.peff.net>
On Thu, Jun 18, 2026 at 12:40:35PM -0400, Jeff King wrote:
> On Mon, Jun 15, 2026 at 03:56:53PM +0200, Patrick Steinhardt wrote:
[snip]
> I'd expect the ref database config (like the ref format) to be read not
> through the regular config subsystem, but via read_repository_format()
> and friends. And while that does build on the regular config code, it
> should never enable includes at all. So includeIf.onbranch:foo.path is
> just another uninteresting config key to it.
This feels rather painful though, as we'd now have to do this for every
single backend that we know about. Also, I think not enabling includes
is an overly broad fix: there isn't any reason why "includeif.gitdir"
and all the other conditions shouldn't apply. We really only want to
disable "onbranch".
[snip]
> > The consequence is that we have recursion:
> >
> > 1. We call `get_main_ref_store()`.
> >
> > 2. We don't yet have a reference store, so we call `ref_store_init()`.
> >
> > 3. We parse the configuration required for the reference store.
> >
> > 4. We eventually end up in `include_by_branch()`.
> >
> > 5. We have already configured the reference storage format, so we end
> > up calling `get_main_ref_store()` again.
>
> Ah, the culprit seems to be ref_store_init() calling into the regular
> config parser via repo_settings_get_log_all_ref_updates(). But that
> feels weird to me. Either:
>
> 1. It is application config that should not be something we need to
> load in order to initialize the backend. We could lazy-load it
> later, or rely on higher level code to set the option.
I actually tried lazy-loading, but I found it to be quite painful
overall, as the above setting isn't the only one we use. The reftable
backend for example has a bunch of additional settings that it reads.
We could of course start lazy-loading all of these. But that may not
work for future backends that really _need_ to parse some configuration
at initiation time.
> 2. It is crucial to the ref backend functioning, in which case we
> ought to be reading it alongside core.repositoryFormatVersion, etc.
I think ideally, we'd have a way to read the repository configuration
that explicitly disables parsing includes. We could for example extend
`struct config_options` to have a new "ignore_refdb" toggle then
explicitly use that in the reference backends.
I'll give that a try.
Patrick
^ permalink raw reply
* Re: [PATCH] help: prompt user to run corrected command on typo
From: Jishnu C K @ 2026-06-19 6:05 UTC (permalink / raw)
To: Justin Tobler; +Cc: git, gitster
In-Reply-To: <ajQuqTB580gqNP8D@denethor>
On Thu, Jun 18, 2026, Justin Tobler wrote:
> Isn't this already possible via setting `help.autoCorrect=prompt` in the
> config?
Thank you for the review.
You're right that `help.autocorrect=prompt` exists and is similar.
Our change differs in two ways:
1. No configuration needed. The existing prompt mode requires the user
to explicitly set `help.autocorrect=prompt`. Most users are unaware
of this option, so they see a suggestion and must retype the full
command manually. Our change makes the interactive prompt the
default behaviour when stdin and stderr are a terminal.
2. The prompt includes the original arguments. `help.autocorrect=prompt`
shows only:
Run 'checkout' instead [y/N]?
Our prompt shows the full corrected invocation:
Did you mean 'git checkout neo'? [y/N]
This lets the user confirm exactly what will run, including their
original arguments, before pressing 'y'.
If the consensus is that the default should remain non-interactive,
we are happy to rework this as an improvement to the existing
`autocorrect=prompt` mode (showing args in the prompt) with
documentation updates to make the option more discoverable.
--
Jishnu C K
^ permalink raw reply
* [PATCH v3 5/5] SubmittingPatches: note that trailer order matters
From: kristofferhaugsbakk @ 2026-06-19 5:44 UTC (permalink / raw)
To: git; +Cc: Kristoffer Haugsbakk, Patrick Steinhardt, Junio C Hamano
In-Reply-To: <V3_CV_SubPatches_trailers.9ec@msgid.xyz>
From: Kristoffer Haugsbakk <code@khaugsbakk.name>
It matters where you put new trailers: they should be added in
chronological order, and each person who passes on a patch should add
their s-o-b last. You are signing off on the patch as well as the whole
message up to that point.
This also makes it clear who added what:
Acked-by: The Reviewer <r@example.org>
Signed-off-by: The Contributor <c@example.org>
Acked-by: The (Late) Reviewer <late@example.org>
Signed-off-by: The Maintainer <m@example.org>
The first ack was added by the contributor and the second one was added
by the maintainer.
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---
Notes (series):
v2:
• Mention this in both the DCO section (new) as well as the trailers
section
• Emphasize and lead with chronological order and let everything
fall in place according to that
• https://lore.kernel.org/git/xmqq8q8mt4eo.fsf@gitster.g/
• Msg: Drop “the the”; one is enough
Documentation/SubmittingPatches | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 125bc0a2d63..56706e55ea1 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -427,6 +427,10 @@ D-C-O. Indeed you are encouraged to do so. Do not forget to
place an in-body "From: " line at the beginning to properly attribute
the change to its true author (see (2) above).
+Place this `Signed-off-by:` trailer at the end, after trailers added by
+others and after other trailers added by you; see
+<<commit-trailers,Commit trailers>> below ("chronological order").
+
This procedure originally came from the Linux kernel project, so our
rule is quite similar to theirs, but what exactly it means to sign-off
your patch differs from project to project, so it may be different
@@ -487,6 +491,12 @@ particular are not used in this project.
Only capitalize the very first letter of the trailer, i.e. favor
`Signed-off-by:` over `Signed-Off-By:` and `Acked-by:` over `Acked-By:`.
+As mentioned under <<dco,DCO>> above, trailers are added in
+chronological order; one person might sign-off on a patch and send it to
+someone else, who then in turn adds her own sign-off. Further, any
+trailers that you add beyond your sign-off should come before that
+sign-off. That makes it clear what trailers which person added.
+
[[ai]]
=== Use of Artificial Intelligence (AI)
--
2.54.0.22.g9e26862b904
^ permalink raw reply related
* [PATCH v3 4/5] SubmittingPatches: be consistent with trailer markup
From: kristofferhaugsbakk @ 2026-06-19 5:44 UTC (permalink / raw)
To: git; +Cc: Kristoffer Haugsbakk, Patrick Steinhardt
In-Reply-To: <V3_CV_SubPatches_trailers.9ec@msgid.xyz>
From: Kristoffer Haugsbakk <code@khaugsbakk.name>
The rest of this section and (most importantly) the list has decided to
use `<key>:`. So let’s use backticks (`) and a colon (:) throughout the
document.
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---
Documentation/SubmittingPatches | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 5b4ab93543c..125bc0a2d63 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -374,7 +374,7 @@ or, on an older version of Git without support for --pretty=reference:
....
[[sign-off]]
-=== Certify your work by adding your `Signed-off-by` trailer
+=== Certify your work by adding your `Signed-off-by:` trailer
To improve tracking of who did what, we ask you to certify that you
wrote the patch or have the right to pass it on under the same license
@@ -411,7 +411,7 @@ d. I understand and agree that this project and the contribution
this project or the open source license(s) involved.
____
-you add a "Signed-off-by" trailer to your commit, that looks like
+you add a `Signed-off-by:` trailer to your commit, that looks like
this:
....
@@ -421,7 +421,7 @@ this:
This line can be added by Git if you run the git-commit command with
the -s option.
-Notice that you can place your own `Signed-off-by` trailer when
+Notice that you can place your own `Signed-off-by:` trailer when
forwarding somebody else's patch with the above rules for
D-C-O. Indeed you are encouraged to do so. Do not forget to
place an in-body "From: " line at the beginning to properly attribute
@@ -433,7 +433,7 @@ your patch differs from project to project, so it may be different
from that of the project you are accustomed to.
[[real-name]]
-Please use a known identity in the `Signed-off-by` trailer, since we cannot
+Please use a known identity in the `Signed-off-by:` trailer, since we cannot
accept anonymous contributions. It is common, but not required, to use some form
of your real name. We realize that some contributors are not comfortable doing
so or prefer to contribute under a pseudonym or preferred name and we can accept
@@ -485,7 +485,7 @@ Other projects might regularly refer to other kinds of data, like
particular are not used in this project.
Only capitalize the very first letter of the trailer, i.e. favor
-"Signed-off-by" over "Signed-Off-By" and "Acked-by:" over "Acked-By".
+`Signed-off-by:` over `Signed-Off-By:` and `Acked-by:` over `Acked-By:`.
[[ai]]
=== Use of Artificial Intelligence (AI)
@@ -607,7 +607,7 @@ Here is a link:MyFirstContribution.html#v2-git-send-email[step-by-step guide] on
how to submit updated versions of a patch series.
If your log message (including your name on the
-`Signed-off-by` trailer) is not writable in ASCII, make sure that
+`Signed-off-by:` trailer) is not writable in ASCII, make sure that
you send off a message in the correct encoding.
WARNING: Be wary of your MUAs word-wrap
@@ -627,7 +627,7 @@ previously sent.
The `git format-patch` command follows the best current practice to
format the body of an e-mail message. At the beginning of the
patch should come your commit message, ending with the
-`Signed-off-by` trailers, and a line that consists of three dashes,
+`Signed-off-by:` trailers, and a line that consists of three dashes,
followed by the diffstat information and the patch itself. If
you are forwarding a patch from somebody else, optionally, at
the beginning of the e-mail message just before the commit
--
2.54.0.22.g9e26862b904
^ permalink raw reply related
* [PATCH v3 3/5] SubmittingPatches: document Based-on-patch-by trailer
From: kristofferhaugsbakk @ 2026-06-19 5:44 UTC (permalink / raw)
To: git; +Cc: Kristoffer Haugsbakk, Patrick Steinhardt
In-Reply-To: <V3_CV_SubPatches_trailers.9ec@msgid.xyz>
From: Kristoffer Haugsbakk <code@khaugsbakk.name>
This trailer comes up often enough and the use case is not fully covered
by the other trailers here. For example, it is sometimes better to use
this trailer instead of `Co-authored-by:`.
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---
Notes (series):
v2:
• Do *not* say *without sign-off*; do mention the precondition that
it is signed off, and cover the case when the patch author did not
sign off on it
• https://lore.kernel.org/git/xmqqse6tnho1.fsf@gitster.g/
• Drop “without a commit message”. It doesn’t seem important. A bare
patch is just a patch, not a patch plus a message.
Documentation/SubmittingPatches | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 8d946e9acb3..5b4ab93543c 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -465,6 +465,10 @@ These are the common trailers in use:
and found it to have the desired effect.
. `Co-authored-by:` is used to indicate that people exchanged drafts
of a patch before submitting it.
+. `Based-on-patch-by:` is used when someone else authored parts of the
+ patch that you are submitting. This might be relevant if someone sent
+ a patch to the mailing list with their sign-off. (Be mindful and ask
+ them to sign off on it if they did not.)
. `Helped-by:` is used to credit someone who suggested ideas for
changes without providing the precise changes in patch form.
. `Mentored-by:` is used to credit someone with helping develop a
--
2.54.0.22.g9e26862b904
^ permalink raw reply related
* [PATCH v3 2/5] SubmittingPatches: discourage common Linux trailers
From: kristofferhaugsbakk @ 2026-06-19 5:44 UTC (permalink / raw)
To: git; +Cc: Kristoffer Haugsbakk, Patrick Steinhardt
In-Reply-To: <V3_CV_SubPatches_trailers.9ec@msgid.xyz>
From: Kristoffer Haugsbakk <code@khaugsbakk.name>
The Linux Kernel regularly uses trailers (or “tags”) `Fixes` and
`Link`. Sometimes people submit patches to this project with them.
They have their use in that project but it is not clear what purpose
they would serve here.
For `Fixes`: Linux has many trees, and applying patches with
cherry-picks is common. A `Fixes` trailer in commit C2 pointing to
commit C1 helps the cherry-picker figure out that she probably needs
C2 if she wants to apply C1. See linux/d5d6281a (checkpatch: check for
missing Fixes tags, 2024-06-11):[1]
Why are stable patches encouraged to have a fixes tag? Some people
mark their stable patches as "# 5.10" etc. This is useful but a
Fixes tag is still a good idea. For example, the Fixes tag helps in
review. It helps people to not cherry-pick buggy patches without
also cherry-picking the fix.
In contrast the Git project has few trees (to my knowledge), and there
is much less need to cherry-pick fixes as opposed to either using
backmerges or rebasing all of the downstream tree’s commits on top of
git.git `master` from time to time.
This project does regularly mention what commits a patch/commit fixes,
but that is done inline in the commit message proper (cf. the trailer
block of the message).
For `Link`: These are used both to link back to the patch submission as
well as with footnotes. In contrast this project has `refs/notes/amlog`
for linking back to the patch submissions, and footnotes are only used
in the commit message proper.
† 1: Commit linux/d5d6281a has “linux” in front of it since this commit
is from the Linux Kernel, not Git. Example of a Linux tree—as well
as an example of `Link`—is [2].
Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/ [2]
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---
Notes (series):
v2: Msg: it’s “cf.”, not “c.f.”
Documentation/SubmittingPatches | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 4e8dea4eaa6..8d946e9acb3 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -476,6 +476,10 @@ While you can also create your own trailer if the situation warrants it, we
encourage you to instead use one of the common trailers in this project
highlighted above.
+Other projects might regularly refer to other kinds of data, like
+`Fixes:` and `Link:` in the Linux Kernel project, but these ones in
+particular are not used in this project.
+
Only capitalize the very first letter of the trailer, i.e. favor
"Signed-off-by" over "Signed-Off-By" and "Acked-by:" over "Acked-By".
--
2.54.0.22.g9e26862b904
^ permalink raw reply related
* [PATCH v3 1/5] SubmittingPatches: encourage trailer use for substantial help
From: kristofferhaugsbakk @ 2026-06-19 5:44 UTC (permalink / raw)
To: git; +Cc: Kristoffer Haugsbakk, Patrick Steinhardt
In-Reply-To: <V3_CV_SubPatches_trailers.9ec@msgid.xyz>
From: Kristoffer Haugsbakk <code@khaugsbakk.name>
Trailers beyond the mandatory s-o-b are regularly used based on my
last two years of reading the mailing list. Moreover, reviewers might
encourage it.[1]
This is also in line with the project crediting both commit authors and
people mentioned in trailers each release; “Nobody is THE one making
contribution”.[2]
Adding trailers is already encouraged, but in the section `send-patches`.
Let’s replace “If you like” with outright encouragement in this section
so that all trailer discussion (except s-o-b; see `sign-off` section) is
contained in this section; a link to from `send-patches` makes this
information equally visible.
Now we need to make a heading for `commit-trailers` in order for the
HTML output to make sense.
At the same time, it is important to temper this recommendation to a
significant enough contribution; in my experience beginners can be eager
to add a trailer for everyone who replies with an action point that is
followed up on.
Let’s also spell out that these trailers should follow the Git author/
committer format. One might naturally just write the name, but in that
case it will not be picked up by:
git shortlog --group=trailer:<key>
and normalization via `.mailmap` will not work.
Also introduce the list of common trailers as such. Granted, this is
already implied by the later paragraph about “create your own trailer”,
so this just frontloads this information.
† 1: https://lore.kernel.org/git/CAP8UFD0POvYDgGtEx8GBhvKkd8XzzWQsy8XxAKL9M3+uz3ka+w@mail.gmail.com/#:~:text=for%20at%20least
† 2: https://lore.kernel.org/git/xmqqzh248sy0.fsf@gitster.c.googlers.com/
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---
Notes (series):
v3: correct anchor placement
🔗 https://lore.kernel.org/git/xmqq4ij0vo8f.fsf@gitster.g/
v2:
• Msg: proofreading typos, dropped words[1]
• Msg: Avoid hyphenating for linebreaks on syllable[1]
🔗 1: https://lore.kernel.org/git/310ef65e-b6c7-4d0c-a58a-0c88257143ba@app.fastmail.com/
Documentation/SubmittingPatches | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 176567738d4..4e8dea4eaa6 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -444,7 +444,15 @@ The goal of this policy is to allow us to have sufficient information to contact
you if questions arise about your contribution.
[[commit-trailers]]
-If you like, you can put extra trailers at the end:
+=== Commit trailers
+It is polite to credit people who have helped with your work to a
+substantial enough degree. This project uses commit trailers for that,
+where the credited person is written out like a Git author, i.e. with
+both their name and their email address. Note that the threshold to
+credit someone is a judgement call, and crediting someone for simple
+review work is certainly not necessary.
+
+These are the common trailers in use:
. `Reported-by:` is used to credit someone who found the bug that
the patch attempts to fix.
@@ -562,8 +570,8 @@ when the maintainer did not heavily participate in the discussion and
instead left the review to trusted others.
Do not forget to add trailers such as `Acked-by:`, `Reviewed-by:` and
-`Tested-by:` lines as necessary to credit people who helped your
-patch, and "cc:" them when sending such a final version for inclusion.
+`Tested-by:` (see <<commit-trailers,Commit trailers>>), and "cc:" them
+when sending such a final version for inclusion.
==== `format-patch` and `send-email`
--
2.54.0.22.g9e26862b904
^ permalink raw reply related
* [PATCH v3 0/5] SubmittingPatches: update and flesh out trailer sections
From: kristofferhaugsbakk @ 2026-06-19 5:44 UTC (permalink / raw)
To: git; +Cc: Kristoffer Haugsbakk, Patrick Steinhardt
In-Reply-To: <CV_SubPatches_trailers.8f3@msgid.xyz>
From: Kristoffer Haugsbakk <code@khaugsbakk.name>
Topic name (applied) kh/submittingpatches-trailers
Topic summary: Flesh out and update the trailer sections.
All of these points have come up on the mailing list. At least for me.
And `Based-on-patch-by` is a nice-to-have documented kind of thing.
[elide “since January” from v1...]
Link to v2: https://lore.kernel.org/git/V2_CV_SubPatches_trailers.9b6@msgid.xyz/
§ Changes in v3
Patch “encourage trailer use for substantial help”: correct AsciiDoc anchor
placement.
[1/5] SubmittingPatches: encourage trailer use for substantial help
[2/5] SubmittingPatches: discourage common Linux trailers
[3/5] SubmittingPatches: document Based-on-patch-by trailer
[4/5] SubmittingPatches: be consistent with trailer markup
[5/5] SubmittingPatches: note that trailer order matters
Documentation/SubmittingPatches | 46 ++++++++++++++++++++++++++-------
1 file changed, 36 insertions(+), 10 deletions(-)
Interdiff against v2:
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index dceeb5a1817..56706e55ea1 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -447,8 +447,8 @@ identifying, and not misleading.
The goal of this policy is to allow us to have sufficient information to contact
you if questions arise about your contribution.
-=== Commit trailers
[[commit-trailers]]
+=== Commit trailers
It is polite to credit people who have helped with your work to a
substantial enough degree. This project uses commit trailers for that,
where the credited person is written out like a Git author, i.e. with
Range-diff against v2:
1: 835eb736f39 ! 1: dc75b862d73 SubmittingPatches: encourage trailer use for substantial help
@@ Commit message
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
## Documentation/SubmittingPatches ##
-@@ Documentation/SubmittingPatches: identifying, and not misleading.
- The goal of this policy is to allow us to have sufficient information to contact
+@@ Documentation/SubmittingPatches: The goal of this policy is to allow us to have sufficient information to contact
you if questions arise about your contribution.
-+=== Commit trailers
[[commit-trailers]]
-If you like, you can put extra trailers at the end:
++=== Commit trailers
+It is polite to credit people who have helped with your work to a
+substantial enough degree. This project uses commit trailers for that,
+where the credited person is written out like a Git author, i.e. with
2: 5a652b8e14d = 2: 86b9973a8e8 SubmittingPatches: discourage common Linux trailers
3: 5e53999b2e9 = 3: a142f66c3b8 SubmittingPatches: document Based-on-patch-by trailer
4: dd47fabe917 = 4: 439fa864da7 SubmittingPatches: be consistent with trailer markup
5: 726386d976b = 5: 2d133f2ad5e SubmittingPatches: note that trailer order matters
base-commit: 1ff279f3404a482a83fb04c7457e41ab26884aea
--
2.54.0.22.g9e26862b904
^ permalink raw reply related
* Re: [PATCH v3 15/17] odb/source-packed: stub out remaining functions
From: Patrick Steinhardt @ 2026-06-19 5:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Karthik Nayak, Justin Tobler
In-Reply-To: <xmqqik7frapn.fsf@gitster.g>
On Thu, Jun 18, 2026 at 10:59:32AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
>
> Just FYI (i.e. nothing wrong in this patch)
>
> > +static int odb_source_packed_write_object(struct odb_source *source UNUSED,
> > + const void *buf UNUSED,
> > + unsigned long len UNUSED,
>
> The type of this parameter will become size_t via another topic in
> flight; I prepared an evil merge to address it (otherwise winbuild
> would barf, as expected).
>
> -- >8 --
> Author: Junio C Hamano <gitster@pobox.com>
> Date: Thu Jun 18 10:49:10 2026 -0700
>
> merge-fix po/hash-object-size-t vs ps/odb-source-packed
>
> diff --git a/odb/source-packed.c b/odb/source-packed.c
> index 42c28fba0e..decc81aa52 100644
> --- a/odb/source-packed.c
> +++ b/odb/source-packed.c
> @@ -503,7 +503,7 @@ static int odb_source_packed_freshen_object(struct odb_source *source,
>
> static int odb_source_packed_write_object(struct odb_source *source UNUSED,
> const void *buf UNUSED,
> - unsigned long len UNUSED,
> + size_t len UNUSED,
> enum object_type type UNUSED,
> struct object_id *oid UNUSED,
> struct object_id *compat_oid UNUSED,
Thanks for the heads up, the change looks obviously correct to me. I'm
also happy to send a rebased version -- just give me a nudge and I'll do
that.
Patrick
^ permalink raw reply
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