* Re: [PATCH v2] doc: git-log: clarify --follow options
From: Tamir Duberstein @ 2026-05-10 23:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jean-Noël Avila
In-Reply-To: <xmqqqzni967o.fsf@gitster.g>
On Sun, May 10, 2026 at 7:48 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Tamir Duberstein <tamird@gmail.com> writes:
>
> > I will reroll to say that `--follow` follows a single file beyond renames, works
> > only with exactly one pathspec, and that directory pathspecs do not follow
> > directory renames even though they still use the same traversal mode and can
> > therefore show a different set of commits. I will also fix the subject and
> > option ordering as suggested.
>
> To be quite honest, the "--follow" option being what it is (i.e., a
> checkbox option to claim we do support such an operation, without a
> serious design and implementation), I'd rather see our documentation
> being more honest and do not claim it works with pathspec at all.
> When you use "--follow", you have to give a single filename, and
> that file is followed across commits that renames it from some other
> name, and then that file with the old name is followed.
I certainly agree that being honest is the right thing to do - but the
honest truth is that `--follow` changes the behavior when used with
*any* pathspec, not just when given a single file. I attempted to
capture that nuance in v3.
>
> If multiple histories are merged and if the file being followed
> turns out to have come from different files on these different
> histories, the "old name" the traversal is currently following is
> not kept track of per traversal path, so we cannot expect the
> feature to work with anything but a linear history, either.
I'm not sure how to reply to this. The ground truth today is that the
option does have an effect when used with not-just-a-single-file, yet
the documentation does not mention this at all.
^ permalink raw reply
* Re: [PATCH v3] doc: clarify --follow and log.follow for git log
From: Junio C Hamano @ 2026-05-10 23:53 UTC (permalink / raw)
To: Tamir Duberstein; +Cc: git, Jean-Noël Avila
In-Reply-To: <20260510-document-log-no-follow-v3-1-d6d3368c64bb@gmail.com>
Tamir Duberstein <tamird@gmail.com> writes:
> `log.follow`::
> If `true`, `git log` will act as if the `--follow` option was used when
> + a single pathspec is given. This has the same limitations as
> + `--follow`, i.e. it cannot be used with multiple pathspecs and does not
> + work well on non-linear history. When the pathspec names a directory,
> + Git does not follow directory renames, but it still uses the same
> + traversal mode as for file rename following; see `--follow` in
> + linkgit:git-log[1]. This can be overridden by `--no-follow`.
Saying that the feature does "not work well" on non-lenear history
is like the behaviour of the feature is "undefined" on such a
history. Quite honestly, when you do not give a single filename,
the behaviour is "undefined", either, so I do not think we want to
say what happens when the pathspec you give matches a directory.
The feature only takes a single filename on a linear history.
Anything else the feature does is "undefined" random behavour.
^ permalink raw reply
* Re: [PATCH v3] doc: clarify --follow and log.follow for git log
From: Tamir Duberstein @ 2026-05-11 0:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jean-Noël Avila
In-Reply-To: <xmqqik8u95yn.fsf@gitster.g>
On Sun, May 10, 2026 at 7:53 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Tamir Duberstein <tamird@gmail.com> writes:
>
> > `log.follow`::
> > If `true`, `git log` will act as if the `--follow` option was used when
> > + a single pathspec is given. This has the same limitations as
> > + `--follow`, i.e. it cannot be used with multiple pathspecs and does not
> > + work well on non-linear history. When the pathspec names a directory,
> > + Git does not follow directory renames, but it still uses the same
> > + traversal mode as for file rename following; see `--follow` in
> > + linkgit:git-log[1]. This can be overridden by `--no-follow`.
>
> Saying that the feature does "not work well" on non-lenear history
> is like the behaviour of the feature is "undefined" on such a
> history. Quite honestly, when you do not give a single filename,
> the behaviour is "undefined", either, so I do not think we want to
> say what happens when the pathspec you give matches a directory.
> The feature only takes a single filename on a linear history.
> Anything else the feature does is "undefined" random behavour.
I observed this "undefined" behavior, which is why I started working
on this patch. I think it is not reasonable to deal with undefined
behavior by pretending it doesn't exist. The documentation should
acknowledge and explain what happens when this option is used for all
ways that it can be used.
^ permalink raw reply
* Re: [PATCH 1/1] shallow: fix relative deepen on non-shallow repositories
From: Junio C Hamano @ 2026-05-11 0:09 UTC (permalink / raw)
To: Samo Pogačnik; +Cc: git, l.s.r, owen
In-Reply-To: <20260506215647.3011769-1-samo_pogacnik@t-2.net>
Samo Pogačnik <samo_pogacnik@t-2.net> writes:
> The previous patch "shallow: handling fetch relative-deepen"
Whose "previous patch" are we talking about in [PATCH 1/1]?
Please refer to the commit with "git show -s --format=reference", if
you are talking about a public commit etched in the history.
> introduced a bug where using --deepen=<n> on a non-shallow
> repository incorrectly treated the value as an absolute depth,
> resulting in a shallow fetch and truncated history.
That's unfortunate.
We obviously should not truncate when asked to "deepen" (i.e., the
user asked to get more history, not reset the number of commits we
have to a specific depth), and making the operation in this
situation a no-op may be a good first step, but should we just do so
silently, instead of giving a warning/diagnosis?
> This patch prevents any modification when a relative deepen is
> requested on a non-shallow repository.
>
> A test is added to ensure that history is not changed when
> --deepen is used on a non-shallow repository.
>
> Reported-by: Owen Stephens <owen@owenstephens.co.uk>
> Signed-off-by: Samo Pogačnik <samo_pogacnik@t-2.net>
^ permalink raw reply
* Re: [PATCH v3] doc: clarify --follow and log.follow for git log
From: Junio C Hamano @ 2026-05-11 0:13 UTC (permalink / raw)
To: Tamir Duberstein; +Cc: git, Jean-Noël Avila
In-Reply-To: <CAJ-ks9mPzCr3obAw5cE071GNjzy_ZLzF4mQdnUbQY5H4WPw3sA@mail.gmail.com>
Tamir Duberstein <tamird@gmail.com> writes:
> I observed this "undefined" behavior, which is why I started working
> on this patch. I think it is not reasonable to deal with undefined
> behavior by pretending it doesn't exist. The documentation should
> acknowledge and explain what happens when this option is used for all
> ways that it can be used.
No, you are misguided.
Undefined behaviour can change without notice, and users should be
strongly discouraged from using it. Describing what the current
implementation happens to do moves us exactly in the opposite
direction.
`--follow` is a checkbox feature. You can use it "only with a single
filename on a linear history" or all bets are off otherwise.
That is what we should describe if we want to be honest.
^ permalink raw reply
* Re: [PATCH] add -p: introduce 'w' command to view hunk with --word-diff
From: Junio C Hamano @ 2026-05-11 0:16 UTC (permalink / raw)
To: D. Ben Knoble
Cc: Phillip Wood, Javier Bassi, git, Abraham Samuel Adekunle,
Rene Scharfe, Elijah Newren, Ruben Justo, Patrick Steinhardt
In-Reply-To: <CALnO6CCsOMyLxAhGW10L4duaahUORwedfmtdpY3zDGpQcZoP2Q@mail.gmail.com>
"D. Ben Knoble" <ben.knoble@gmail.com> writes:
> I concur, though I wonder what other diff options would be useful. I
> can imagine a world where "add --patch" allows to reshow the patch
> with any set of custom options. Spitballing…
>
> :show <opts>
>
> …could work, since we have room to allow long-form commands still.
> This could be extended to arbitrary git-* commands, and ":!cmd" could
> be used for shelling out.
> (Can you tell I use Vim?)
>
> Anyway, what I like about this is we don't have to worry about running
> out of (or thinking up new mnemonics for) single letters for different
> combinations of diff options, so it's a bit more extensible.
If you mean "don't waste a new letter, like 'w', every time you come
up with a use case to show the patch hunk differently", I had the
same reaction to suggest reusing 'p' but allow options after it,
just like the output from "git diff" can be modified by giving it an
option "--word-diff". But how would it work for single-key folks (I
am not one of them so I have less sympathy than I should in this
case, but still...).
^ permalink raw reply
* Re: [PATCH] rebase: ignore non-branch update-refs
From: Abhinav Gupta @ 2026-05-11 0:15 UTC (permalink / raw)
To: Junio C Hamano, Phillip Wood; +Cc: git, Derrick Stolee
In-Reply-To: <xmqqv7cu96q4.fsf@gitster.g>
On Sun, May 10, 2026, at 16:37, Junio C Hamano wrote:
> it would have failed to work due to the "HEAD" thing, so even though
> existing versions of Git may have added such local tags to the insn
> sequence, it would not have been a workable configuration anyway.
Yeah. One additional data point:
non-interactive rebase is also broken under this configuration.
Given a branch off main~1, it runs into the same issue:
$ git checkout -b foo main~1
$ git commit --allow-empty -m 'do things'
$ git rebase main
# ...
error: update-ref requires a fully qualified refname e.g. refs/heads/HEAD
error: invalid line 2: update-ref HEAD
You can fix this with 'git rebase --edit-todo' and then run 'git rebase --continue'.
Or you can abort the rebase with 'git rebase --abort'.
I'm guessing non-interactive rebase works off the same todo list so that makes sense.
^ permalink raw reply
* Re: [PATCH] rebase: ignore non-branch update-refs
From: Junio C Hamano @ 2026-05-11 0:20 UTC (permalink / raw)
To: Abhinav Gupta; +Cc: Phillip Wood, git, Derrick Stolee
In-Reply-To: <63e04828-5895-4deb-a698-5d6f494d23f3@app.fastmail.com>
"Abhinav Gupta" <mail@abhinavg.net> writes:
> On Sun, May 10, 2026, at 16:37, Junio C Hamano wrote:
>> it would have failed to work due to the "HEAD" thing, so even though
>> existing versions of Git may have added such local tags to the insn
>> sequence, it would not have been a workable configuration anyway.
>
> Yeah. One additional data point:
> non-interactive rebase is also broken under this configuration.
> Given a branch off main~1, it runs into the same issue:
>
> $ git checkout -b foo main~1
> $ git commit --allow-empty -m 'do things'
> $ git rebase main
> # ...
> error: update-ref requires a fully qualified refname e.g. refs/heads/HEAD
> error: invalid line 2: update-ref HEAD
> You can fix this with 'git rebase --edit-todo' and then run 'git rebase --continue'.
> Or you can abort the rebase with 'git rebase --abort'.
>
> I'm guessing non-interactive rebase works off the same todo list so that makes sense.
I smell that you'd be suggesting to replace the patch we have
discussed with another one that declares that it is a bug to use %d
in insn format? I do not think how well it would fly.
^ permalink raw reply
* Re: [PATCH v3] doc: clarify --follow and log.follow for git log
From: Tamir Duberstein @ 2026-05-11 0:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jean-Noël Avila
In-Reply-To: <xmqqv7cux0q7.fsf@gitster.g>
On Sun, May 10, 2026 at 8:13 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Tamir Duberstein <tamird@gmail.com> writes:
>
> > I observed this "undefined" behavior, which is why I started working
> > on this patch. I think it is not reasonable to deal with undefined
> > behavior by pretending it doesn't exist. The documentation should
> > acknowledge and explain what happens when this option is used for all
> > ways that it can be used.
>
> No, you are misguided.
>
> Undefined behaviour can change without notice, and users should be
> strongly discouraged from using it. Describing what the current
> implementation happens to do moves us exactly in the opposite
> direction.
>
> `--follow` is a checkbox feature. You can use it "only with a single
> filename on a linear history" or all bets are off otherwise.
>
> That is what we should describe if we want to be honest.
At the very least the documentation should state this...?
^ permalink raw reply
* Re: [PATCH] rebase: ignore non-branch update-refs
From: Abhinav Gupta @ 2026-05-11 0:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Phillip Wood, git, Derrick Stolee
In-Reply-To: <xmqqmry6x0dm.fsf@gitster.g>
On Sun, May 10, 2026, at 17:20, Junio C Hamano wrote:
> I smell that you'd be suggesting to replace the patch we have
> discussed with another one that declares that it is a bug to use %d
> in insn format? I do not think how well it would fly.
No, I didn't meant to imply that. I'm happy with the patch as-is.
Using %d in insn format is desirable, and I would not try to remove that.
I ran into this issue because of my own use of %d in insn format.
I was sharing an additional example for how this currently misbehaves:
not only does it generate the 'update-ref HEAD' in interactive contexts,
but it also breaks all non-interactive rebases with a non-empty todo list.
^ permalink raw reply
* Re: [PATCH v3] doc: clarify --follow and log.follow for git log
From: Junio C Hamano @ 2026-05-11 0:46 UTC (permalink / raw)
To: Tamir Duberstein; +Cc: git, Jean-Noël Avila
In-Reply-To: <CAJ-ks9krzLO_+O74omAfeVByUBh=rDGSVSarf5PGwkdWepzubw@mail.gmail.com>
Tamir Duberstein <tamird@gmail.com> writes:
>> Undefined behaviour can change without notice, and users should be
>> strongly discouraged from using it. Describing what the current
>> implementation happens to do moves us exactly in the opposite
>> direction.
>>
>> `--follow` is a checkbox feature. You can use it "only with a single
>> filename on a linear history" or all bets are off otherwise.
>>
>> That is what we should describe if we want to be honest.
>
> At the very least the documentation should state this...?
Sure.
Doesn't the current text for the option
`--follow`::
Continue listing the history of a file beyond renames
(works only for a single file).
pretty much cover that, though? The configuration side is a bit
more verbose but essentially says the same thing, I think.
`log.follow`::
If `true`, `git log` will act as if the `--follow` option was used when
a single <path> is given. This has the same limitations as `--follow`,
i.e. it cannot be used to follow multiple files and does not work well
on non-linear history.
We do not say anything about what the feature happens to do when it
is given a non-linear history whose branches each rename to the same
final name that you start following from in the more recent part of
the history, either, and stop at saying "does not work well". We
should treat that case the same way as the case where the user gives
a pathspec with multiple pathspec elements or a pathspec that
matches with a directory.
^ permalink raw reply
* Re: [PATCH v3] doc: add caveat about turning off commit-graph
From: Junio C Hamano @ 2026-05-11 1:16 UTC (permalink / raw)
To: Kristoffer Haugsbakk; +Cc: Derrick Stolee, git
In-Reply-To: <7eae7ad5-5b09-4069-aafe-571f3e345b83@app.fastmail.com>
"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:
> On Thu, May 7, 2026, at 21:56, Derrick Stolee wrote:
>> On 5/7/2026 3:42 PM, kristofferhaugsbakk@fastmail.com wrote:
>>> From: Kristoffer Haugsbakk <code@khaugsbakk.name>
>>
>>> Range-diff against v2:
>>> 1: 82faa72f7bf ! 1: fb5ba74ea3e doc: add caveat about turning off commit-graph
>>> @@ Commit message
>>> But this isn’t mentioned in the user-facing doc. Let’s mention it on
>>> git-replace(1) and git-commit-graph(1).
>>>
>>> + Acked-by: Derrick Stolee <stolee@gmail.com>
>>> Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
>>>
>>> ## Documentation/git-commit-graph.adoc ##
>> In general, you don't need to do this. Junio will add these
>> during his application of the series, if necessary.
>
> It’s certainly not necessary, yeah. :)
>
> I am basing this on a recollection of someone quoting this from
> SubmittingPatches:
>
> Do not forget to add trailers such as `Acked-by:`, `Reviewed-by:` and
> `Tested-by:` lines as necessary to credit people who helped your
> patch, and "cc:" them when sending such a final version for inclusion.
>
> They said that this was outdated since Junio does it himself. But then
> Junio replied and said that it’s good/better if the contributor does it.
I used to say "let me do this to skip one extra roundtrip" but I
stopped saying so. Perhaps I should be a bit more explicit and stop
being silently nice to contributors who do not follow the guidelines
to the letter in order to unconfuse you and your friends. It
actually is a tempting thought.
> Well, this is another instance that I may be trying to be too
> helpful and over extending myself, which does not make the process
> scale well (the other one being the "one final resend after the
> list reached a consensus").
>
> If the authors collect Acks and Reviewed-by's and resend after the
> list reached the concensus, it may take one extra iteration, but I
> no longer have to keep track of these trailers myself, which could
> be a big win.
>
> So, I dunno.
>
> In conclusion for now: I dunno. :)
I do not know either, but if we agree that everybody should do so
themselves and I should refrain from applying the ones that lack
Acks, I can adjust. There will be lot of unapplied patches left on
the mailing list initially until the contributors adjust their
behaviour, but in the long run it may be beneficial?
^ permalink raw reply
* Re: [PATCH v3] doc: clarify --follow and log.follow for git log
From: Tamir Duberstein @ 2026-05-11 1:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jean-Noël Avila
In-Reply-To: <xmqqh5oewz6c.fsf@gitster.g>
On Sun, May 10, 2026 at 8:46 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Tamir Duberstein <tamird@gmail.com> writes:
>
> >> Undefined behaviour can change without notice, and users should be
> >> strongly discouraged from using it. Describing what the current
> >> implementation happens to do moves us exactly in the opposite
> >> direction.
> >>
> >> `--follow` is a checkbox feature. You can use it "only with a single
> >> filename on a linear history" or all bets are off otherwise.
> >>
> >> That is what we should describe if we want to be honest.
> >
> > At the very least the documentation should state this...?
>
> Sure.
>
> Doesn't the current text for the option
>
> `--follow`::
> Continue listing the history of a file beyond renames
> (works only for a single file).
>
> pretty much cover that, though? The configuration side is a bit
> more verbose but essentially says the same thing, I think.
>
> `log.follow`::
> If `true`, `git log` will act as if the `--follow` option was used when
> a single <path> is given. This has the same limitations as `--follow`,
> i.e. it cannot be used to follow multiple files and does not work well
> on non-linear history.
>
> We do not say anything about what the feature happens to do when it
> is given a non-linear history whose branches each rename to the same
> final name that you start following from in the more recent part of
> the history, either, and stop at saying "does not work well". We
> should treat that case the same way as the case where the user gives
> a pathspec with multiple pathspec elements or a pathspec that
> matches with a directory.
Sorry, I was unclear. I was saying that the documentation should be
explicit about the cases that constitute "undefined behavior".
^ permalink raw reply
* Re: [PATCH v3] doc: clarify --follow and log.follow for git log
From: Junio C Hamano @ 2026-05-11 2:06 UTC (permalink / raw)
To: Tamir Duberstein; +Cc: git, Jean-Noël Avila
In-Reply-To: <CAJ-ks9n=DcwqyP7K_q0Ki6_3_+o5=558FK1DKr0+VyiM7q69EA@mail.gmail.com>
Tamir Duberstein <tamird@gmail.com> writes:
>> Doesn't the current text for the option
>>
>> `--follow`::
>> Continue listing the history of a file beyond renames
>> (works only for a single file).
>>
>> pretty much cover that, though? The configuration side is a bit
>> more verbose but essentially says the same thing, I think.
>>
>> `log.follow`::
>> If `true`, `git log` will act as if the `--follow` option was used when
>> a single <path> is given. This has the same limitations as `--follow`,
>> i.e. it cannot be used to follow multiple files and does not work well
>> on non-linear history.
>>
>> We do not say anything about what the feature happens to do when it
>> is given a non-linear history whose branches each rename to the same
>> final name that you start following from in the more recent part of
>> the history, either, and stop at saying "does not work well". We
>> should treat that case the same way as the case where the user gives
>> a pathspec with multiple pathspec elements or a pathspec that
>> matches with a directory.
>
> Sorry, I was unclear. I was saying that the documentation should be
> explicit about the cases that constitute "undefined behavior".
Ah, I see.
I am not sure. This is not the only case where we have left these
unspecified things unsaid, is it? I am not sure if it is worth
singling out this particular case.
Thanks.
^ permalink raw reply
* Re: [PATCH] commit-reach: early exit paint_down_to_common for single merge-base
From: Junio C Hamano @ 2026-05-11 2:08 UTC (permalink / raw)
To: Kristofer Karlsson via GitGitGadget
Cc: git, Derrick Stolee, Kristofer Karlsson
In-Reply-To: <pull.2109.git.1778252837132.gitgitgadget@gmail.com>
"Kristofer Karlsson via GitGitGadget" <gitgitgadget@gmail.com>
writes:
> diff --git a/commit-reach.c b/commit-reach.c
> index d3a9b3ed6f..c9d2d594de 100644
> --- a/commit-reach.c
> +++ b/commit-reach.c
> @@ -55,14 +55,16 @@ static int paint_down_to_common(struct repository *r,
> struct commit **twos,
> timestamp_t min_generation,
> int ignore_missing_commits,
> + int find_all,
> struct commit_list **result)
> {
> struct prio_queue queue = { compare_commits_by_gen_then_commit_date };
> int i;
> + int has_gens = min_generation || corrected_commit_dates_enabled(r);
Giving a name that identifies what the commonly-used logical
expression means is a very good idea, but don't some caller pass
min_generation==infinity (i.e., not zero) when there is no
generation available? E.g., remove_redundant_no_gen() passes
the result of calling commit_graph_generation(), and without commit
graph, we would get infinity here, right?
Given that the second user of this variable is guarded by !find_all,
the variable being true even when we shouldn't be using generation
numbers may not matter for the purpose of the early break, but then
it means that the patch squanders the perfect opportunity to clarify
what the variable means, which is not very lovely.
> timestamp_t last_gen = GENERATION_NUMBER_INFINITY;
> struct commit_list **tail = result;
>
> - if (!min_generation && !corrected_commit_dates_enabled(r))
> + if (!has_gens)
> queue.compare = compare_commits_by_commit_date;
>
> one->object.flags |= PARENT1;
> @@ -97,6 +99,11 @@ static int paint_down_to_common(struct repository *r,
> if (!(commit->object.flags & RESULT)) {
> commit->object.flags |= RESULT;
> tail = commit_list_append(commit, tail);
> + /* Generation-ordered queue: no later
> + * commit can dominate this one. */
> + if (!find_all && has_gens &&
> + generation < GENERATION_NUMBER_INFINITY)
> + break;
Three comments
* See Documentation/CodingGuidelines for our preferred style for
multi-line comments.
* I do not think we often use "dominate" to describe relationship
between commits, and I am not sure what you want the word to mean
in this context. Can you clarify?
* The code is getting way too deeply indented. Perhaps using a
helper function and
if (!(commit->object.flags & RESULT)) {
if (mark_result(r, &tail, commit,
find_all, min_generation))
break;
}
move the logic to mark the newly discovered commit as one of the
possible result, and to tell the loop to terminate, to it, along
with the comment on the meaning of its return value, may make the
code easier to follow?
> +/* To be used only when object flags after this call no longer matter.
> + * When find_all is false and generation numbers are available, returns
> + * after finding the first merge-base, skipping the STALE drain. */
Ditto on the style.
^ permalink raw reply
* Re: [PATCH] config: retry acquiring config.lock for 100ms
From: Junio C Hamano @ 2026-05-11 2:32 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: Joerg Thalheim, git
In-Reply-To: <adYvSZeN0ZVqwRhi@pks.im>
Patrick Steinhardt <ps@pks.im> writes:
>> This bites in practice when running `git worktree add -b` concurrently
>> against the same repository. Each invocation makes several writes to
>> ".git/config" to set up branch tracking, and tooling that creates
>> worktrees in parallel sees intermittent failures. Worse, `git worktree
>> add` does not propagate the failed config write to its exit code: the
>> worktree is created and the command exits 0, but tracking
>> configuration is silently dropped.
>
> This very much sounds like a bug that is worth fixing independently.
>
>> The lock is held only for the duration of rewriting a small file, so
>> retrying for 100 ms papers over any realistic contention while still
>> failing fast if a stale lock has been left behind by a crashed
>> process. This mirrors what we already do for individual reference
>> locks (4ff0f01cb7 (refs: retry acquiring reference locks for 100ms,
>> 2017-08-21)).
>
> Famous last words :) Experience tells me that any timeout value that
> isn't excessive will eventually be hit in some production system. Which
> raises the question whether we want to make the timeout configurable,
> similar to "core.filesRefLockTimeout" and "core.packedRefsTimeout".
> ...
> Honestly though, I'm not really sure what to make with this. We could
> of course also add some validation that the configuration we want to set
> hasn't been modified meanwhile. But that would now lead to a situation
> where we have to update every single caller in our tree to make use of
> the new mechanism, which would be a bunch of work.
>
> And adding the timeout doesn't really change the status quo, either. We
> already have the case that we'll happily overwrite changes made by
> concurrent processes. The only thing that changes is that we make it
> more likely for concurrent changes to succeed.
We haven't heard any response to these points raised in the message
I am responding to. Should I still keep the patch in my tree,
hoping that a responses may come some day? I am tempted to discard
the topic as it has been quite a while since we last looked at it.
Thanks.
^ permalink raw reply
* Re: [PATCH v6] clone: add clone.<url>.defaultObjectFilter config
From: Junio C Hamano @ 2026-05-11 2:38 UTC (permalink / raw)
To: Patrick Steinhardt
Cc: Alan Braithwaite via GitGitGadget, git, christian.couder,
jonathantanmy, me, Jeff King, brian m. carlson, Alan Braithwaite
In-Reply-To: <abe1l8ONmFIhzaxi@pks.im>
Patrick Steinhardt <ps@pks.im> writes:
> On Sun, Mar 15, 2026 at 05:37:02AM +0000, Alan Braithwaite via GitGitGadget wrote:
>> 1: fa1ea69bdb ! 1: 480453b2e7 clone: add clone.<url>.defaultObjectFilter config
>> @@ t/t5616-partial-clone.sh: test_expect_success 'after fetching descendants of non
>> +test_expect_success 'setup for clone.defaultObjectFilter tests' '
>> + git init default-filter-src &&
>> + echo "small" >default-filter-src/small.txt &&
>> -+ dd if=/dev/zero of=default-filter-src/large.bin bs=1024 count=100 2>/dev/null &&
>> + git -C default-filter-src add . &&
>> + git -C default-filter-src commit -m "initial" &&
>> +
>
> As Junio already pointed out, this change here is a bit puzzling. Not
> that I think it's a problem, but one wonders why this existed in the
> first place if it seemed to not be necessary.
>> ...
>> + normalized_url = url_normalize(url, &config.url);
>> + if (!normalized_url) {
>> + urlmatch_config_release(&config);
>> + return NULL;
>> + }
>
> We haven't allocated anything, right? So in theory, we should be able to
> return early without calling `urlmatch_config_release()`. This could be
> stressed further by moving the error path earlier, so that it's the
> first thing we do in the function.
We haven't heard any response to these points raised in the message
I am responding to. Should I still keep the patch in my tree,
hoping that a responses may come some day? I am tempted to discard
the topic as it has been quite a while since we last looked at it.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 0/9] doc: interpret-trailers: explain key format
From: Junio C Hamano @ 2026-05-11 2:41 UTC (permalink / raw)
To: Kristoffer Haugsbakk
Cc: git, Christian Couder, jackmanb, Linus Arver, D. Ben Knoble
In-Reply-To: <55d5d53a-ec30-4b72-9ff4-c5a0631620ec@app.fastmail.com>
"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:
> On Mon, Apr 13, 2026, at 12:20, kristofferhaugsbakk@fastmail.com wrote:
>> From: Kristoffer Haugsbakk <code@khaugsbakk.name>
>>[snip]
>
> Sorry to Ben here who I forgot to set on copy. :/
>
> +Cc now.
It has been quite a while and I have no recollection if there were
still necessary adjustments or not. Is everybody happy with the
final text?
https://lore.kernel.org/git/V2_CV_doc_int-tr_key_format.613@msgid.xyz/
Documentation/git-interpret-trailers.adoc | 68 +++++++++++++++++++++++--------
1 file changed, 50 insertions(+), 18 deletions(-)
diff --git a/Documentation/git-interpret-trailers.adoc b/Documentation/git-interpret-trailers.adoc
index 77b4f63b05..b42f957d66 100644
--- a/Documentation/git-interpret-trailers.adoc
+++ b/Documentation/git-interpret-trailers.adoc
@@ -3,7 +3,7 @@ git-interpret-trailers(1)
NAME
----
-git-interpret-trailers - Add or parse structured information in commit messages
+git-interpret-trailers - Add or parse metadata in commit messages
SYNOPSIS
--------
@@ -14,9 +14,15 @@ git interpret-trailers [--in-place] [--trim-empty]
DESCRIPTION
-----------
-Add or parse _trailer_ lines that look similar to RFC 822 e-mail
-headers, at the end of the otherwise free-form part of a commit
-message. For example, in the following commit message
+Add or parse trailers metadata at the end of the otherwise
+free-form part of a commit message, or any other kind of text.
+
+A _trailer_ in its simplest form is a key-value pair with a colon as a
+separator. The _key_ consists of ASCII alphanumeric characters and
+hyphens (`-`). A _trailer block_ consists of one or more trailers. The
+trailer block needs to be preceded by a blank line, where a _blank line_
+is either an empty or a whitespace-only line. For example, in the
+following commit message
------------------------------------------------
subject
@@ -81,19 +87,25 @@ trailer.sign.key "Signed-off-by: "
in your configuration, you only need to specify `--trailer="sign: foo"`
on the command line instead of `--trailer="Signed-off-by: foo"`.
-By default the new trailer will appear at the end of all the existing
-trailers. If there is no existing trailer, the new trailer will appear
-at the end of the input. A blank line will be added before the new
-trailer if there isn't one already.
+By default the new trailer will appear at the end of the trailer block.
+A trailer block will be created with only that trailer if a trailer
+block does not already exist. Recall that a trailer block needs to be
+preceded by a blank line, so a blank line (specifically an empty line)
+will be inserted before the new trailer block in that case.
-Existing trailers are extracted from the input by looking for
-a group of one or more lines that (i) is all trailers, or (ii) contains at
-least one Git-generated or user-configured trailer and consists of at
+Existing trailers are extracted from the input by looking for the
+trailer block. Concretely, that is a group of one or more lines that (i)
+is all trailers, or (ii) contains at least one Git-generated or
+user-configured trailer and consists of at
least 25% trailers.
-The group must be preceded by one or more empty (or whitespace-only) lines.
-The group must either be at the end of the input or be the last
-non-whitespace lines before a line that starts with `---` (followed by a
-space or the end of the line).
+The trailer block is by definition at the end the the message. The end
+of the message in turn is either (i) at the end of the input, or (ii)
+the last non-whitespace lines before a line that starts with `---`
+(followed by a space or the end of the line).
+
+This command ignores comment lines (see `core.commentString` in
+linkgit:git-config[1]). This is for use with the `prepare-commit-msg`
+and `commit-msg` hooks.
When reading trailers, there can be no whitespace before or inside the
_<key>_, but any number of regular space and tab characters are allowed
@@ -107,9 +119,6 @@ key: This is a very long value, with spaces and
newlines in it.
------------------------------------------------
-Note that trailers do not follow (nor are they intended to follow) many of the
-rules for RFC 822 headers. For example they do not follow the encoding rule.
-
OPTIONS
-------
`--in-place`::
@@ -402,6 +411,29 @@ mv "\$1.new" "\$1"
$ chmod +x .git/hooks/commit-msg
------------
+* Here we try to to use three different trailer keys. But it fails
+ because two of them are not recognized as trailer keys.
++
+----
+$ cat msg.txt
+subject
+
+Skapad-på: some-branch
+Hash-in-v6.11: 45c12d3269fe48f22834320c782ffe86c3560f2c
+Reviewed-by: Alice <alice@example.com>
+$ git interpret-trailers --only-trailers <msg.txt
+$
+----
++
+Recall that a trailer key has to consist of only ASCII alphanumeric
+characters and hyphens, and this does not hold for the two first
+supposed trailer keys. And now none are recognized as trailers because
+the candidate trailer block has at least one non-trailer line, even
+though `Reviewed-by` is a valid trailer key. Recall that a trailer block
+has to either (i) be all trailers, or (ii) consist of at least one
+Git-generated or user-configured trailer (and some other conditions).
+And (ii) is not satisfied since we have not configured any trailer keys.
+
SEE ALSO
--------
linkgit:git-commit[1], linkgit:git-format-patch[1], linkgit:git-config[1]
^ permalink raw reply related
* Re: [PATCH v2 2/3] builtin/log: prefetch necessary blobs for `git cherry`
From: Junio C Hamano @ 2026-05-11 2:51 UTC (permalink / raw)
To: Derrick Stolee; +Cc: Elijah Newren via GitGitGadget, git, Elijah Newren
In-Reply-To: <a2fbb23d-0809-4a9d-8bf9-8ac0dc8ee054@gmail.com>
Derrick Stolee <stolee@gmail.com> writes:
> Ultimately, _this_ patch cares about a diff. Could we compute a
> "diff prep" computation using the core diff library instead of
> inventing a second queue of results for diffing?
>
> Patch 3 cares about a "scan prep" which cares about loading all
> blobs for a given tree with respect to a pathspec. This is very
> similar to what a checkout would do, though it ultimately uses
> a form of diff to find out what change should be applied to the
> working directory. Perhaps 'git archive' is a better matching
> example.
>
> I don't mean to make your series more complicated. I value what
> you're doing and can see how your current attention can be used
> to make further improvements later. By implementing things in a
> common location, then we can have later integrations add to the
> confidence in the feature through tests covering each user-facing
> use.
>
> I'm not sure if it makes sense to attempt to create a universal
> library method that would be used by builtin/log.c _and_ diff.c,
> at least not right now. I'm most interested in having this logic
> be more reusable in the future without needing to move code
> across files.
The points raised in the message I am responding here, together with
the ones in <31763514-2602-4d8e-ac25-70590f090947@gmail.com>, remain
unanswered.
Should I still keep these patches in my tree, hoping that responses
may come some day? I will mark the topic as "Expeting review
responses" in the draft "What's cooking" report I work from for now,
but it has been quite a while since we looked at the patches, so...?
Thanks.
^ permalink raw reply
* Re: [PATCH v2 0/9] pack-bitmap: fix various pseudo-merge bugs
From: Junio C Hamano @ 2026-05-11 2:53 UTC (permalink / raw)
To: Taylor Blau, Elijah Newren; +Cc: git, Jeff King
In-Reply-To: <CABPp-BGkfavqezk2SV3+K6iF8MLm8j_=ijHiPDLmv_U_o_Ykgg@mail.gmail.com>
Elijah Newren <newren@gmail.com> writes:
>> + git init pseudo-merge-fill-in-multi &&
>
> Here you fixed the order, but...
>
>> ++ git init pseudo-merge-fill-in-multi &&
>
> ...then you immediately run git init a second time? I'm guessing this
> was a stray edit made while trying to fix the order; could we get rid
> of the duplicate?
>
>> (
>> + cd pseudo-merge-fill-in-multi &&
>> +
>
> Looks like you addressed all the feedback so far from v1. There does
> appear to be a new accidental double-init that I noted above in patch
> 4, but I didn't spot any other issues.
The topic went dormant after this comment, and it seems that it is
so close to the finish line otherwise? I'll leave the topic marked
as "Expecting (hopefully minor and final) reroll" in the draft
"What's cooking" report I work from for now.
Thanks.
^ permalink raw reply
* Re: [PATCH v3 0/8] environment: move core config globals into repo_config_values
From: Junio C Hamano @ 2026-05-11 2:56 UTC (permalink / raw)
To: Bello Olamide
Cc: git, phillip.wood123, christian.couder, usmanakinyemi202,
kaartic.sivaraam, me
In-Reply-To: <CAD=f0L8-_3sDGGkCzF4WA0xmUtaY_qiz__3zq5AemLgwTsqvsg@mail.gmail.com>
Bello Olamide <belkid98@gmail.com> writes:
> On Sun, 26 Apr 2026 at 01:02, Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Olamide Caleb Bello <belkid98@gmail.com> writes:
>>
>> > Olamide Caleb Bello (8):
>> > environment: move "trust_ctime" into `struct repo_config_values`
>> > environment: move "check_stat" into `struct repo_config_values`
>> > environment: move `zlib_compression_level` into `struct
>> > repo_config_values`
>> > environment: move "pack_compression_level" into `struct
>> > repo_config_values`
>> > environment: move "precomposed_unicode" into `struct
>> > repo_config_values`
>> > env: move "core_sparse_checkout_cone" into `struct repo_config_values`
>> > env: move "sparse_expect_files_outside_of_patterns" into
>> > `repo_config_values`
>> > env: move "warn_on_object_refname_ambiguity" into `struct
>> > repo_config_values`
>>
>> Are there differences between the ones that start with "environment:"
>> vs the ones with "env:"?
>>
> Hi Junio,
>
> There isn’t any semantic difference intended between
> the "environment:" and "env:" prefixes
>
> I shortened some of them to stay within the recommended subject length,
> but on a second thought I agree that consistency is more important here.
>
> I’ll standardize them in the next revision.
Does anybody listed on the CC: in the original submission have any
comments on this round? It seems that v2 iteration was commented on
quite a bit, but has anybody checked the latest iteration since it
was posted?
Thanks.
^ permalink raw reply
* Re: [PATCH] fetch: add fetch.pruneLocalBranches config
From: Junio C Hamano @ 2026-05-11 2:59 UTC (permalink / raw)
To: Harald Nordgren; +Cc: j6t, git, gitgitgadget, kristofferhaugsbakk
In-Reply-To: <20260505220712.93952-1-haraldnordgren@gmail.com>
Harald Nordgren <haraldnordgren@gmail.com> writes:
>> I have some sympathy for the desire to clean up unnecessary local
>> branches, but I don't like the concept that `git fetch` modifies local
>> branches, not even as an opt-in. Deleting local branches should be `git
>> branch`'s task exclusively (at the porcelain level).
>
> Yeah, maybe that's a good point.
I think the latest iteration was sent after the above exchange, yet
it seems to have changes to builtin/fetch.c to cause `git fetch` to
modify local branches still. Will we have another update that is
hopefully final to excise that part, or are we OK to allow `fetch`
to modify the local state as an opt-in now?
Thanks.
^ permalink raw reply
* Re: [PATCH v6 00/10] parseopt: add subcommand autocorrection
From: Junio C Hamano @ 2026-05-11 3:03 UTC (permalink / raw)
To: Jiamu Sun; +Cc: git, Aaron Plattner, Karthik Nayak
In-Reply-To: <SY0P300MB0801677A2A1E0FD38D06A841CE2A2@SY0P300MB0801.AUSP300.PROD.OUTLOOK.COM>
Jiamu Sun <39@barroit.sh> writes:
> Git currently provides auto-correction for builtins and aliases, but
> lacks this functionality for subcommands parsed via the parse-options
> API. Subcommands are also commands, and typos will occur, too. Like:
>
> git remote add-rul
>
> So, this series introduces subcommand auto-correction.
>
> By default, this implementation enables autocorrection for builtins
> with mandatory subcommands. However, for those using
> PARSE_OPT_SUBCOMMAND_OPTIONAL, autocorrection is skipped to avoid
> misinterpreting legitimate unknown arguments as mistyped subcommands.
>
> To allow builtins with optional subcommands to explicitly opt in,
> this series adds the PARSE_OPT_SUBCOMMAND_AUTOCORRECT flag, and enables
> it for git-remote and git-notes.
>
> Additionally, the existing autocorrection logic is extracted from
> help.c so subcommand handling can reuse the same config parsing and
> prompt/delay logic.
>
> Some string literals are also combined so the full text is easier to
> grep for.
>
> Changes in v6:
> - Adjust existing tests to fit subcommand autocorrection behavior
> - Change the similar subcommand hint exit code to 129
I've been carrying the following fix on top of these series since
Apr 23 when the topic was merged to 'seen'. Can you fix these up at
the source, so that we can move forward with this topic?
Thanks.
diff --git a/parse-options.c b/parse-options.c
index a1258134df..1a5feab5dd 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -647,7 +647,8 @@ static const char *autocorrect_subcommand(const char *cmd,
struct string_list *cmds)
{
struct autocorrect autocorrect = { 0 };
- unsigned int n = 0, best = 0;
+ unsigned int n = 0;
+ int best = 0;
struct string_list_item *cand;
autocorrect_resolve(&autocorrect);
@@ -657,7 +658,7 @@ static const char *autocorrect_subcommand(const char *cmd,
for_each_string_list_item(cand, cmds) {
if (starts_with(cand->string, cmd)) {
- cand->util = 0;
+ cand->util = NULL;
} else {
int edit = levenshtein(cmd, cand->string,
0, 2, 1, 3) + 1;
--
2.54.0-170-g88022b8681
^ permalink raw reply related
* Re: [PATCH v2 00/10] pack-objects: integrate --path-walk and some --filter options
From: Junio C Hamano @ 2026-05-11 3:05 UTC (permalink / raw)
To: Derrick Stolee
Cc: Taylor Blau, Derrick Stolee via GitGitGadget, git,
christian.couder, johannes.schindelin, johncai86, karthik.188,
kristofferhaugsbakk, newren, peff, ps
In-Reply-To: <07b36bd8-376b-4a98-a735-0c0f75452c24@gmail.com>
Derrick Stolee <stolee@gmail.com> writes:
> On 5/5/2026 3:01 PM, Taylor Blau wrote:
>> On Tue, May 05, 2026 at 12:18:28PM -0400, Derrick Stolee wrote:
>> ...
>> I think this is a consequence of us not sending directly-referenced
>> blobs with `--filter=blob:none` when running the filters through
>> `--path-walk`. Something like:
>> ...
> Thanks for this suggestion. I got pulled away from my investigation, so
> wasn't to this point yet.
>> fixes t5310 for me. I haven't looked into any of the other failures yet
>> since you mentioned that you're looking into them, but let me know if
>> you want to tag-team any of these.
>>
>> (As a related side-note, I noticed that GIT_TEST_PACK_PATH_WALK=1 is not
>> currently in the TEST-vars CI build. I'm not sure if there are
>> historical reasons for leaving it out, but if not I think it would be
>> worthwhile to add it.)
> I think the initial idea was that the feature was too niche to add it to
> the CI builds right away. Your series is going to make it a lot more
> important, so adding this to CI builds may be valuable.
Should I expect a new [v3] iteration anytime soon? Not getting
antsy, but just going through the "What's cooking" report to see if
there are things I should immediately advance.
Thanks.
^ permalink raw reply
* What's cooking in git.git (May 2026, #02)
From: Junio C Hamano @ 2026-05-11 3:08 UTC (permalink / raw)
To: git
Here are the topics that have been cooking in my tree. Commits
prefixed with '+' are in 'next' (being in 'next' is a sign that a
topic is stable enough to be used and is a candidate to be in a
future release). Commits prefixed with '-' are only in 'seen', and
aren't considered "accepted" at all and may be annotated with a URL
to a message that raises issues but they are by no means exhaustive.
A topic without enough support may be discarded after a long period
of no activity (of course they can be resubmitted when new interests
arise).
The first batch of topics marked for graduation for quite a while
since 2.54-rc2 have all been merged to 'master'.
Copies of the source code to Git live in many repositories, and the
following is a list of the ones I push into or their mirrors. Some
repositories have only a subset of branches.
With maint, master, next, seen, todo:
git://git.kernel.org/pub/scm/git/git.git/
git://repo.or.cz/alt-git.git/
https://kernel.googlesource.com/pub/scm/git/git/
https://github.com/git/git/
https://gitlab.com/git-scm/git/
With all the integration branches and topics broken out:
https://github.com/gitster/git/
Even though the preformatted documentation in HTML and man format
are not sources, they are published in these repositories for
convenience (replace "htmldocs" with "manpages" for the manual
pages):
git://git.kernel.org/pub/scm/git/git-htmldocs.git/
https://github.com/gitster/git-htmldocs.git/
Release tarballs are available at:
https://www.kernel.org/pub/software/scm/git/
--------------------------------------------------
[Graduated to 'master']
* ar/parallel-hooks (2026-04-10) 13 commits
(merged to 'next' on 2026-04-13 at 0a6acf0d17)
+ t1800: test SIGPIPE with parallel hooks
+ hook: allow hook.jobs=-1 to use all available CPU cores
+ hook: add hook.<event>.enabled switch
+ hook: move is_known_hook() to hook.c for wider use
+ hook: warn when hook.<friendly-name>.jobs is set
+ hook: add per-event jobs config
+ hook: add -j/--jobs option to git hook run
+ hook: mark non-parallelizable hooks
+ hook: allow pre-push parallel execution
+ hook: allow parallel hook execution
+ hook: parse the hook.jobs config
+ config: add a repo_config_get_uint() helper
+ repository: fix repo_init() memleak due to missing _clear()
Hook scripts defined via the configuration system can now be
configured to run in parallel.
source: <20260410090608.75283-1-adrian.ratiu@collabora.com>
* bc/rust-by-default (2026-04-09) 4 commits
(merged to 'next' on 2026-04-23 at fb9310bfae)
+ Enable Rust by default
+ Linux: link against libdl
+ ci: install cargo on Alpine
+ docs: update version with default Rust support
Rust support is enabled by default (but still allows opting out) in
some future version of Git.
source: <20260409224434.1861422-1-sandals@crustytoothpaste.net>
* cc/promisor-auto-config-url (2026-04-07) 10 commits
(merged to 'next' on 2026-04-13 at 289fcba081)
+ t5710: use proper file:// URIs for absolute paths
+ promisor-remote: remove the 'accepted' strvec
+ promisor-remote: keep accepted promisor_info structs alive
+ promisor-remote: refactor accept_from_server()
+ promisor-remote: refactor has_control_char()
+ promisor-remote: refactor should_accept_remote() control flow
+ promisor-remote: reject empty name or URL in advertised remote
+ promisor-remote: clarify that a remote is ignored
+ promisor-remote: pass config entry to all_fields_match() directly
+ promisor-remote: try accepted remotes before others in get_direct()
(this branch is used by cc/promisor-auto-config-url-more.)
Promisor remote handling has been refactored and fixed in
preparation for auto-configuration of advertised remotes.
source: <20260407115243.358642-1-christian.couder@gmail.com>
* dl/cache-tree-fully-valid-fix (2026-04-06) 1 commit
(merged to 'next' on 2026-04-13 at 68c82a9f37)
+ cache-tree: fix inverted object existence check in cache_tree_fully_valid
The check that implements the logic to see if an in-core cache-tree
is fully ready to write out a tree object was broken, which has
been corrected.
source: <20260406192711.68870-1-davidlin@stripe.com>
* ja/doc-difftool-synopsis-style (2026-04-04) 4 commits
(merged to 'next' on 2026-04-13 at 0e6c98f313)
+ doc: convert git-describe manual page to synopsis style
+ doc: convert git-shortlog manual page to synopsis style
+ doc: convert git-range-diff manual page to synopsis style
+ doc: convert git-difftool manual page to synopsis style
Doc mark-up updates.
source: <pull.2077.git.1775322767.gitgitgadget@gmail.com>
* jc/doc-timestamps-in-stat (2026-04-10) 1 commit
(merged to 'next' on 2026-04-20 at 0680260012)
+ CodingGuidelines: st_mtimespec vs st_mtim vs st_mtime
Doc update.
source: <xmqqzf3aofdj.fsf_-_@gitster.g>
* ps/test-set-e-clean (2026-04-21) 12 commits
(merged to 'next' on 2026-04-23 at 4f69b47b94)
+ t: detect errors outside of test cases
+ t9902: fix use of `read` with `set -e`
+ t6002: fix use of `expr` with `set -e`
+ t1301: don't fail in case setfacl(1) doesn't exist or fails
+ t0008: silence error in subshell when using `grep -v`
+ t: prepare `test_when_finished ()`/`test_atexit()` for `set -e`
+ t: prepare execution of potentially failing commands for `set -e`
+ t: prepare conditional test execution for `set -e`
+ t: prepare `git config --unset` calls for `set -e`
+ t: prepare `stop_git_daemon ()` for `set -e`
+ t: prepare `test_must_fail ()` for `set -e`
+ t: prepare `test_match_signal ()` calls for `set -e`
The test suite harness and many individual test scripts have been
updated to work correctly when 'set -e' is in effect, which helps
detect misspelled test commands.
source: <20260421-b4-pks-tests-with-set-e-v6-0-26330e3061ab@pks.im>
* sb/userdiff-lisp-family (2026-04-14) 2 commits
(merged to 'next' on 2026-04-20 at 5897c04899)
+ userdiff: extend Scheme support to cover other Lisp dialects
+ userdiff: tighten word-diff test case of the scheme driver
The userdiff driver for the Scheme language has been extended to
cover other Lisp dialects.
source: <pull.2000.v4.git.1776220063.gitgitgadget@gmail.com>
* sp/refs-reduce-the-repository (2026-04-04) 3 commits
(merged to 'next' on 2026-04-09 at bb1d626802)
+ refs/reftable-backend: drop uses of the_repository
+ refs: remove the_hash_algo global state
+ refs: add struct repository parameter in get_files_ref_lock_timeout_ms()
Code clean-up to use the right instance of a repository instance in
calls inside refs subsystem.
source: <20260404135914.61195-1-shreyanshpaliwalcmsmn@gmail.com>
--------------------------------------------------
[New Topics]
* js/mingw-no-nedmalloc (2026-05-08) 3 commits
- mingw: remove the vendored compat/nedmalloc/ subtree
- mingw: drop the build-system plumbing for nedmalloc
- mingw: stop using nedmalloc
Stop using unmaintained custom allocator in Windows build which was
the last user of the code.
Will merge to 'next'.
source: <pull.2104.v3.git.1778244661.gitgitgadget@gmail.com>
* sj/submodule-update-clone-config-fix (2026-05-09) 1 commit
- submodule-config: fix reading submodule.fetchJobs
The configuration variable submodule.fetchJobs was not read correctly,
which has been corrected.
Will merge to 'next'.
source: <pull.2287.v4.git.git.1778385022964.gitgitgadget@gmail.com>
* aw/validate-proxy-url-scheme (2026-05-05) 1 commit
- http: reject unsupported proxy URL schemes
Misspelt proxy URL (e.g., httt://...) did not trigger any warning
or failure, which has been corrected.
Will merge to 'next'?
source: <20260505091941.1825-2-aminnimaj@gmail.com>
* hn/branch-prune-merged (2026-05-05) 6 commits
- branch: add --all-remotes flag
- branch: add branch.<name>.pruneMerged opt-out
- fetch: add --prune-merged
- branch: add --prune-merged <remote>
- branch: let delete_branches warn instead of error on bulk refusal
- branch: add --forked <remote>
"git branch" command learned "--prune-merged" option to remove
local branches that have already been merged to the remote-tracking
branches they track.
Expecting a reroll to remove "fetch" part?
cf. <20260505220712.93952-1-haraldnordgren@gmail.com>
source: <pull.2285.v4.git.git.1778009038.gitgitgadget@gmail.com>
* kh/doc-restore-double-underscores-fix (2026-05-05) 1 commit
- doc: restore: remove double underscore
Doc update.
Will merge to 'next'.
source: <double_underscore.670@msgid.xyz>
* mm/diff-U-takes-no-negative-values (2026-05-05) 3 commits
- xdiff: guard against negative context lengths
- diff: reject negative values for -U/--unified
- diff: reject negative values for --inter-hunk-context
The command line parser for "git diff" learned a few options take
only non-negative integers.
Will merge to 'next'?
source: <pull.2105.git.1778022144.gitgitgadget@gmail.com>
* ps/clang-w-glibc-2.43-and-_Generic (2026-05-05) 1 commit
- build: tolerate use of _Generic from glibc 2.43 with Clang
Headers from glibc 2.43 when used with clang does not allow
disabling C11 language features, causing build failures..
Will merge to 'next'.
source: <20260505-b4-pks-ci-tolerate-glibc-generic-v1-1-5786386fe512@pks.im>
* mm/git-url-parse (2026-05-01) 8 commits
- t9904: add tests for the new url-parse builtin
- doc: describe the url-parse builtin
- builtin: create url-parse command
- urlmatch: define url_parse function
- url: return URL_SCHEME_UNKNOWN instead of dying
- url: move scheme detection to URL header/source
- url: move url_is_local_not_ssh to url.h
- connect: rename enum protocol to url_scheme
The internal URL parsing logic has been made accessible via a new
subcommand "git url-parse".
Will merge to 'next'?
source: <pull.1715.v3.git.git.1777699722.gitgitgadget@gmail.com>
* kh/doc-commit-graph (2026-05-07) 1 commit
- doc: add caveat about turning off commit-graph
Ramifications of turning off commit-graph has been documented a bit
more clearly.
source: <V3_caveat_commit-graph.6b6@msgid.xyz>
* dk/doc-exclude-is-shared-per-repo (2026-05-08) 1 commit
- ignore: note info/exclude lives in GIT_COMMON_DIR, not GIT_DIR
Document the fact that .git/info/exclude is shared across worktrees
linked to the same repository.
Will merge to 'next'?
source: <d58b6e921d3005c6170fc6c47f175214acb3fa68.1778249267.git.ben.knoble+github@gmail.com>
* jc/t5551-fix-expensive (2026-05-07) 1 commit
- t5551: "GIT_TEST_LONG=Yes make test" is broken
Test fix.
Will merge to 'next'.
source: <xmqqqznmeaco.fsf@gitster.g>
* kk/paint-down-to-common-optim (2026-05-08) 1 commit
- commit-reach: early exit paint_down_to_common for single merge-base
"git merge-base" optimization.
Comments?
source: <pull.2109.git.1778252837132.gitgitgadget@gmail.com>
* st/daemon-sockaddr-fixes (2026-05-08) 1 commit
- daemon: fix network address handling bugs
Correct use of sockaddr API in "git daemon".
Comments?
source: <pull.2299.git.git.1778291290159.gitgitgadget@gmail.com>
* ag/rebase-update-refs-limit-to-branches (2026-05-10) 1 commit
- rebase: ignore non-branch update-refs
"git rebase --update-refs", when used with an rebase.instructionFormat
with "%d" (describe) in it, tried to update local branch HEAD by
mistake, which has been corrected.
Will merge to 'next'.
source: <20260510224111.64467-2-mail@abhinavg.net>
* jc/ci-enable-expensive (2026-05-10) 2 commits
- ci: enable EXPENSIVE for contributor builds
- Merge branch 'js/objects-larger-than-4gb-on-windows' into jc/ci-enable-expensive
(this branch uses js/objects-larger-than-4gb-on-windows.)
Enable expensive tests to catch topics that may cause breakages on
integration branches closer to their origin in the contributor PR
builds.
Comments?
source: <xmqqjyta9630.fsf@gitster.g>
* rs/sideband-clear-line-before-print (2026-05-10) 1 commit
- sideband: clear full line when printing remote messages
Tweak the way how sideband messages from remote are printed while
we talk with a remote repository to avoid tickling terminal
emulator glitches.
Will merge to 'next'.
source: <9826dabf-c9a6-4397-8ae6-a24f9c507f1b@web.de>
--------------------------------------------------
[Cooking]
* jh/alias-i18n-fixes (2026-04-24) 1 commit
- alias: restore support for simple dotted aliases
Further update to the i18n alias support to avoid regressions.
Will merge to 'next'?
source: <20260424161707.1514255-1-jonatan@jontes.page>
* kn/refs-generic-helpers (2026-05-04) 9 commits
- refs: use peeled tag values in reference backends
- refs: add peeled object ID to the `ref_update` struct
- refs: move object parsing to the generic layer
- update-ref: handle rejections while adding updates
- update-ref: move `print_rejected_refs()` up
- refs: return `ref_transaction_error` from `ref_transaction_update()`
- refs: extract out reflog config to generic layer
- refs: introduce `ref_store_init_options`
- refs: remove unused typedef 'ref_transaction_commit_fn'
Refactor service routines in the ref subsystem backends.
Will merge to 'next'?
source: <20260504-refs-move-to-generic-layer-v4-0-936ac2f0b1a3@gmail.com>
* ob/more-repo-config-values (2026-04-23) 8 commits
- env: move "warn_on_object_refname_ambiguity" into `struct repo_config_values`
- env: move "sparse_expect_files_outside_of_patterns" into `repo_config_values`
- env: move "core_sparse_checkout_cone" into `struct repo_config_values`
- environment: move "precomposed_unicode" into `struct repo_config_values`
- environment: move "pack_compression_level" into `struct repo_config_values`
- environment: move `zlib_compression_level` into `struct repo_config_values`
- environment: move "check_stat" into `struct repo_config_values`
- environment: move "trust_ctime" into `struct repo_config_values`
Expecting a reroll.
cf. <CAD=f0L8-_3sDGGkCzF4WA0xmUtaY_qiz__3zq5AemLgwTsqvsg@mail.gmail.com>
source: <20260423165432.143598-1-belkid98@gmail.com>
* ps/history-fixup (2026-04-26) 3 commits
- builtin/history: introduce "fixup" subcommand
- builtin/history: generalize function to commit trees
- replay: allow callers to control what happens with empty commits
"git history" learned "fixup" command.
Comments?
source: <20260427-b4-pks-history-fixup-v3-0-cb908f06264b@pks.im>
* rs/grep-column-only-match-fix (2026-04-24) 1 commit
- grep: fix --column --only-match for 2nd and later matches
"git grep" update.
Will merge to 'next'.
source: <9bd69678-f04b-41d2-ad74-a386820d34c8@web.de>
* sb/unpack-index-pack-buffer-resize (2026-04-28) 1 commit
- index-pack, unpack-objects: increase input buffer from 4 KiB to 128 KiB
Use a larger buffer size in the code paths to ingest pack stream.
Will merge to 'next'?
source: <pull.2282.v4.git.git.1777387660841.gitgitgadget@gmail.com>
* bc/sign-commit-with-custom-encoding (2026-04-27) 2 commits
- commit: sign commit after mutating buffer
- commit: name UTF-8 function appropriately
Signing commit with custom encoding was passing the data to be
signed at a wrong stage in the pipeline, which has been corrected.
Will merge to 'next'?
source: <20260427221834.1824543-1-sandals@crustytoothpaste.net>
* cc/promisor-auto-config-url-more (2026-04-27) 9 commits
- doc: promisor: improve acceptFromServer entry
- promisor-remote: auto-configure unknown remotes
- promisor-remote: trust known remotes matching acceptFromServerUrl
- promisor-remote: introduce promisor.acceptFromServerUrl
- promisor-remote: add 'local_name' to 'struct promisor_info'
- urlmatch: add url_normalize_pattern() helper
- urlmatch: change 'allow_globs' arg to bool
- t5710: simplify 'mkdir X' followed by 'git -C X init'
- Merge branch 'cc/promisor-auto-config-url' into cc/promisor-auto-config-url-more
The handling of promisor-remote protocol capability has been
loosened to allow the other side to add to the list of promisor
remotes via the promisor.acceptFromServerURL configuration
variable.
Comments?
cf. <875x4yoys5.fsf@toon--20250203-5JQV3.mail-host-address-is-not-set>
source: <20260427124108.3524129-1-christian.couder@gmail.com>
* js/maintenance-fix-deadlock-on-win10 (2026-05-07) 2 commits
- maintenance(geometric): do release the `.idx` files before repacking
- mingw: optionally use legacy (non-POSIX) delete semantics
To help Windows 10 installations, avoid removing files whose
contents are still mmap()'ed.
Will merge to 'next'.
source: <pull.2103.v2.git.1778158273.gitgitgadget@gmail.com>
* js/objects-larger-than-4gb-on-windows (2026-05-08) 11 commits
- ci: run expensive tests on push builds to integration branches
- t5608: mark >4GB tests as EXPENSIVE
- test-tool synthesize: add precomputed SHA-256 pack for 4 GiB + 1
- test-tool synthesize: precompute pack for 4 GiB + 1
- test-tool synthesize: use the unsafe hash for speed
- t5608: add regression test for >4GB object clone
- test-tool: add a helper to synthesize large packfiles
- delta, packfile: use size_t for delta header sizes
- odb, packfile: use size_t for streaming object sizes
- git-zlib: handle data streams larger than 4GB
- index-pack, unpack-objects: use size_t for object size
(this branch is used by jc/ci-enable-expensive.)
Update code paths that assumed "unsigned long" was long enough for
"size_t".
Will merge to 'next'.
source: <pull.2102.v3.git.1778228209.gitgitgadget@gmail.com>
* js/t5564-socks-use-short-path (2026-04-29) 1 commit
(merged to 'next' on 2026-05-11 at fbb23860ca)
+ t5564: use a short path for the SOCKS proxy socket
Avoid hitting the pathname limit for socks proxy socket during the
test..
Will merge to 'master'.
source: <pull.2100.v2.git.1777450974159.gitgitgadget@gmail.com>
* kh/doc-log-decorate-list (2026-04-27) 2 commits
- doc: log: use the same delimiter in description list
- doc: log: fix --decorate description list
Doc update.
Comments?
source: <CV_doc_log_--decorate_list.626@msgid.xyz>
* za/t2000-modernise-more (2026-04-29) 1 commit
- t2000: consolidate second scenario into a single test block
Test update.
Comments?
source: <20260429103607.406339-1-zakariyahali100@gmail.com>
* hn/checkout-track-fetch (2026-05-08) 1 commit
- checkout: extend --track with a "fetch" mode to refresh start-point
"git checkout --track=..." learned to optionally fetch the branch
from the remote the new branch will work with.
Comments?
cf. <f23eb128-958f-475f-911b-eac4f6daddff@gmail.com>
source: <pull.2281.v7.git.git.1778280727849.gitgitgadget@gmail.com>
* mf/revision-max-count-oldest (2026-05-09) 2 commits
- SQUASH??? tac is not portable
- revision.c: implement --max-count-oldest
"git rev-list" (and "git log" family of commands) learned a new "--max-count-oldest"
that picks oldest N commits in the range instead of the usual newest.
Comments?
source: <2f71a00b035e25b971641b77a6fa7626f1e2459c.1777578676.git.mroik@delayed.space>
* mm/line-log-cleanup (2026-04-27) 3 commits
- line-log: allow non-patch diff formats with -L
- line-log: integrate -L output with the standard log-tree pipeline
- revision: move -L setup before output_format-to-diff derivation
Code clean-up.
Comments?
source: <pull.2094.git.1777349126.gitgitgadget@gmail.com>
* pw/rename-to-get-current-worktree (2026-05-01) 1 commit
- worktree: rename get_worktree_from_repository()
Code clean-up.
Will merge to 'next'.
source: <bd48396137f8d1352d11b3bd2dca2848f24a347d.1777648798.git.phillip.wood@dunelm.org.uk>
* ds/path-walk-filters (2026-05-04) 11 commits
- path-walk: support `combine` filter
- path-walk: support `object:type` filter
- path-walk: support `tree:0` filter
- pack-objects: support sparse:oid filter with path-walk
- path-walk: add pl_sparse_trees to control tree pruning
- path-walk: support blob size limit filter
- backfill: die on incompatible filter options
- path-walk: support blobless filter
- t/perf: add pack-objects filter and path-walk benchmark
- pack-objects: pass --objects with --path-walk
- Merge branch 'en/backfill-fixes-and-edges' into ds/path-walk-filters
(this branch uses en/backfill-fixes-and-edges.)
The "git pack-objects --path-walk" traversal has been integrated
with several object filters, including blobless and sparse filters.
Expecting a reroll?
cf. <07b36bd8-376b-4a98-a735-0c0f75452c24@gmail.com>
source: <pull.2101.v2.git.1777926079.gitgitgadget@gmail.com>
* en/ort-cached-rename-with-trivial-resolution (2026-04-20) 1 commit
(merged to 'next' on 2026-05-11 at 9fe24668d9)
+ merge-ort: handle cached rename & trivial resolution interaction better
"ort" merge backend improvements.
Will merge to 'master'.
source: <pull.2095.git.1776724214171.gitgitgadget@gmail.com>
* en/ort-harden-against-corrupt-trees (2026-04-20) 5 commits
- cache-tree: fix verify_cache() to catch non-adjacent D/F conflicts
- merge-ort: abort merge when trees have duplicate entries
- merge-ort: free diff pairs queue in clear_or_reinit_internal_opts()
- merge-ort: drop unnecessary show_all_errors from collect_merge_info()
- merge-ort: propagate callback errors from traverse_trees_wrapper()
"ort" merge backend handles merging corrupt trees better by
aborting when it should.
Needs review.
source: <pull.2096.git.1776731171.gitgitgadget@gmail.com>
* jk/revert-aa-reap-transport-child-processes (2026-04-22) 1 commit
(merged to 'next' on 2026-05-11 at b41904c1d3)
+ Revert "transport-helper, connect: use clean_on_exit to reap children on abnormal exit"
Revert a recent change that introduced a regression to help mksh users.
Will merge to 'master'.
source: <20260422230020.GA1839627@coredump.intra.peff.net>
* js/ci-github-actions-update (2026-04-30) 6 commits
(merged to 'next' on 2026-05-11 at ba87f84054)
+ l10n: bump mshick/add-pr-comment from v2 to v3
+ ci: bump git-for-windows/setup-git-for-windows-sdk from v1 to v2
+ ci: bump actions/checkout from v5 to v6
+ ci: bump actions/github-script from v8 to v9
+ ci: bump actions/{upload,download}-artifact to v7 and v8
+ ci: bump microsoft/setup-msbuild from v2 to v3
Update various GitHub Actions versions.
Will merge to 'master'.
source: <pull.2097.v3.git.1777534500.gitgitgadget@gmail.com>
* mf/format-patch-cover-letter-format-docfix (2026-04-22) 1 commit
(merged to 'next' on 2026-05-11 at 3cca9cc117)
+ Fix docs for format.commitListFormat
Docfix.
Will merge to 'master'.
source: <576d29f15e016889e02c253713656cd8cbf1f04c.1776894255.git.mroik@delayed.space>
* sg/t6112-unwanted-tilde-expansion-fix (2026-04-21) 1 commit
- t6112: avoid tilde expansion
Test fix.
Will merge to 'next'.
source: <20260421192132.51172-1-szeder.dev@gmail.com>
* pw/status-rebase-todo (2026-05-01) 2 commits
- status: improve rebase todo list parsing
- sequencer: factor out parsing of todo commands
The display of the rebase todo list in "git status" has been
improved to correctly abbreviate object IDs for more commands and
avoid misinterpreting refs as object IDs.
Needs review.
source: <cover.1777648598.git.phillip.wood@dunelm.org.uk>
* ss/t7004-unhide-git-failures (2026-04-20) 3 commits
(merged to 'next' on 2026-05-11 at 9ee9feacb7)
+ t7004: avoid subshells to capture git exit codes
+ t7004: dynamically grab expected state in tests
+ t7004: drop hardcoded tag count for state verification
Test clean-up.
Will merge to 'master'.
cf. <aecNc-BNwaqFlg5c@pks.im>
source: <20260421053334.5414-1-r.siddharth.shrimali@gmail.com>
* tb/pseudo-merge-bugfixes (2026-04-21) 9 commits
- pack-bitmap: prevent pattern leak on pseudo-merge re-assignment
- Documentation: fix broken `sampleRate` in gitpacking(7)
- pack-bitmap: reject pseudo-merge "sampleRate" of 0
- pack-bitmap: parse commits in `find_pseudo_merge_group_for_ref()`
- pack-bitmap: fix pseudo-merge lookup for shared commits
- pack-bitmap: fix inverted binary search in `pseudo_merge_at()`
- pack-bitmap-write: sort pseudo-merge commit lookup table in pack order
- t5333: demonstrate various pseudo-merge bugs
- t/helper: add 'test-tool bitmap write' subcommand
Fixes many bugs in pseudo-merge code.
Expecting (hopefully minor and final) reroll.
cf. <CABPp-BGkfavqezk2SV3+K6iF8MLm8j_=ijHiPDLmv_U_o_Ykgg@mail.gmail.com>
source: <cover.1776801694.git.me@ttaylorr.com>
* ds/fetch-negotiation-options (2026-04-22) 7 commits
- send-pack: pass negotiation config in push
- remote: add remote.*.negotiationInclude config
- fetch: add --negotiation-include option for negotiation
- remote: add remote.*.negotiationRestrict config
- transport: rename negotiation_tips
- fetch: add --negotiation-restrict option
- t5516: fix test order flakiness
The negotiation tip options in "git fetch" have been reworked to
allow requiring certain refs to be sent as "have" lines, and to
restrict negotiation to a specific set of refs.
Needs review.
source: <pull.2085.v3.git.1776871546.gitgitgadget@gmail.com>
* en/backfill-fixes-and-edges (2026-04-15) 3 commits
(merged to 'next' on 2026-05-11 at baccbdf26d)
+ backfill: default to grabbing edge blobs too
+ backfill: document acceptance of revision-range in more standard manner
+ backfill: reject rev-list arguments that do not make sense
(this branch is used by ds/path-walk-filters.)
The 'git backfill' command now rejects revision-limiting options that
are incompatible with its operation, uses standard documentation for
revision ranges, and includes blobs from boundary commits by default
to improve performance of subsequent operations.
Will merge to 'master'.
cf. <6e95b82a-19e3-460e-86f7-f899c2df261d@gmail.com>
source: <pull.2088.git.1776297482.gitgitgadget@gmail.com>
* mc/http-emptyauth-negotiate-fix (2026-04-30) 4 commits
- doc: clarify http.emptyAuth values
(merged to 'next' on 2026-04-20 at 6539524ca2)
+ t5563: add tests for http.emptyAuth with Negotiate
+ http: attempt Negotiate auth in http.emptyAuth=auto mode
+ http: extract http_reauth_prepare() from retry paths
The 'http.emptyAuth=auto' configuration now correctly attempts
Negotiate authentication before falling back to manual credentials.
This allows seamless Kerberos ticket-based authentication without
requiring users to explicitly set 'http.emptyAuth=true'.
Will merge to 'next' and then to 'master'.
source: <e0f236767f81ea60f90749d1bc00ab78081efd0e.1777546472.git.gitgitgadget@gmail.com>
source: <pull.2087.git.1776331259.gitgitgadget@gmail.com>
* en/batch-prefetch (2026-04-17) 3 commits
- grep: prefetch necessary blobs
- builtin/log: prefetch necessary blobs for `git cherry`
- patch-ids.h: add missing trailing parenthesis in documentation comment
In a lazy clone, "git cherry" and "git grep" often fetch necessary
blob objects one by one from promisor remotes. It has been corrected
to collect necessary object names and fetch them in bulk to gain
reasonable performance.
Needs review.
source: <pull.2089.v2.git.1776472347.gitgitgadget@gmail.com>
* en/diffstat-utf8-truncation-fix (2026-04-20) 1 commit
- diff: fix out-of-bounds reads and NULL deref in diffstat UTF-8 truncation
The computation to shorten the filenames shown in diffstat measured
width of individual UTF-8 characters to add up, but forgot to take
into account error cases (e.g., an invalid UTF-8 sequence, or a
control character).
Will merge to 'next'?
source: <pull.2093.v3.git.1776699778177.gitgitgadget@gmail.com>
* ps/odb-in-memory (2026-04-10) 18 commits
- t/unit-tests: add tests for the in-memory object source
- odb: generic in-memory source
- odb/source-inmemory: stub out remaining functions
- odb/source-inmemory: implement `freshen_object()` callback
- odb/source-inmemory: implement `count_objects()` callback
- odb/source-inmemory: implement `find_abbrev_len()` callback
- odb/source-inmemory: implement `for_each_object()` callback
- odb/source-inmemory: convert to use oidtree
- oidtree: add ability to store data
- cbtree: allow using arbitrary wrapper structures for nodes
- odb/source-inmemory: implement `write_object_stream()` callback
- odb/source-inmemory: implement `write_object()` callback
- odb/source-inmemory: implement `read_object_stream()` callback
- odb/source-inmemory: implement `read_object_info()` callback
- odb: fix unnecessary call to `find_cached_object()`
- odb/source-inmemory: implement `free()` callback
- odb: introduce "in-memory" source
- Merge branch 'jt/odb-transaction-write' into ps/odb-in-memory
(this branch uses jt/odb-transaction-write.)
Add a new odb "in-memory" source that is meant to only hold
tentative objects (like the virtual blob object that represents the
working tree file used by "git blame").
Will merge to 'next'.
source: <20260410-b4-pks-odb-source-inmemory-v3-0-22fd0fad58fe@pks.im>
* js/adjust-tests-to-explicitly-access-bare-repo (2026-04-26) 8 commits
- safe.bareRepository: default to "explicit" with WITH_BREAKING_CHANGES
- status tests: filter `.gitconfig` from status output
- ls-files tests: filter `.gitconfig` from `--others` output
- t5601: restore `.gitconfig` after includeIf test
- t1305: use `--git-dir=.` for bare repo in include cycle test
- t1300: remove global config settings injected by test-lib.sh
- t7900: do not let `$HOME/.gitconfig` interfere with XDG tests
- test-lib: allow bare repository access when breaking changes are enabled
Some tests assume that bare repository accesses are by default
allowed; rewrite some of them to avoid the assumption, rewrite
others to explicitly set safe.bareRepository to allow them.
Will merge to 'next'?
source: <pull.2098.v2.git.1777214316.gitgitgadget@gmail.com>
* cl/conditional-config-on-worktree-path (2026-04-03) 2 commits
- config: add "worktree" and "worktree/i" includeIf conditions
- config: refactor include_by_gitdir() into include_by_path()
The [includeIf "condition"] conditional inclusion facility for
configuration files has learned to use the location of worktree
in its condition.
Comments?
source: <20260403-includeif-worktree-v3-0-109ce5782b03@black-desk.cn>
* ps/shift-root-in-graph (2026-04-27) 1 commit
- graph: add indentation for commits preceded by a parentless commit
In a history with more than one root commit, "git log --graph
--oneline" stuffed an unrelated commit immediately below a root
commit, which has been corrected by making the spot below a root
unavailable.
Will merge to 'next'?
source: <20260427102838.44867-2-pabloosabaterr@gmail.com>
* jt/config-lock-timeout (2026-04-03) 1 commit
- config: retry acquiring config.lock for 100ms
The code path to update the configuration file has been taught to
use a short timeout to retry.
Waiting for a review response.
cf. <adYvSZeN0ZVqwRhi@pks.im>
source: <20260403100135.3901610-1-joerg@thalheim.io>
* lp/repack-propagate-promisor-debugging-info (2026-04-18) 6 commits
- repack-promisor: add missing headers
- t7703: test for promisor file content after geometric repack
- t7700: test for promisor file content after repack
- repack-promisor: preserve content of promisor files after repack
- repack-promisor add helper to fill promisor file after repack
- pack-write: add explanation to promisor file content
When fetching objects into a lazily cloned repository, .promisor
files are created with information meant to help debugging. "git
repack" has been taught to carry this information forward to
packfiles that are newly created.
Comments?
source: <cover.1776384902.git.lorenzo.pegorari2002@gmail.com>
* th/promisor-quiet-per-repo (2026-04-06) 1 commit
- promisor-remote: fix promisor.quiet to use the correct repository
The "promisor.quiet" configuration variable was not used from
relevant submodules when commands like "grep --recurse-submodules"
triggered a lazy fetch, which has been corrected.
Comments?
source: <20260406183041.783800-1-vikingtc4@gmail.com>
* jt/odb-transaction-write (2026-04-02) 7 commits
- odb/transaction: make `write_object_stream()` pluggable
- object-file: generalize packfile writes to use odb_write_stream
- object-file: avoid fd seekback by checking object size upfront
- object-file: remove flags from transaction packfile writes
- odb: update `struct odb_write_stream` read() callback
- odb/transaction: use pluggable `begin_transaction()`
- odb: split `struct odb_transaction` into separate header
(this branch is used by ps/odb-in-memory.)
ODB transaction interface is being reworked to explicitly handle
object writes.
Will merge to 'next'.
source: <20260402213220.2651523-1-jltobler@gmail.com>
* sa/cat-file-batch-mailmap-switch (2026-04-15) 1 commit
- cat-file: add mailmap subcommand to --batch-command
"git cat-file --batch" learns an in-line command "mailmap"
that lets the user toggle use of mailmap.
Will merge to 'next'?
source: <20260416033250.4327-2-siddharthasthana31@gmail.com>
* tb/incremental-midx-part-3.3 (2026-04-29) 16 commits
- repack: allow `--write-midx=incremental` without `--geometric`
- repack: introduce `--write-midx=incremental`
- repack: implement incremental MIDX repacking
- packfile: ensure `close_pack_revindex()` frees in-memory revindex
- builtin/repack.c: convert `--write-midx` to an `OPT_CALLBACK`
- repack-geometry: prepare for incremental MIDX repacking
- repack-midx: extract `repack_fill_midx_stdin_packs()`
- repack-midx: factor out `repack_prepare_midx_command()`
- midx: expose `midx_layer_contains_pack()`
- repack: track the ODB source via existing_packs
- midx: support custom `--base` for incremental MIDX writes
- midx: introduce `--no-write-chain-file` for incremental MIDX writes
- midx: use `strvec` for `keep_hashes`
- midx: build `keep_hashes` array in order
- midx: use `strset` for retained MIDX files
- midx-write: handle noop writes when converting incremental chains
The repacking code has been refactored and compaction of MIDX layers
have been implemented, and incremental strategy that does not require
all-into-one repacking has been introduced.
Will merge to 'next'?
source: <cover.1777507303.git.me@ttaylorr.com>
* jd/unpack-trees-wo-the-repository (2026-03-31) 2 commits
- unpack-trees: use repository from index instead of global
- unpack-trees: use repository from index instead of global
A handful of inappropriate uses of the_repository have been
rewritten to use the right repository structure instance in the
unpack-trees.c codepath.
Comments?
source: <pull.2258.v2.git.git.1774971267.gitgitgadget@gmail.com>
* ps/setup-wo-the-repository (2026-04-20) 18 commits
- setup: stop using `the_repository` in `init_db()`
- setup: stop using `the_repository` in `create_reference_database()`
- setup: stop using `the_repository` in `initialize_repository_version()`
- setup: stop using `the_repository` in `check_repository_format()`
- setup: stop using `the_repository` in `upgrade_repository_format()`
- setup: stop using `the_repository` in `setup_git_directory()`
- setup: stop using `the_repository` in `setup_git_directory_gently()`
- setup: stop using `the_repository` in `setup_git_env()`
- setup: stop using `the_repository` in `set_git_work_tree()`
- setup: stop using `the_repository` in `setup_work_tree()`
- setup: stop using `the_repository` in `enter_repo()`
- setup: stop using `the_repository` in `verify_non_filename()`
- setup: stop using `the_repository` in `verify_filename()`
- setup: stop using `the_repository` in `path_inside_repo()`
- setup: stop using `the_repository` in `prefix_path()`
- setup: stop using `the_repository` in `is_inside_git_dir()`
- setup: stop using `the_repository` in `is_inside_worktree()`
- setup: replace use of `the_repository` in static functions
Many uses of the_repository has been updated to use a more
appropriate struct repository instance in setup.c codepath.
Needs review.
source: <20260420-pks-setup-wo-the-repository-v1-0-f4a81c4988e8@pks.im>
* kh/doc-trailers (2026-04-13) 9 commits
- doc: interpret-trailers: document comment line treatment
- doc: interpret-trailers: commit to “trailer block” term
- doc: interpret-trailers: add key format example
- doc: interpret-trailers: explain key format
- doc: interpret-trailers: explain the format after the intro
- doc: interpret-trailers: not just for commit messages
- doc: interpret-trailers: use “metadata” in Name as well
- doc: interpret-trailers: replace “lines” with “metadata”
- doc: interpret-trailers: stop fixating on RFC 822
Documentation updates.
Needs review.
source: <V2_CV_doc_int-tr_key_format.613@msgid.xyz>
* ps/graph-lane-limit (2026-03-27) 3 commits
- graph: add truncation mark to capped lanes
- graph: add --graph-lane-limit option
- graph: limit the graph width to a hard-coded max
The graph output from commands like "git log --graph" can now be
limited to a specified number of lanes, preventing overly wide output
in repositories with many branches.
Needs review.
cf. <bdff0a5d-b738-4053-9b72-08eba88156de@kdbg.org>
source: <20260328001113.1275291-1-pabloosabaterr@gmail.com>
* jr/bisect-custom-terms-in-output (2026-04-17) 2 commits
- rev-parse: use selected alternate terms to look up refs
- bisect: use selected alternate terms in status output
"git bisect" now uses the selected terms (e.g., old/new) more
consistently in its output.
Needs review.
source: <20260417-bisect-terms-v3-0-d659fa547261@schlaraffenlan.de>
* ua/push-remote-group (2026-05-03) 3 commits
- push: support pushing to a remote group
- remote: move remote group resolution to remote.c
- remote: fix sign-compare warnings in push_cas_option
"git push" learned to take a "remote group" name to push to, which
causes pushes to multiple places, just like "git fetch" would do.
Comments?
source: <20260503153402.1333220-1-usmanakinyemi202@gmail.com>
* hn/git-checkout-m-with-stash (2026-04-28) 5 commits
- checkout -m: autostash when switching branches
- checkout: rollback lock on early returns in merge_working_tree
- sequencer: teach autostash apply to take optional conflict marker labels
- sequencer: allow create_autostash to run silently
- stash: add --label-ours, --label-theirs, --label-base for apply
"git checkout -m another-branch" was invented to deal with local
changes to paths that are different between the current and the new
branch, but it gave only one chance to resolve conflicts. The command
was taught to create a stash to save the local changes.
Will merge to 'next'.
source: <pull.2234.v16.git.git.1777401552.gitgitgadget@gmail.com>
* kh/name-rev-custom-format (2026-05-07) 5 commits
- format-rev: introduce builtin for on-demand pretty formatting
- name-rev: make dedicated --annotate-stdin --name-only test
- name-rev: factor code for sharing with a new command
- name-rev: run clang-format before factoring code
- name-rev: wrap both blocks in braces
A new builtin "git format-rev" is introduced for pretty formatting
one revision expression per line or commit object names found in
running text.
Will merge to 'next'.
source: <V4_CV_format-rev.6aa@msgid.xyz>
* js/parseopt-subcommand-autocorrection (2026-04-27) 11 commits
- SQUASH???
- doc: document autocorrect API
- parseopt: add tests for subcommand autocorrection
- parseopt: enable subcommand autocorrection for git-remote and git-notes
- parseopt: autocorrect mistyped subcommands
- autocorrect: provide config resolution API
- autocorrect: rename AUTOCORRECT_SHOW to AUTOCORRECT_HINT
- autocorrect: use mode and delay instead of magic numbers
- help: move tty check for autocorrection to autocorrect.c
- help: make autocorrect handling reusable
- parseopt: extract subcommand handling from parse_options_step()
The parse-options library learned to auto-correct misspelled
subcommand names.
Expecting a reroll.
source: <SY0P300MB0801677A2A1E0FD38D06A841CE2A2@SY0P300MB0801.AUSP300.PROD.OUTLOOK.COM>
* ab/clone-default-object-filter (2026-03-14) 1 commit
- clone: add clone.<url>.defaultObjectFilter config
"git clone" learns to pay attention to "clone.<url>.defaultObjectFilter"
configuration and behave as if the "--filter=<filter-spec>" option
was given on the command line.
Expecting review responses.
cf. <abe1l8ONmFIhzaxi@pks.im>
source: <pull.2058.v6.git.1773553022381.gitgitgadget@gmail.com>
* jc/neuter-sideband-fixup (2026-03-05) 6 commits
(merged to 'next' on 2026-03-13 at 5a4098b0cd)
+ sideband: drop 'default' configuration
+ sideband: offer to configure sanitizing on a per-URL basis
+ sideband: add options to allow more control sequences to be passed through
+ sideband: do allow ANSI color sequences by default
+ sideband: introduce an "escape hatch" to allow control characters
+ sideband: mask control characters
(this branch is used by jc/neuter-sideband-post-3.0.)
Try to resurrect and reboot a stalled "avoid sending risky escape
sequences taken from sideband to the terminal" topic by Dscho. The
plan is to keep it in 'next' long enough to see if anybody screams
with the "everything dropped except for ANSI color escape sequences"
default.
Will keep in 'next' a bit longer than usual.
source: <20260305233452.3727126-1-gitster@pobox.com>
* jc/neuter-sideband-post-3.0 (2026-03-05) 2 commits
- sideband: delay sanitizing by default to Git v3.0
- Merge branch 'jc/neuter-sideband-fixup' into jc/neuter-sideband-post-3.0
(this branch uses jc/neuter-sideband-fixup.)
The final step, split from earlier attempt by Dscho, to loosen the
sideband restriction for now and tighten later at Git v3.0 boundary.
On hold, until jc/neuter-sideband-fixup cooks long enough in 'next'.
(this branch uses jc/neuter-sideband-fixup.)
source: <20260305233452.3727126-8-gitster@pobox.com>
* cs/subtree-split-recursion (2026-03-05) 3 commits
- contrib/subtree: reduce recursion during split
- contrib/subtree: functionalize split traversal
- contrib/subtree: reduce function side-effects
When processing large history graphs on Debian or Ubuntu, "git
subtree" can die with a "recursion depth reached" error.
Comments?
source: <20260305-cs-subtree-split-recursion-v2-0-7266be870ba9@howdoi.land>
* pt/promisor-lazy-fetch-no-recurse (2026-03-11) 1 commit
- promisor-remote: prevent lazy-fetch recursion in child fetch
The mechanism to avoid recursive lazy-fetch from promisor remotes
was not propagated properly to child "git fetch" processes, which
has been corrected.
Will discard.
cf. <xmqqik9s6qvd.fsf@gitster.g>
source: <pull.2224.v3.git.git.1773238778894.gitgitgadget@gmail.com>
* pt/fsmonitor-linux (2026-04-15) 13 commits
- fsmonitor: convert shown khash to strset in do_handle_client
- fsmonitor: add tests for Linux
- fsmonitor: add timeout to daemon stop command
- fsmonitor: close inherited file descriptors and detach in daemon
- run-command: add close_fd_above_stderr option
- fsmonitor: implement filesystem change listener for Linux
- fsmonitor: rename fsm-settings-darwin.c to fsm-settings-unix.c
- fsmonitor: rename fsm-ipc-darwin.c to fsm-ipc-unix.c
- fsmonitor: use pthread_cond_timedwait for cookie wait
- compat/win32: add pthread_cond_timedwait
- fsmonitor: fix hashmap memory leak in fsmonitor_run_daemon
- fsmonitor: fix khash memory leak in do_handle_client
- t9210, t9211: disable GIT_TEST_SPLIT_INDEX for scalar clone tests
The fsmonitor daemon has been implemented for Linux.
Will merge to 'next'?
source: <pull.2147.v15.git.git.1776259657.gitgitgadget@gmail.com>
* pw/xdiff-shrink-memory-consumption (2026-05-04) 5 commits
- xdiff: reduce the size of array
- xprepare: simplify error handling
- xdiff: cleanup xdl_clean_mmatch()
- xdiff: reduce size of action arrays
- Merge branch 'en/xdiff-cleanup-3' into pw/xdiff-shrink-memory-consumption
(this branch uses en/xdiff-cleanup-3.)
Shrink wasted memory in Myers diff that does not account for common
prefix and suffix removal.
Will merge to 'next'?
source: <cover.1777903579.git.phillip.wood@dunelm.org.uk>
* en/xdiff-cleanup-3 (2026-04-29) 6 commits
- xdiff/xdl_cleanup_records: make execution of action easier to follow
- xdiff/xdl_cleanup_records: make setting action easier to follow
- xdiff/xdl_cleanup_records: make limits more clear
- xdiff/xdl_cleanup_records: use unambiguous types
- xdiff: use unambiguous types in xdl_bogo_sqrt()
- xdiff/xdl_cleanup_records: delete local recs pointer
(this branch is used by pw/xdiff-shrink-memory-consumption.)
Preparation of the xdiff/ codebase to work with Rust.
Will merge to 'next'.
source: <pull.2156.v6.git.git.1777500495.gitgitgadget@gmail.com>
^ 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