* Re: [PATCH 2/3] doc: config/sideband: fix typo in adoc markup
From: Kristoffer Haugsbakk @ 2026-06-10 20:13 UTC (permalink / raw)
To: Tuomas Ahola, git
In-Reply-To: <20260610185148.23920-3-taahol@utu.fi>
> doc: config/sideband: fix typo in adoc markup
You might be able to be more precise while using the same amount of
words or less. Like:
_: fix description list delimiter
On Wed, Jun 10, 2026, at 20:51, Tuomas Ahola wrote:
> Fix a simple typo in AsciiDoc markup.
The subject of the commit might be enough here.
>
> Signed-off-by: Tuomas Ahola <taahol@utu.fi>
> ---
> Documentation/config/sideband.adoc | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>[snip]
> @@ -9,7 +9,7 @@ sideband.allowControlCharacters::
> `color`::
> Allow ANSI color sequences, line feeds and horizontal tabs,
> but mask all other control characters. This is the default.
> - `cursor:`:
> + `cursor`::
Nice find!
> Allow control sequences that move the cursor. This is
> disabled by default.
> `erase`::
> --
> 2.30.2
^ permalink raw reply
* Re: [PATCH 3/3] doc: git-config: escape erroneous adoc markup
From: Junio C Hamano @ 2026-06-10 20:07 UTC (permalink / raw)
To: Tuomas Ahola; +Cc: git
In-Reply-To: <xmqqecieuqdm.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
> Thanks.
>
> What we see in
> https://git-scm.com/docs/git-config#Documentation/git-config.txt---commentmessage
> is rather embarrasing. This would be a vast improvement ;-)
>
>> diff --git a/Documentation/git-config.adoc b/Documentation/git-config.adoc
>> index 8439ce97df..708e88cdeb 100644
>> --- a/Documentation/git-config.adoc
>> +++ b/Documentation/git-config.adoc
>> @@ -119,10 +119,10 @@ OPTIONS
>> Append a comment at the end of new or modified lines.
>> +
>> If _<message>_ begins with one or more whitespaces followed
>> -by "#", it is used as-is. If it begins with "#", a space is
>> +by "\#", it is used as-is. If it begins with "#", a space is
>> prepended before it is used. Otherwise, a string " # " (a
With this change, I wonder if this '#' on the next line gets paired
as the closing element that corresponds to the second one on the
previous line, which is not quoted hence can be taken as the opening
element? Even if the one on the second line does not get taken as a
closing element now, if a future change adds some word with '#' that
does, the second "#" on the line left unquoted by this patch would
then require quoting, no? IOW, would it be better to do this
>> -by "#", it is used as-is. If it begins with "#", a space is
>> +by "\#", it is used as-is. If it begins with "\#", a space is
so that we do not have to worry about "special cases" where it
becomes unnecessary to quote "#"s?
>> space followed by a hash followed by a space) is prepended
>> -to it. And the resulting string is placed immediately after
>> +to it. The resulting string is placed immediately after
>> the value defined for the variable. The _<message>_ must
>> not contain linefeed characters (no multi-line comments are
>> permitted).
^ permalink raw reply
* Re: [PATCH 3/3] doc: git-config: escape erroneous adoc markup
From: Junio C Hamano @ 2026-06-10 19:50 UTC (permalink / raw)
To: Tuomas Ahola; +Cc: git
In-Reply-To: <20260610185148.23920-4-taahol@utu.fi>
Tuomas Ahola <taahol@utu.fi> writes:
> Paired octothorpes are used in AsciiDoc to mark highlighted text,
> <mark> being the equivalent HTML tag. To use the symbol as a literal
> character, it can be escaped with a backslash.
>
> Do so in git-config.adoc.
>
> While at it, tweak the text slightly to make it scan better.
>
> Signed-off-by: Tuomas Ahola <taahol@utu.fi>
> ---
> Documentation/git-config.adoc | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Thanks.
What we see in
https://git-scm.com/docs/git-config#Documentation/git-config.txt---commentmessage
is rather embarrasing. This would be a vast improvement ;-)
> diff --git a/Documentation/git-config.adoc b/Documentation/git-config.adoc
> index 8439ce97df..708e88cdeb 100644
> --- a/Documentation/git-config.adoc
> +++ b/Documentation/git-config.adoc
> @@ -119,10 +119,10 @@ OPTIONS
> Append a comment at the end of new or modified lines.
> +
> If _<message>_ begins with one or more whitespaces followed
> -by "#", it is used as-is. If it begins with "#", a space is
> +by "\#", it is used as-is. If it begins with "#", a space is
> prepended before it is used. Otherwise, a string " # " (a
> space followed by a hash followed by a space) is prepended
> -to it. And the resulting string is placed immediately after
> +to it. The resulting string is placed immediately after
> the value defined for the variable. The _<message>_ must
> not contain linefeed characters (no multi-line comments are
> permitted).
^ permalink raw reply
* Re: [PATCH] commit-reach: remove get_reachable_subset()
From: Derrick Stolee @ 2026-06-10 19:29 UTC (permalink / raw)
To: Junio C Hamano, Kristofer Karlsson via GitGitGadget
Cc: git, Kristofer Karlsson
In-Reply-To: <xmqqbjdixupc.fsf@gitster.g>
On 6/10/2026 11:48 AM, Junio C Hamano wrote:
> "Kristofer Karlsson via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
>
>> get_reachable_subset() was introduced in fcb2c0769d (2018-11-02)
>> for add_missing_tags() in remote.c. tips_reachable_from_bases()
>> was added in cbfe360b14 (2023-03-20) as part of the ahead-behind
>> series. The two were never consolidated.
>
> Good finding. It is curious to see that these were from the same
> author.
I agree. In my defense, these commits are five years apart. I still
should have looked for similar code that could be reused instead of
rolling new code. (But the new code is better when a commit-graph
exists.)
The other thing that I should have done in the later commit was add
the method to the test-tool, which you do here.
>> ... Without generation numbers, some edge cases
>> may be slower with DFS instead of BFS since the date-ordered
>> prio_queue naturally stays near the top of the graph, but this
>> should not matter in practice
>
> "should not matter in practice" because...?
>
>> -- worst case both visit the full
>> graph down from the bases.
>
> And of course the worst case scenario is by definition not a typical
> case that appear in practice, so it does not make a good explanation
> for "should not matter in practice".
It's important to recognize the use cases that call each method and
to understand if it is appropriate to take these performance changes.
Both methods terminate in the case that all potential targets are
found. And that's the only case that matters, as we will walk all
reachable commits in the case of any one commit not being reachable.
Both methods avoid walking below the "minimum generation" among the
target commits.
The key opportunity here is that tips_reachable_from_bases() will
"increase" the minimum generation when it finds the current-minimum
target commit. That's a big reason why the DFS approach wins: it
has the opportunity to find those lower commits without needing to
walk _every_ commit with higher generation.
The one downside to this approach is that the DFS approach does not
take into account the commit date as a fallback when there is no
commit-graph file with computed generation numbers. When there is
no commit-graph file, then the fallback to commit date to break ties
among "generation number infinity" commits can't be used to help the
BFS search in get_reachable_subset().
And perhaps that is the critical reason for the different algorithms:
in 2018 we didn't have the commit-graph for very long so it wasn't a
reasonable expectation that we'd have one, even for large repositories.
Now? The feature is quite stable and it's easy for users to create
and maintain one. All servers are expected to use it for performance
needs. It's probably reasonable to expect that any repos where this
would matter would have one.
Thanks,
-Stolee
^ permalink raw reply
* Re: [PATCH v2] completion: hide dotfiles for selected path completion
From: Junio C Hamano @ 2026-06-10 18:56 UTC (permalink / raw)
To: Zakariyah Ali via GitGitGadget; +Cc: git, Zakariyah Ali
In-Reply-To: <pull.2311.v2.git.git.1779808987825.gitgitgadget@gmail.com>
"Zakariyah Ali via GitGitGadget" <gitgitgadget@gmail.com> writes:
> -# __git_index_files accepts 1 or 2 arguments:
> +# __git_index_files accepts 1 to 4 arguments:
> # 1: Options to pass to ls-files (required).
> # 2: A directory path (optional).
> # If provided, only files within the specified directory are listed.
> # Sub directories are never recursed. Path must have a trailing
> # slash.
> # 3: List only paths matching this path component (optional).
> +# 4: Hide paths whose first component starts with a dot if this is
> +# "hide-dotfiles" and the third argument is empty (optional).
> __git_index_files ()
> {
> - local root="$2" match="$3"
> + local root="$2" match="$3" hide_dotfiles="${4-}"
> + local hide_dotfiles_awk=0
> + if [ "$hide_dotfiles" = "hide-dotfiles" ] && [ -z "$match" ]; then
> + hide_dotfiles_awk=1
> + fi
>
> __git_ls_files_helper "$root" "$1" "${match:-?}" |
> - awk -F / -v pfx="${2//\\/\\\\}" '{
> + awk -F / -v pfx="${2//\\/\\\\}" -v hide_dotfiles="$hide_dotfiles_awk" '{
> paths[$1] = 1
> }
> END {
> for (p in paths) {
> if (substr(p, 1, 1) != "\"") {
> # No special characters, easy!
> + if (hide_dotfiles == 1 && substr(p, 1, 1) == ".")
> + continue
> print pfx p
> continue
> }
> @@ -675,8 +683,10 @@ __git_index_files ()
> # We have seen the same directory unquoted,
> # skip it.
> continue
> - else
> - print pfx p
> +
> + if (hide_dotfiles == 1 && substr(p, 1, 1) == ".")
> + continue
> + print pfx p
> }
> }
Having to repeat the same thing twice here is a bit unsatisfying,
but that is not a fault of this addition. I suspect that it would
have been simpler to patch if the original were first simplified
into something like:
for (p in paths) {
if (substr(p, 1, 1) == "\"") {
p = dequote(p);
if ((p == "") || (p in paths))
continue
}
print pfx p
}
Then the new "ah, that thing begins with a dot" logic can be added
only once and at an obvious place.
> @@ -2164,7 +2176,7 @@ _git_ls_files ()
>
> # XXX ignore options like --modified and always suggest all cached
> # files.
> - __git_complete_index_file "--cached"
> + __git_complete_index_file "--cached" hide-dotfiles
> }
In this patch, it is hard to tell from the patch what _other_ calls
to the __git_complete_index_file helper lack hide-dotfiles flag
(i.e., they are to show everything including the path that begins
with a dot). I will not try to be exhaustive, but for example
_git_add does not get hide-dotfiles but it is unclear why. The same
for _clean, _commit. But _mv does hide them. The choice seems
arbitrary and incoherent.
A few ideas (some of them may be mutually incompatible)
* Instead of "empty vs hide-dotfiles", perhaps make the 2nd option
mandatory for __git_complete_index_file, e.g., "hide-" vs
"include-" dotfiles, to make it easier to see in the patch which
ones exclude and which ones include dotfiles.
* Extend comments like we saw in the above hunk to say why we treat
files that begin with dot specially.
* Make __git_complete_index_file unconditionally hide the dotfiles
when there is no match pattern for consistency (getting rid of
the need to explay why).
^ permalink raw reply
* [PATCH 1/3] doc: config: terminate runaway lists
From: Tuomas Ahola @ 2026-06-10 18:51 UTC (permalink / raw)
To: git; +Cc: Tuomas Ahola
In-Reply-To: <20260610185148.23920-1-taahol@utu.fi>
There are many places in git-config(1) where paragraphs that should
logically come after a list are instead appended to the last item of
the list. This is a well-documented quirk of AsciiDoc, and can be
mitigated by enclosing the list in an open block:
--
* first item
* last item
--
+
New paragraph after the list.
Fix the issue accordingly.
Signed-off-by: Tuomas Ahola <taahol@utu.fi>
---
Documentation/config.adoc | 4 +++-
Documentation/config/promisor.adoc | 2 ++
Documentation/config/safe.adoc | 2 ++
Documentation/git-config.adoc | 2 ++
4 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/Documentation/config.adoc b/Documentation/config.adoc
index dcea3c0c15..fc48c1c461 100644
--- a/Documentation/config.adoc
+++ b/Documentation/config.adoc
@@ -276,13 +276,15 @@ boolean::
When a variable is said to take a boolean value, many
synonyms are accepted for 'true' and 'false'; these are all
case-insensitive.
-
++
+--
true;; Boolean true literals are `yes`, `on`, `true`,
and `1`. Also, a variable defined without `= <value>`
is taken as true.
false;; Boolean false literals are `no`, `off`, `false`,
`0` and the empty string.
+--
+
When converting a value to its canonical form using the `--type=bool` type
specifier, 'git config' will ensure that the output is "true" or
diff --git a/Documentation/config/promisor.adoc b/Documentation/config/promisor.adoc
index b0fa43b839..39af63dcb8 100644
--- a/Documentation/config/promisor.adoc
+++ b/Documentation/config/promisor.adoc
@@ -63,11 +63,13 @@ If one of these field names (e.g., "token") is being checked for an
advertised promisor remote (e.g., "foo"), three conditions must be met
for the check of this specific field to pass:
+
+--
1. The corresponding local configuration (e.g., `remote.foo.token`)
must be set.
2. The server must advertise the "token" field for remote "foo".
3. The value of the locally configured `remote.foo.token` must exactly
match the value advertised by the server for the "token" field.
+--
+
If any of these conditions is not met for any field name listed in
`promisor.checkFields`, the advertised remote "foo" is rejected.
diff --git a/Documentation/config/safe.adoc b/Documentation/config/safe.adoc
index 2d45c98b12..5ae4476b24 100644
--- a/Documentation/config/safe.adoc
+++ b/Documentation/config/safe.adoc
@@ -2,10 +2,12 @@ safe.bareRepository::
Specifies which bare repositories Git will work with. The currently
supported values are:
+
+--
* `all`: Git works with all bare repositories. This is the default.
* `explicit`: Git only works with bare repositories specified via
the top-level `--git-dir` command-line option, or the `GIT_DIR`
environment variable (see linkgit:git[1]).
+--
+
If you do not use bare repositories in your workflow, then it may be
beneficial to set `safe.bareRepository` to `explicit` in your global
diff --git a/Documentation/git-config.adoc b/Documentation/git-config.adoc
index 00545b2054..8439ce97df 100644
--- a/Documentation/git-config.adoc
+++ b/Documentation/git-config.adoc
@@ -221,6 +221,7 @@ Use `--no-value` to unset _<pattern>_.
+
Valid `<type>`'s include:
+
+--
- 'bool': canonicalize values `true`, `yes`, `on`, and positive
numbers as "true", and values `false`, `no`, `off` and `0` as
"false".
@@ -239,6 +240,7 @@ Valid `<type>`'s include:
escape sequence. When setting a value, a sanity-check is performed to ensure
that the given value is canonicalize-able as an ANSI color, but it is written
as-is.
+--
+
If the command is in `list` mode, then the `--type <type>` argument will apply
to each listed config value. If the value does not successfully parse in that
--
2.30.2
^ permalink raw reply related
* [PATCH 0/3] doc: config: fix AsciiDoc glitches
From: Tuomas Ahola @ 2026-06-10 18:51 UTC (permalink / raw)
To: git; +Cc: Tuomas Ahola
Fix various markup shortcomings in git-config(1).
Based on 29bd7ed512 (The second batch, 2026-05-12).
Tuomas Ahola (3):
doc: config: terminate runaway lists
doc: config/sideband: fix typo in adoc markup
doc: git-config: escape erroneous adoc markup
Documentation/config.adoc | 4 +++-
Documentation/config/promisor.adoc | 2 ++
Documentation/config/safe.adoc | 2 ++
Documentation/config/sideband.adoc | 2 +-
Documentation/git-config.adoc | 6 ++++--
5 files changed, 12 insertions(+), 4 deletions(-)
base-commit: 29bd7ed5127255713c1ac2f43b7c6f257d7b4594
--
2.30.2
^ permalink raw reply
* [PATCH 3/3] doc: git-config: escape erroneous adoc markup
From: Tuomas Ahola @ 2026-06-10 18:51 UTC (permalink / raw)
To: git; +Cc: Tuomas Ahola
In-Reply-To: <20260610185148.23920-1-taahol@utu.fi>
Paired octothorpes are used in AsciiDoc to mark highlighted text,
<mark> being the equivalent HTML tag. To use the symbol as a literal
character, it can be escaped with a backslash.
Do so in git-config.adoc.
While at it, tweak the text slightly to make it scan better.
Signed-off-by: Tuomas Ahola <taahol@utu.fi>
---
Documentation/git-config.adoc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-config.adoc b/Documentation/git-config.adoc
index 8439ce97df..708e88cdeb 100644
--- a/Documentation/git-config.adoc
+++ b/Documentation/git-config.adoc
@@ -119,10 +119,10 @@ OPTIONS
Append a comment at the end of new or modified lines.
+
If _<message>_ begins with one or more whitespaces followed
-by "#", it is used as-is. If it begins with "#", a space is
+by "\#", it is used as-is. If it begins with "#", a space is
prepended before it is used. Otherwise, a string " # " (a
space followed by a hash followed by a space) is prepended
-to it. And the resulting string is placed immediately after
+to it. The resulting string is placed immediately after
the value defined for the variable. The _<message>_ must
not contain linefeed characters (no multi-line comments are
permitted).
--
2.30.2
^ permalink raw reply related
* [PATCH 2/3] doc: config/sideband: fix typo in adoc markup
From: Tuomas Ahola @ 2026-06-10 18:51 UTC (permalink / raw)
To: git; +Cc: Tuomas Ahola
In-Reply-To: <20260610185148.23920-1-taahol@utu.fi>
Fix a simple typo in AsciiDoc markup.
Signed-off-by: Tuomas Ahola <taahol@utu.fi>
---
Documentation/config/sideband.adoc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/config/sideband.adoc b/Documentation/config/sideband.adoc
index 96fade7f5f..06de0d5c07 100644
--- a/Documentation/config/sideband.adoc
+++ b/Documentation/config/sideband.adoc
@@ -9,7 +9,7 @@ sideband.allowControlCharacters::
`color`::
Allow ANSI color sequences, line feeds and horizontal tabs,
but mask all other control characters. This is the default.
- `cursor:`:
+ `cursor`::
Allow control sequences that move the cursor. This is
disabled by default.
`erase`::
--
2.30.2
^ permalink raw reply related
* [PATCH v3] describe: limit default ref iteration to tags
From: Tamir Duberstein @ 2026-06-10 18:50 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King, Patrick Steinhardt, Tamir Duberstein
In-Reply-To: <20260608-describe-tag-ref-scope-v2-1-256fd36dca32@gmail.com>
Without --all, git describe ignores refs outside refs/tags/. Commit
8a5a1884e9 (Avoid accessing non-tag refs in git-describe unless --all is
requested, 2008-02-24) moved this check ahead of object lookup. That
avoided loading objects for irrelevant refs, but the backend still has
to yield every ref before get_name() can reject it.
Pass refs/tags/ to the iterator so the backend can avoid visiting those
refs in the first place.
The new perf test creates 10,000 unrelated packed refs. It measures:
git describe --exact-match HEAD
The runtime drops from 0.03(0.01+0.01) to 0.02(0.00+0.00). In a
repository with 120,532 refs but only 330 tags, the same command went
from 171.7 ms to 9.9 ms.
Signed-off-by: Tamir Duberstein <tamird@gmail.com>
---
Changes in v3:
- Pack the synthetic refs to better match repositories with many refs.
- Generate update-ref input with test_seq -f.
- Shorten the commit message and report the p6100.6 result.
- Link to v2: https://patch.msgid.link/20260608-describe-tag-ref-scope-v2-1-256fd36dca32@gmail.com
Changes in v2:
- Exercise the performance test with both ref backends.
- Keep the ref count local to its setup test.
- Report native hyperfine output for an exact-tag lookup.
- Link to v1: https://patch.msgid.link/20260607-describe-tag-ref-scope-v1-1-653d232b86b5@gmail.com
---
builtin/describe.c | 3 +++
t/perf/p6100-describe.sh | 12 ++++++++++++
2 files changed, 15 insertions(+)
diff --git a/builtin/describe.c b/builtin/describe.c
index 1c47d7c0b7..3532c8ff22 100644
--- a/builtin/describe.c
+++ b/builtin/describe.c
@@ -740,6 +740,9 @@ int cmd_describe(int argc,
return ret;
}
+ if (!all)
+ for_each_ref_opts.prefix = "refs/tags/";
+
hashmap_init(&names, commit_name_neq, NULL, 0);
refs_for_each_ref_ext(get_main_ref_store(the_repository),
get_name, NULL, &for_each_ref_opts);
diff --git a/t/perf/p6100-describe.sh b/t/perf/p6100-describe.sh
index 069f91ce49..b1c61529bb 100755
--- a/t/perf/p6100-describe.sh
+++ b/t/perf/p6100-describe.sh
@@ -27,4 +27,16 @@ test_perf 'describe HEAD with one tag' '
git describe --match=new HEAD
'
+test_expect_success 'set up many unrelated refs' '
+ ref_count=10000 &&
+ git tag -m tip tip HEAD &&
+ test_seq -f "create refs/heads/describe-perf/%05d HEAD" $ref_count |
+ git update-ref --stdin &&
+ git pack-refs --all
+'
+
+test_perf 'describe exact tag with many unrelated refs' '
+ git describe --exact-match HEAD
+'
+
test_done
---
base-commit: 9ac3f193c05c2237e2b14ebaa1149e9fc8a1abe0
change-id: 20260607-describe-tag-ref-scope-7d00ae140a58
Best regards,
--
Tamir Duberstein <tamird@gmail.com>
^ permalink raw reply related
* Re: [PATCH] commit-reach: remove get_reachable_subset()
From: Kristofer Karlsson @ 2026-06-10 18:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kristofer Karlsson via GitGitGadget, git, Derrick Stolee
In-Reply-To: <xmqqbjdixupc.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
> "should not matter in practice" because...?
>
> And of course the worst case scenario is by definition not a typical
> case that appear in practice, so it does not make a good explanation
> for "should not matter in practice".
You are right, that was hand-wavy. I started with writing a somewhat
long analysis but after finding a clean way of supporting both DFS
and priority queue modes it feels somewhat unnecessary - I will
still include it here, but the short summary is that it's fixable.
Since the prio_queue struct supports both LIFO and heap mode,
it's actually quite easy to plug this into
tips_reachable_from_bases. I just need to switch away from using
the stack structure and pass a mode to choose between LIFO
and heap. This preserves the old behavior while still reducing
the code size and unifying the code more.
I will submit a v2 of the patch shortly.
I will also include the original analysis I wrote before finding
the simple fix.
Thanks for the review!
Kristofer
---
I will refer to the prio_queue approach in get_reachable_subset
as PQ for brevity, and the DFS in tips_reachable_from_bases as
simply DFS.
tips_reachable_from_bases() was designed for --merged queries where
the targets (branches/tags) can be deep ancestors of the base. DFS
is a natural fit there: it dives deep along first-parent quickly,
and with generation numbers the dynamic floor raising prunes
aggressively.
add_missing_tags() has the opposite shape: the bases are branch
tips being pushed (near the top) and the targets are tag commits
the remote does not have yet, which tend to be relatively close
to those tips. PQ ordered by commit date is a better fit here
because it sweeps down from the top and finds nearby targets early,
while DFS might take a long detour down a side branch before
coming back.
With a commit-graph this difference mostly disappears since the
generation floor keeps DFS from going too far off track. Without a
commit-graph, neither approach prunes anything (generation is
GENERATION_NUMBER_INFINITY for all commits) so the traversal order
is the only thing that matters, and PQ has the edge for shallow
targets.
So the current code actually has each caller matched to the
traversal strategy that fits its typical workload. My patch traded
that away for code reduction.
That said, in practice the difference is limited: repositories
large enough for this to matter typically have a commit-graph,
and small repositories are fast either way.
---
^ permalink raw reply
* Re: [PATCH v2] describe: limit default ref iteration to tags
From: Junio C Hamano @ 2026-06-10 17:45 UTC (permalink / raw)
To: Tamir Duberstein; +Cc: Jeff King, git, Patrick Steinhardt
In-Reply-To: <CAJ-ks9kz5JGFSF21aOhuXfgsJ+5aa5xE69RPT2Vhn-CRGyHZ6A@mail.gmail.com>
Tamir Duberstein <tamird@gmail.com> writes:
> On Tue, Jun 9, 2026 at 4:09 AM Jeff King <peff@peff.net> wrote:
>>
>> Probably not worth re-rolling on its own, though.
>
> The suggested changes seem reasonable to me. Certainly I am happy to
> make them, and re-rolls are cheap. Do let me know explicitly if you'd
> like that done.
Let's see how much more pleasant to read such an updated version ;-)
Thanks.
^ permalink raw reply
* Re: [PATCH v2] describe: limit default ref iteration to tags
From: Junio C Hamano @ 2026-06-10 17:43 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: Jeff King, Tamir Duberstein, git
In-Reply-To: <aika_Q0rWhcI6eXR@pks.im>
Patrick Steinhardt <ps@pks.im> writes:
> I very much think that we should and even have to expect that
> contributors adapt, because if we don't we will basically reinforce
> whatever AI is doing right now and increase the load on reviewers even
> more.
>
> I also think that we should reserve the right to reject a patch series
> completely in case we notice that we're basically just talking to a
> middleman that sits between an AI prompt and us (please note that I
> don't refer to this patch series specifically, this is more of a general
> statement).
Sounds sensible. Something like this may make a good starting
point.
diff --git c/Documentation/SubmittingPatches w/Documentation/SubmittingPatches
index 176567738d..2fd7f6f9e6 100644
--- c/Documentation/SubmittingPatches
+++ w/Documentation/SubmittingPatches
@@ -499,6 +499,12 @@ checking for obvious mistakes, things that can be improved, things
that don’t match our style, guidelines or our feedback, before sending
it to us.
+We reserve the right to reject a patch series completely when we
+notice that we are basically just talking to a middleman that sits
+between an AI prompt and us, without having a better understanding of
+the subject matter than the AI agent being used.
+
+
[[git-tools]]
=== Generate your patch using Git tools out of your commits.
^ permalink raw reply related
* Re: [PATCH v4] remote: qualify "git pull" advice for non-upstream compareBranches
From: Harald Nordgren @ 2026-06-10 17:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Harald Nordgren via GitGitGadget, git
In-Reply-To: <xmqq7bo6xuok.fsf@gitster.g>
> > remote: qualify "git pull" advice for non-upstream branches
> >
> > * Don't suggest git pull when we have no good command to suggest.
> > * New test for this. Asserts the behind line shows with no follow-up
> > advice.
>
> Very well written.
>
> What does not happen in the "punt" case (the first bullet point
> above) may deserve to be given in the commit log message, but
> otherwise it is very clear what the change wanted to do to the
> future readers of "git log".
Thanks. It's a good point, but maybe it's implicit that nothing
happens when nothing can happen?
> Shall we mark it for 'next' now?
>
> Thanks for working on this.
Yes please, thanks for all the help!
Harald
^ permalink raw reply
* Re: [PATCH 3/9] setup: don't apply "GIT_REFERENCE_BACKEND" without a repository
From: Junio C Hamano @ 2026-06-10 17:32 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Karthik Nayak
In-Reply-To: <20260610-b4-pks-refs-avoid-chdir-notify-reparent-v1-3-56c864b01c43@pks.im>
Patrick Steinhardt <ps@pks.im> writes:
> When discovering a repository we eventually also apply the
> "GIT_REFERENCE_BACKEND" environment variable to the repository. There's
> two problems with that:
>
> - We do this unconditionally, which is rather pointless: we really
> only have to configure the repository when we have found one.
>
> - We have already applied the repository format at that point in time,
> so we need to manually reapply it.
Does the second point have a small typo, i.e., "if we have a
repository, we have already applied the ref backend to it when we
discovered it, so NO need to manually reapply"?
> Move the logic around so that we only apply the environment variable
> when a repository was discovered. This also allows us to drop the
> explcit call to `repo_set_ref_storage_format()` because we now adjust
> the format before we apply it via `apply_repository_format()`.
Makes sense.
^ permalink raw reply
* Re: [PATCH] bash-completions: add --max-count-oldest
From: Junio C Hamano @ 2026-06-10 17:08 UTC (permalink / raw)
To: Mirko Faina; +Cc: git
In-Reply-To: <a804828a046d8f12ef0d03eaf014807b079bb707.1781102091.git.mroik@delayed.space>
Mirko Faina <mroik@delayed.space> writes:
> Add missing completion for log --max-count-oldest
>
> Signed-off-by: Mirko Faina <mroik@delayed.space>
> ---
> Unfortunately I forgot to add bash completions.
That's fine. I think it is OK to add a new patch on top of that
series.
^ permalink raw reply
* Re: [PATCH v2 3/3] replay: offer an option to linearize the commit topology
From: Junio C Hamano @ 2026-06-10 17:02 UTC (permalink / raw)
To: Toon Claes; +Cc: git, Johannes Schindelin
In-Reply-To: <20260610-toon-git-replay-drop-merges-v2-3-5714a71c6d83@iotcl.com>
Toon Claes <toon@iotcl.com> writes:
> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>
> One of the stated goals of git-replay(1) is to allow implementing the
> git-rebase(1) functionality on the server side.
>
> The default mode of git-rebase(1) is to act as if `--no-rebase-merges`
> was given. This mode drops merge commits instead of replaying them, and
> linearizes the commit history into a sequence of the
> regular (single-parent) commits.
>
> Add option `--linearize` to git-replay(1) to do the same.
>
> Co-authored-by: Toon Claes <toon@iotcl.com>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> Signed-off-by: Toon Claes <toon@iotcl.com>
> ---
> Documentation/git-replay.adoc | 5 +++++
> builtin/replay.c | 4 ++++
> replay.c | 30 +++++++++++++++++++++++-------
> replay.h | 5 +++++
> t/t3650-replay-basics.sh | 26 ++++++++++++++++++++++++++
> 5 files changed, 63 insertions(+), 7 deletions(-)
>
> @@ -430,12 +435,23 @@ int replay_revisions(struct rev_info *revs,
> while ((commit = get_revision(revs))) {
> const struct name_decoration *decoration;
>
> - if (commit->parents && commit->parents->next)
> - die(_("replaying merge commits is not supported yet!"));
> + if (commit->parents && commit->parents->next) {
> + if (!opts->linearize)
> + die(_("replaying merge commits is not supported yet!"));
> + /*
> + * When linearizing, a merge commit itself is not picked,
> + * but refs that point to it might need updating.
> + */
In the review response during the previous iteration, I commented
that (1) the original excluded only merges, but (2) your version
excluded both merges and the root commits the same way. Your
response was:
The way it was written in v1 was maybe a bit too smart and hard to
follow. I agree with your suggestion and will adopt this (with some
tweaks) in the next version.
which I took as saying "it may be confusing, but it correctly
expresses what we want to do", meaning "yes, roots and merges should
be handled the same way". But the above no longer treats roots the
same way as merges. I think that is intended, but just wanted to
double check.
> diff --git a/replay.h b/replay.h
> index 1851a07705..07e6fdcca3 100644
> --- a/replay.h
> +++ b/replay.h
> @@ -62,6 +62,11 @@ struct replay_revisions_options {
> * Defaults to REPLAY_EMPTY_COMMIT_DROP.
> */
> enum replay_empty_commit_action empty;
> +
> + /*
> + * Whether to linearize the commits (i.e. drop merge commits).
> + */
> + int linearize;
> };
OK.
> diff --git a/t/t3650-replay-basics.sh b/t/t3650-replay-basics.sh
> index 3353bc4a4d..64e0731188 100755
> --- a/t/t3650-replay-basics.sh
> +++ b/t/t3650-replay-basics.sh
> @@ -565,4 +565,30 @@ test_expect_success '--onto with --ref rejects multiple revision ranges' '
> test_grep "cannot be used with multiple revision ranges" err
> '
>
> +test_expect_success 'replay merge commit fails' '
> + echo "fatal: replaying merge commits is not supported yet!" >expect &&
> + test_must_fail git replay --ref-action=print --onto main I..P 2>actual &&
> + test_cmp expect actual
> +'
> +
> +test_expect_success 'replay to rebase merge commit with --linearize' '
> + git replay --ref-action=print --linearize --onto main I..topic-with-merge >result &&
> +
> + test_line_count = 1 result &&
> +
> + git log --format=%s $(cut -f 3 -d " " result) >actual &&
> + test_write_lines O N J M L B A >expect &&
> + test_cmp expect actual
> +'
> +
> +test_expect_success 'replay to rebase merge commit with --linearize down to root commit' '
> + git replay --ref-action=print --linearize --onto main A..topic-with-merge >result &&
As with other test pieces, this "git replay" command line is overly
long and hides the important bit which is that the range being
replayed is *not* actually down to the root, which is A (it excludes
A). Intended?
> +
> + test_line_count = 1 result &&
> +
> + git log --format=%s $(cut -f 3 -d " " result) >actual &&
> + test_write_lines O N J I M L B A >expect &&
> + test_cmp expect actual
> +'
> +
> test_done
Thanks.
^ permalink raw reply
* Re: [PATCH v2 1/1] environment.c: move 'protect_hfs' and 'protect_ntfs' into 'repo_config_values'
From: Junio C Hamano @ 2026-06-10 16:41 UTC (permalink / raw)
To: Tian Yuchen
Cc: git, phillip.wood123, Christian Couder, Ayush Chandekar,
Olamide Caleb Bello
In-Reply-To: <20260610124353.149874-2-cat@malon.dev>
Tian Yuchen <cat@malon.dev> writes:
> +int repo_protect_ntfs(struct repository *repo)
> +{
> + return repo->gitdir ?
> + repo_config_values(repo)->protect_ntfs :
> + PROTECT_NTFS_DEFAULT;
> +}
> +
> +int repo_protect_hfs(struct repository *repo)
> +{
> + return repo->gitdir ?
> + repo_config_values(repo)->protect_hfs :
> + PROTECT_HFS_DEFAULT;
> +}
> ...
> @@ -123,6 +125,14 @@ int git_default_config(const char *, const char *,
> int git_default_core_config(const char *var, const char *value,
> const struct config_context *ctx, void *cb);
>
> +/*
> + * Getters for the `protect_hfs` and `protect_ntfs` fields of `struct repo_config_values`.
> + * They check `repo->gitdir` to prevent calling repo_config_values()
> + * before the configuration is loaded or in bare environments.
> + */
> +int repo_protect_hfs(struct repository *repo);
> +int repo_protect_ntfs(struct repository *repo);
I briefly wondered what *should* happen when repo->gitdir is not
ready, as it feels almost a bug for a caller to call these two
functions before the repository is ready to be used.
When repo is not ready, these return their respective default
values. That's like the original code using the initial value of
these global variables.
IOW, this rewrite is bug-for-bug compatible, which is good.
Shall we declare victory and mark the topic for 'next' now?
Thanks.
^ permalink raw reply
* Re: [PATCH v4 09/10] builtin/history: split handling of ref updates into two phases
From: Junio C Hamano @ 2026-06-10 16:25 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Pablo Sabater, Kristoffer Haugsbakk, Phillip Wood
In-Reply-To: <20260610-b4-pks-history-drop-v4-9-70d5f0ae8c25@pks.im>
Patrick Steinhardt <ps@pks.im> writes:
> The function `handle_reference_updates()` is used by git-history(1) to
> update all references that refer to commits that have been rewritten. As
> such, it performs two steps:
>
> - It gathers the references that need to be updated in the first
> place.
>
> - It prepares and commits the reference transaction.
>
> In a subsequent commit we'll want to handle those two steps separately.
> Prepare for this by splitting up the function into two.
OK. I can sees how this will help doing a dry-run mode.
> +static int apply_pending_ref_updates(struct repository *repo,
> + const struct replay_result *result,
> + const char *reflog_msg,
> + int dry_run)
> +{
> + struct ref_transaction *transaction = NULL;
> + struct strbuf err = STRBUF_INIT;
> + int ret;
> +
> + if (!dry_run) {
> + transaction = ref_store_transaction_begin(get_main_ref_store(repo),
> + 0, &err);
> + if (!transaction) {
> + ret = error(_("failed to begin ref transaction: %s"), err.buf);
> + goto out;
> + }
> + }
> +
> + for (size_t i = 0; i < result->updates_nr; i++) {
> ret = handle_ref_update(transaction,
> - decoration->name,
> - &rewritten->object.oid,
> - &original->object.oid,
> + result->updates[i].refname,
> + &result->updates[i].new_oid,
> + &result->updates[i].old_oid,
> reflog_msg, &err);
Cute.
handle_ref_update() uses transaction==NULL not as a signal to update
each ref as request comes (i.e., non-transactional updates) but as a
singal to perform a dry-run, which was unexpected to my taste but it
has been that way since at least February this year ;-)
Looking good.
Thanks.
^ permalink raw reply
* Re: [PATCH RFC v2 2/2] builtin/history: abort reword on same message
From: Junio C Hamano @ 2026-06-10 16:02 UTC (permalink / raw)
To: Patrick Steinhardt
Cc: Pablo Sabater, Phillip Wood, git, cat, kaartic.sivaraam,
ben.knoble
In-Reply-To: <aikMLBCC9Rc7q9S7@pks.im>
Patrick Steinhardt <ps@pks.im> writes:
> On Tue, Jun 09, 2026 at 12:17:51PM -0700, Junio C Hamano wrote:
>> Pablo Sabater <pabloosabaterr@gmail.com> writes:
>>
>> >> > I wonder if we should check that the committer identity is unchanged as
>> >> > well in case anyone is using this to fix commits after committing with
>> >> > the wrong identity.
>> >
>> > I think that if you reword a commit committed by someone else but end
>> > up with no changes I want it to be kept as it was.
>>
>> That depends on the reason why the feature to "reword" the commit is
>> being used, and the use case Phillip is talking about is a bit
>> different.
>
> So the answer is "it depends". Maybe we should do handle this the same
> as git-commit(1) does with its "--reset-author" flag?
Interesting. I was mostly focusing on the committer identity, but
the same argument of courese also applies to the author identity.
Having said that, if the user who used to commit others' patches
under a wrong identity (i.e., the only thing incorrect about these
commits is the committer identity, and author identity of them are
not to be updated), "--reset-author" would not be usable, as they
want to keep the authorship information recorded. I think
(1) in the shorter term, always create a new commit by default even
if the only difference were the committer timestamp. But add a
mechanism to allow users to tell the tool to skip the update
in such a case.
(2) at a big version bump, flip the default, making the "always
create a new commit" an optional feature.
would be the way to go, and the way to trigger that mechanism needs
to be separate from "--reset-author".
Thanks.
^ permalink raw reply
* Re: [PATCH v4] remote: qualify "git pull" advice for non-upstream compareBranches
From: Junio C Hamano @ 2026-06-10 15:48 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget; +Cc: git, Harald Nordgren
In-Reply-To: <pull.2301.v4.git.git.1779372367317.gitgitgadget@gmail.com>
"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
> 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
>
> * Don't suggest git pull when we have no good command to suggest.
> * New test for this. Asserts the behind line shows with no follow-up
> advice.
Very well written.
What does not happen in the "punt" case (the first bullet point
above) may deserve to be given in the commit log message, but
otherwise it is very clear what the change wanted to do to the
future readers of "git log".
> remote.c | 48 +++++++++++++++----
> t/t6040-tracking-info.sh | 100 +++++++++++++++++++++++++++++++++++++++
> 2 files changed, 140 insertions(+), 8 deletions(-)
The code changes look correct, and the new tests checks the new
suggestion as well as the "punt" case, which is good.
Shall we mark it for 'next' now?
Thanks for working on this.
>> diff --git a/t/t6040-tracking-info.sh b/t/t6040-tracking-info.sh
> index 0242b5bf7a..91cbb8775d 100755
> --- a/t/t6040-tracking-info.sh
> +++ b/t/t6040-tracking-info.sh
> @@ -646,4 +646,104 @@ 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
> +'
A good test that clearly shows how @{push} is described ;-)
> +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
> +'
OK.
^ permalink raw reply
* Re: [PATCH] commit-reach: remove get_reachable_subset()
From: Junio C Hamano @ 2026-06-10 15:48 UTC (permalink / raw)
To: Kristofer Karlsson via GitGitGadget
Cc: git, Derrick Stolee, Kristofer Karlsson
In-Reply-To: <pull.2144.git.1781033285419.gitgitgadget@gmail.com>
"Kristofer Karlsson via GitGitGadget" <gitgitgadget@gmail.com>
writes:
> get_reachable_subset() was introduced in fcb2c0769d (2018-11-02)
> for add_missing_tags() in remote.c. tips_reachable_from_bases()
> was added in cbfe360b14 (2023-03-20) as part of the ahead-behind
> series. The two were never consolidated.
Good finding. It is curious to see that these were from the same
author.
> ... Without generation numbers, some edge cases
> may be slower with DFS instead of BFS since the date-ordered
> prio_queue naturally stays near the top of the graph, but this
> should not matter in practice
"should not matter in practice" because...?
> -- worst case both visit the full
> graph down from the bases.
And of course the worst case scenario is by definition not a typical
case that appear in practice, so it does not make a good explanation
for "should not matter in practice".
> The flag in remote.c changes from 1 (bit 0) to TMP_MARK (bit 4)
> because tips_reachable_from_bases() uses SEEN (bit 0) internally.
> TMP_MARK is already used for deduplication earlier in the same
> function and is cleared before the reachability check.
And tips_reachable_from_bases() clears SEEN at the end as expected.
> commit-reach.c | 73 -------------------------------------------
> commit-reach.h | 13 --------
> remote.c | 19 ++++++-----
> t/helper/test-reach.c | 39 +++++++++++------------
> t/t6600-test-reach.sh | 18 +++++------
> 5 files changed, 36 insertions(+), 126 deletions(-)
Yay, a lot of deletions ;-)
> diff --git a/t/t6600-test-reach.sh b/t/t6600-test-reach.sh
> index b5b314e570..51b140a539 100755
> --- a/t/t6600-test-reach.sh
> +++ b/t/t6600-test-reach.sh
> @@ -391,7 +391,7 @@ test_expect_success 'rev-list: symmetric difference topo-order' '
> run_all_modes git rev-list --topo-order commit-3-8...commit-6-6
> '
>
> -test_expect_success 'get_reachable_subset:all' '
> +test_expect_success 'tips_reachable_from_bases:all' '
> cat >input <<-\EOF &&
> X:commit-9-1
> X:commit-8-3
> @@ -403,15 +403,15 @@ test_expect_success 'get_reachable_subset:all' '
> Y:commit-5-6
> EOF
> (
> - echo "get_reachable_subset(X,Y)" &&
> + echo "tips_reachable_from_bases(X,Y)" &&
> git rev-parse commit-3-3 \
> commit-1-7 \
> commit-5-6 | sort
> ) >expect &&
> - test_all_modes get_reachable_subset
> + test_all_modes tips_reachable_from_bases
> '
>
> -test_expect_success 'get_reachable_subset:some' '
> +test_expect_success 'tips_reachable_from_bases:some' '
> cat >input <<-\EOF &&
> X:commit-9-1
> X:commit-8-3
> @@ -422,14 +422,14 @@ test_expect_success 'get_reachable_subset:some' '
> Y:commit-5-6
> EOF
> (
> - echo "get_reachable_subset(X,Y)" &&
> + echo "tips_reachable_from_bases(X,Y)" &&
> git rev-parse commit-3-3 \
> commit-1-7 | sort
> ) >expect &&
> - test_all_modes get_reachable_subset
> + test_all_modes tips_reachable_from_bases
> '
>
> -test_expect_success 'get_reachable_subset:none' '
> +test_expect_success 'tips_reachable_from_bases:none' '
> cat >input <<-\EOF &&
> X:commit-9-1
> X:commit-8-3
> @@ -439,8 +439,8 @@ test_expect_success 'get_reachable_subset:none' '
> Y:commit-7-6
> Y:commit-2-8
> EOF
> - echo "get_reachable_subset(X,Y)" >expect &&
> - test_all_modes get_reachable_subset
> + echo "tips_reachable_from_bases(X,Y)" >expect &&
> + test_all_modes tips_reachable_from_bases
> '
>
> test_expect_success 'for-each-ref ahead-behind:linear' '
>
> base-commit: 600fe743028cbfb640855f659e9851522214bc0b
Initially I feared that changes to the test script were a sign of
need to adjuist to behaviour changes, but as the proposed log
message explained, all of the above changes are about the name of
the function being used and tested, which makes sense.
Thanks.
^ permalink raw reply
* Re: [BUG] rebase --update-refs emits unqualified "update-ref HEAD" into the todo
From: Phillip Wood @ 2026-06-10 15:39 UTC (permalink / raw)
To: betel_taxis4h, git
In-Reply-To: <35A368B8-9B8A-44A9-96DA-65ED16D7D564@icloud.com>
On 10/06/2026 12:00, betel_taxis4h@icloud.com wrote:
> What did you do before the bug happened? (Steps to reproduce your issue)
>
> With rebase.updateRefs=true, an interactive rebase of the checked-out branch generates a todo containing the literal line "update-ref HEAD”, which git's own todo parser then rejects.
>
> Minimal reproduction (plain repo, no worktrees, no remotes required):
>
> git init -b main repro && cd repro
> git -c user.email=t@t.t -c user.name=t commit --allow-empty -m base
> git checkout -b feat
> git -c user.email=t@t.t -c user.name=t commit --allow-empty -m c1
> git -c user.email=t@t.t -c user.name=t commit --allow-empty -m c2
> git -c rebase.updateRefs=true rebase -i feat~2
>
> The generated todo contains:
>
> pick <c1> c1
> pick <c2> c2
> update-ref HEAD <-- emitted for HEAD, a symref to the branch being rebased
> update-ref refs/heads/feat (correctly placed; this one is fine)
I'm unable to reproduce this with the script above and I do not see any
update-ref commands added to the todo list (which is expected as feat is
being rebased so should not appear in the todo list). Do you have
rebase.instructionFormat set? We recently had a bug report and fix[1]
for "update-ref HEAD" being added when rebase.instructionFormat includes
"%d".
Thanks
Phillip
[1] https://lore.kernel.org/git/20260510224111.64467-1-mail@abhinavg.net/
> Letting the editor save the auto-generated todo verbatim (or running `git rebase --continue`) fails immediately with:
>
> error: update-ref requires a fully qualified refname e.g. refs/heads/HEAD
> error: invalid line 3: update-ref HEAD
> You can fix this with 'git rebase --edit-todo' and then run 'git rebase --continue'.
>
> What did you expect to happen? (Expected behavior)
>
> --update-refs should not emit an "update-ref HEAD" line. HEAD is a symbolic alias of the branch being rebased; the branch ref itself is (correctly) excluded from the update-ref set, so its HEAD alias should be excluded too. The todo should contain only fully-qualified refs/heads/... lines.
>
> What happened instead? (Actual behavior)
>
> git emits a todo line ("update-ref HEAD") that its own sequencer parser rejects as not fully qualified, breaking the rebase. The only recovery is `git rebase --edit-todo` to manually delete the line.
>
> What's different between what you expected and what actually happened?
>
> git generated a todo command it refuses to execute. The unqualified "HEAD" should either be expanded to its target ref or omitted entirely.
>
> Anything else you want to add:
>
> - Reproduces identically in a plain single-worktree repo and in a bare-repo + linked-worktree layout, so it is not worktree-specific.
> - An in-sync remote-tracking ref (origin/feat) on the tip adds a second, valid "update-ref refs/remotes/origin/feat" line but is not required to trigger the fatal "update-ref HEAD".
> - Workaround: unset rebase.updateRefs (or pass -c rebase.updateRefs=false), or delete the "update-ref HEAD" line via `git rebase --edit-todo`.
>
>
> [System Info]
> git version:
> git version 2.54.0
> cpu: aarch64
> no commit associated with this build
> sizeof-long: 8
> sizeof-size_t: 8
> shell-path: /bin/sh
> rust: disabled
> gettext: enabled
> libcurl: 8.14.1
> OpenSSL: OpenSSL 3.5.6 7 Apr 2026
> zlib: 1.3.1
> SHA-1: SHA1_DC
> SHA-256: SHA256_BLK
> default-ref-format: files
> default-hash: sha1
> uname: Linux 7.0.11-orbstack-00360-gc9bc4d96ac70 #1 SMP PREEMPT Thu Jun 4 16:40:25 UTC 2026 aarch64
> compiler info: gnuc: 14.2
> libc info: glibc: 2.41
> $SHELL (typically, interactive shell): /usr/bin/zsh
>
>
^ permalink raw reply
* Re: [GSoC RFC PATCH 0/1] graph: add indentation for commits preceded by a root
From: Pablo Sabater @ 2026-06-10 15:28 UTC (permalink / raw)
To: Junio C Hamano
Cc: Chandra Pratap, phillip.wood, git, christian.couder, karthik.188,
jltobler, ayu.chandekar, siddharthasthana31
In-Reply-To: <xmqqcxxyxvyo.fsf@gitster.g>
El mié, 10 jun 2026 a las 17:21, Junio C Hamano (<gitster@pobox.com>) escribió:
>
> Pablo Sabater <pabloosabaterr@gmail.com> writes:
>
> >> > Do we want cascading or just a fixed indentation?
> >> >
> >> > * A parentless
> >> > * B parentless
> >> > * C parentless
> >> > * D1 child
> >> > * D parentless
> >>
> >> I am late to the party, but I cannot get how the latter is viable.
> >> If "A" had parent "B" whose parent was "C" that is root, wouldn't we
> >> see the same output? Or are we adding " parentless" at the end of
> >> the one-liner log message?
> >
> > We wouldn't see the same output because A and B wouldn't get padded in
> > that case. Vertical adjacency between indented commits doesn't imply
> > relation because indentation means that they are "parentless",
>
> Hmph, I guess such "the first column is special in that two commits
> on consecutive lines with the asterisk on the same column, if only
> that is on the first column, are parent-child, but it does not hold
> in all other columns" was beyond my imagination. And that was why I
> said I am late to the party. Do others find such a rule intuitive?
> I didn't (and that is what led me to ask the question).
>
> > Anyways, having more than 2 "parentless" commits one after the other
> > is strange. Cascading is just having a depth counter and printing the
> > padding depth times, so I'll keep it as it is more intuitive.
>
> Is everbody happy with this version, or will we see an updated final
> reroll to tie any loose ends? For example, do we need the above
> "vertically adjacent commits are in parent-child relationship only
> when they appear on the first column" given as a new instruction in
> the documentation to help users read and understand what the graph
> output is trying to tell them?
>
> Thanks.
Hi!
No, it is not ready yet, sorry, I have to send the next version but I
cannot get some tests to work, I should have it by this week.
Thanks,
Pablo.
^ permalink raw reply
* Re: [GSoC RFC PATCH 0/1] graph: add indentation for commits preceded by a root
From: Junio C Hamano @ 2026-06-10 15:21 UTC (permalink / raw)
To: Pablo Sabater
Cc: Chandra Pratap, phillip.wood, git, christian.couder, karthik.188,
jltobler, ayu.chandekar, siddharthasthana31
In-Reply-To: <CAN5EUNSFBC0+aoW1ceGjEiKWBRjzuzUEUjg8Xys5O9rDsJdkjg@mail.gmail.com>
Pablo Sabater <pabloosabaterr@gmail.com> writes:
>> > Do we want cascading or just a fixed indentation?
>> >
>> > * A parentless
>> > * B parentless
>> > * C parentless
>> > * D1 child
>> > * D parentless
>>
>> I am late to the party, but I cannot get how the latter is viable.
>> If "A" had parent "B" whose parent was "C" that is root, wouldn't we
>> see the same output? Or are we adding " parentless" at the end of
>> the one-liner log message?
>
> We wouldn't see the same output because A and B wouldn't get padded in
> that case. Vertical adjacency between indented commits doesn't imply
> relation because indentation means that they are "parentless",
Hmph, I guess such "the first column is special in that two commits
on consecutive lines with the asterisk on the same column, if only
that is on the first column, are parent-child, but it does not hold
in all other columns" was beyond my imagination. And that was why I
said I am late to the party. Do others find such a rule intuitive?
I didn't (and that is what led me to ask the question).
> Anyways, having more than 2 "parentless" commits one after the other
> is strange. Cascading is just having a depth counter and printing the
> padding depth times, so I'll keep it as it is more intuitive.
Is everbody happy with this version, or will we see an updated final
reroll to tie any loose ends? For example, do we need the above
"vertically adjacent commits are in parent-child relationship only
when they appear on the first column" given as a new instruction in
the documentation to help users read and understand what the graph
output is trying to tell them?
Thanks.
^ 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