* Re: [PATCH 0/2] parse-options: introduce die_for_required_opt() helper
From: Christian Couder @ 2026-06-04 7:45 UTC (permalink / raw)
To: Siddharth Shrimali; +Cc: git, gitster, toon, jn.avila
In-Reply-To: <20260603111044.39116-1-r.siddharth.shrimali@gmail.com>
On Wed, Jun 3, 2026 at 1:11 PM Siddharth Shrimali
<r.siddharth.shrimali@gmail.com> wrote:
>
> Many built-in commands in Git manually check for option prerequisites
> (i.e., option X relies on option Y being present) using explicit
> conditional blocks and duplicated error message strings.
>
> This short series comes out of a discussion with Christian about
> localization and code duplication. To address these issues, it
> introduces a centralized API helper that handles simple option
> prerequisites safely.
I think it would be nice to mention around here that the new function
was inspired by die_for_incompatible_opt2() and similar functions.
> - Patch 1 introduces the `die_for_required_opt()` helper function
> inside parse-options.
>
> - Patch 2 cleans up `builtin/add.c` as a proof-of-concept by migrating
> its manual prerequisite checks for '--ignore-missing' and
> '--pathspec-file-nul' over to the new helper.
>
> If this initial approach looks good, we can later extend the helper
> to handle more complex multi-option dependencies.
Yeah, for functions with more arguments to address cases like "option
X requires both options Y and Z" or "option X requires either option Y
or option Z", I think it's not clear yet what would be the most useful
and what's the best name for such functions.
^ permalink raw reply
* Re: [PATCH] Makefile: drop duplicate %.a from link recipes
From: Harald Nordgren @ 2026-06-04 7:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Harald Nordgren via GitGitGadget, git
In-Reply-To: <CAHwyqnV6uh_yyO9FcUiXKfKPt15ojR3GOmRC06pW55f=KRu=Zw@mail.gmail.com>
Maybe we can do this to get around the brittleness for all ~10 places:
```
-LIBS = $(filter-out %.o, $(GITLIBS)) $(EXTLIBS)
+LIBS = $(filter %.a,$^) $(filter-out $(filter %.a,$^),$(filter-out
%.o,$(GITLIBS)) $(EXTLIBS))
BASIC_CFLAGS += $(COMPAT_CFLAGS)
LIB_OBJS += $(COMPAT_OBJS)
@@ -3392,7 +3395,7 @@ perf: all
t/helper/test-tool$X: $(patsubst %,t/helper/%,$(TEST_BUILTINS_OBJS))
$(UNIT_TEST_DIR)/test-lib.o
t/helper/test-%$X: t/helper/test-%.o GIT-LDFLAGS $(GITLIBS)
- $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter
%.o,$^) $(filter %.a,$^) $(LIBS)
+ $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
check-sha1:: t/helper/test-tool$X
t/helper/test-sha1.sh
@@ -4015,13 +4018,13 @@ fuzz-all: $(FUZZ_PROGRAMS)
$(FUZZ_PROGRAMS): %: %.o oss-fuzz/dummy-cmd-main.o $(GITLIBS) GIT-LDFLAGS
$(QUIET_LINK)$(FUZZ_CXX) $(FUZZ_CXXFLAGS) -o $@ $(ALL_LDFLAGS) \
-Wl,--allow-multiple-definition \
- $(filter %.o,$^) $(filter %.a,$^) $(LIBS) $(LIB_FUZZING_ENGINE)
+ $(filter %.o,$^) $(LIBS) $(LIB_FUZZING_ENGINE)
$(UNIT_TEST_PROGS): $(UNIT_TEST_BIN)/%$X: $(UNIT_TEST_DIR)/%.o
$(UNIT_TEST_OBJS) \
$(GITLIBS) GIT-LDFLAGS
$(call mkdir_p_parent_template)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) \
- $(filter %.o,$^) $(filter %.a,$^) $(LIBS)
+ $(filter %.o,$^) $(LIBS)
GIT-TEST-SUITES: FORCE
@FLAGS='$(CLAR_TEST_SUITES)'; \
```
Harald
On Thu, Jun 4, 2026 at 9:06 AM Harald Nordgren <haraldnordgren@gmail.com> wrote:
>
> On Thu, Jun 4, 2026 at 2:33 AM Junio C Hamano <gitster@pobox.com> wrote:
> >
> > "Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
> >
> > > t/helper/test-%$X: t/helper/test-%.o GIT-LDFLAGS $(GITLIBS)
> > > - $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(filter %.a,$^) $(LIBS)
> > > + $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
> >
> > I think the reason why the pattern to use only the .o files among
> > the prerequisites and then use only the .a files among the same
> > prerequisites (both filters $^) is used here is to make sure that the
> > linker sees object files first before library archives, so that by
> > the time its left-to-right scan sees the first library archive, all
> > the missing symbols in the object files are known. The above change
> > depends on LIBS being a strict superset of all the library archive
> > files ($GITLIBS in the current code, but that can be updated in the
> > future) listed as prerequisites for the rule, but there is nothing to
> > guarantee that, so it looks brittle.
> >
> > Exact same comment applies to the other two rules touched by this patch.
>
> Hmm, there are other constructs like this that rely on $(LIBS) being a
> superset of the archives, so the three rules changed here align with
> the trend rather than introduce a new trend.
>
> Not saying we shouldn't find a way to handle the overall brittleness.
>
>
> Harald
^ permalink raw reply
* Re: [PATCH v3] index-pack: retain child bases in delta cache
From: Jeff King @ 2026-06-04 7:12 UTC (permalink / raw)
To: Arijit Banerjee via GitGitGadget
Cc: git, Ævar Arnfjörð Bjarmason, Junio C Hamano,
Derrick Stolee, Arijit Banerjee, Arijit Banerjee
In-Reply-To: <pull.2131.v3.git.1780445118653.gitgitgadget@gmail.com>
On Wed, Jun 03, 2026 at 12:05:17AM +0000, Arijit Banerjee via GitGitGadget wrote:
> * Addressed Jeff King's review question by releasing cached base data
> after all direct children have been dispatched, while keeping the
> existing subtree bookkeeping intact.
> * Re-ran t/t5302-pack-index.sh, p5302-pack-index.sh, and end-to-end
> full clone spot checks with the precise-release version.
Thanks for humoring me. I fully expected the answer to be "it is hard to
do and doesn't show much improvement, so let's not bother". ;)
It was hard to see the difference between v2 and v3 performance (which I
tried to dig out from the range-diff below), but it looks like it was
basically none. I did my own run of p5302 between the two versions using
both git.git and linux.git, and likewise didn't find anything.
I guess it would make a difference only if we were routinely expiring
useful items out of the cache due to the limit. And even though
linux.git is a "large" repo compared to git.git, cache locality here is
mostly based on how wide the delta tree for a file gets (that is, how
often we go down one chain, caching bases, while still finding it useful
to keep earlier parts of the chain to go down a parallel path).
And that probably has less to do with overall repo size rather than with
how we tend to pack things. Though I guess a repo with a lot of large
files might see more cache pressure (just because each single entry
"costs" more). We could simulate that by dropping the cache size in
p5302, but I still couldn't find any effect even with a tiny cache.
(Actually, with a tiny cache it looked like things got ~1% slower; maybe
noise, but maybe extra thread contention due to the release code?).
So I am happy with either v2 or v3.
-Peff
^ permalink raw reply
* Re: [PATCH] read_gitfile_gently(): return non-repo path on error
From: Patrick Steinhardt @ 2026-06-04 7:08 UTC (permalink / raw)
To: Jeff King; +Cc: git, Tian Yuchen
In-Reply-To: <20260604062720.GA3195904@coredump.intra.peff.net>
On Thu, Jun 04, 2026 at 02:27:20AM -0400, Jeff King wrote:
> On Tue, Jun 02, 2026 at 10:36:34AM +0200, Patrick Steinhardt wrote:
>
> > > The correct output (which this patch produces) is:
> > >
> > > fatal: not a git repository: /home/peff/compile/git/.git/worktrees/worktree3
> > >
> > > And indeed, that path is missing. But why? I feel like I've run into
> > > this same problem occasionally over the last year or so, but never
> > > before. Did we get more aggressive about removing worktrees at some
> > > point? I haven't been able to reproduce whatever is killing off the
> > > worktree directory, and by the time I see the error it is long gone.
> >
> > Both git-gc(1) and git-maintenance(1) prune orphaned worktrees that are
> > older than three months by default, which can be configured via
> > "gc.worktreePruneExpire". That logic has changed in 4dda60c9df (Merge
> > branch 'ps/maintenance-missing-tasks', 2025-05-15), which would kind of
> > match your timeline.
> >
> > But rereading that patch series I cannot really see how it could result
> > in more aggressive pruning of worktrees. We used `git worktree prune
> > --expire <expiry>` before that series, and we still use that logic now.
>
> Yeah, but this .git/worktrees/ directory shouldn't be pruned _at all_.
> The worktree itself is still there (which is why I'm getting the error).
> So perhaps there's a bug in checking that things are still there, or
> perhaps something is corrupting .git/worktrees/*/gitdir.
Oh, that sounds somewhat scary.
> Another option is "I moved my git checkout and the worktree prune
> couldn't find the directory as an absolute path", but I'm sure I didn't
> do that.
>
> An even more exotic option is that I run Git's test suite a lot, and
> very occasionally bugs in the test suite cause the script to escape the
> trash directory. And some scripts do run "rm -r .git/worktrees". I find
> it pretty unlikely for that to be the culprit though.
>
> Oh well. I don't have any good leads, so I guess I'll see if it happens
> again. But maybe now if somebody else sees it we can commiserate. :)
I'll certainly be on the watchout.
Patrick
^ permalink raw reply
* Re: [PATCH] Makefile: drop duplicate %.a from link recipes
From: Harald Nordgren @ 2026-06-04 7:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Harald Nordgren via GitGitGadget, git
In-Reply-To: <xmqqik7zqh4p.fsf@gitster.g>
On Thu, Jun 4, 2026 at 2:33 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> "Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > t/helper/test-%$X: t/helper/test-%.o GIT-LDFLAGS $(GITLIBS)
> > - $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(filter %.a,$^) $(LIBS)
> > + $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
>
> I think the reason why the pattern to use only the .o files among
> the prerequisites and then use only the .a files among the same
> prerequisites (both filters $^) is used here is to make sure that the
> linker sees object files first before library archives, so that by
> the time its left-to-right scan sees the first library archive, all
> the missing symbols in the object files are known. The above change
> depends on LIBS being a strict superset of all the library archive
> files ($GITLIBS in the current code, but that can be updated in the
> future) listed as prerequisites for the rule, but there is nothing to
> guarantee that, so it looks brittle.
>
> Exact same comment applies to the other two rules touched by this patch.
Hmm, there are other constructs like this that rely on $(LIBS) being a
superset of the archives, so the three rules changed here align with
the trend rather than introduce a new trend.
Not saying we shouldn't find a way to handle the overall brittleness.
Harald
^ permalink raw reply
* Re: What's cooking in git.git (Jun 2026, #02)
From: Patrick Steinhardt @ 2026-06-04 6:52 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20260604062122.GB3194609@coredump.intra.peff.net>
On Thu, Jun 04, 2026 at 02:21:22AM -0400, Jeff King wrote:
> On Thu, Jun 04, 2026 at 11:35:50AM +0900, Junio C Hamano wrote:
>
> > * ps/t7527-fix-tap-output (2026-06-02) 4 commits
> > - t: let prove fail when parsing invalid TAP output
> > - t/lib-git-p4: silence output when killing p4d and its watchdog
> > - t/test-lib: silence EBUSY errors on Windows during test cleanup
> > - t7527: fix broken TAP output
> >
> > A recent regression in t7527 that broke TAP output has been fixed,
> > some other test noise that also broke TAP output has been silenced,
> > and 'prove' is now configured to fail on invalid TAP output to
> > prevent future regressions.
> >
> > Expecting a (small and hopefully final) reroll.
> > cf. <xmqqtsrlw09t.fsf@gitster.g>
> > source: <20260603-pks-t7527-fix-tap-output-v2-0-cf3af5694e20@pks.im>
>
> I guess this is the source of several CI failures on jch/seen that look
> like:
>
> Test Summary Report
> -------------------
> t7810-grep.sh (Wstat: 0 Tests: 264 Failed: 0)
> Parse errors: Unknown TAP token: "/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)"
>
> This happens in the dockerized jobs whose images presumably have a very
> minimal locale setup. I don't know if this is a sign that the tests have
> never been doing quite what we expect on those platforms, or if it's
> simply noise that is now being caught.
Ah, thanks for flagging. I'll investigate.
Patrick
^ permalink raw reply
* Re: [PATCH v2 0/2] Small updates to SubmittingPatches
From: Patrick Steinhardt @ 2026-06-04 6:50 UTC (permalink / raw)
To: Derrick Stolee; +Cc: Junio C Hamano, git
In-Reply-To: <c54f3571-ff7b-4caa-b75d-a739ed87ec9d@gmail.com>
On Tue, Jun 02, 2026 at 11:24:48AM -0400, Derrick Stolee wrote:
> On 6/2/2026 10:43 AM, Junio C Hamano wrote:
> > Recently I gave some advice on how a cover letter should
> > try to sell the idea to widest possible audience, and then
> > I realized that we do not seem to teach how in our guides.
> >
> > Here is a small series to do so.
> >
> > In this round, a few typos have been corrected, and improvements are
> > made thanks to help from Christian, Stolee, and Patrick.
> This version LGTM.
Agreed, I'm happy with this version.
Patrick
^ permalink raw reply
* [PATCH v3] git-gui: silence install recipes under "make -s"
From: Harald Nordgren via GitGitGadget @ 2026-06-04 6:48 UTC (permalink / raw)
To: git; +Cc: Johannes Sixt, Harald Nordgren, Harald Nordgren
In-Reply-To: <pull.2318.v2.git.git.1780510415838.gitgitgadget@gmail.com>
From: Harald Nordgren <haraldnordgren@gmail.com>
Several install and uninstall recipes embed "echo" calls that fire as
part of the recipe itself, so the install banners (DEST, INSTALL,
LINK, REMOVE) were visible whenever the variables expand non-empty.
Guard the whole "ifndef V" block on "-s" so the loud variants are
selected only when "-s" is absent and V=1 is unset. The existing
"-s" check also had its findstring arguments in the wrong order
(needle "-s" never fit in haystack "s"), so swap them while moving
the check to wrap the block.
Signed-off-by: Harald Nordgren <harald.nordgren@kostdoktorn.se>
---
git-gui: silence install recipes under "make -s"
Added sentences to the commit message noting that the old findstring arg
order was broken (needle never fit haystack).
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2318%2FHaraldNordgren%2Fgit-gui-respect-silent-flag-v3
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2318/HaraldNordgren/git-gui-respect-silent-flag-v3
Pull-Request: https://github.com/git/git/pull/2318
Range-diff vs v2:
1: 4e4029c8e8 ! 1: 1375fdc1aa git-gui: silence install recipes under "make -s"
@@ Commit message
LINK, REMOVE) were visible whenever the variables expand non-empty.
Guard the whole "ifndef V" block on "-s" so the loud variants are
- selected only when "-s" is absent and V=1 is unset.
+ selected only when "-s" is absent and V=1 is unset. The existing
+ "-s" check also had its findstring arguments in the wrong order
+ (needle "-s" never fit in haystack "s"), so swap them while moving
+ the check to wrap the block.
Signed-off-by: Harald Nordgren <harald.nordgren@kostdoktorn.se>
git-gui/Makefile | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/git-gui/Makefile b/git-gui/Makefile
index ca01068810..d33204e875 100644
--- a/git-gui/Makefile
+++ b/git-gui/Makefile
@@ -64,6 +64,7 @@ REMOVE_F0 = $(RM_RF) # space is required here
REMOVE_F1 =
CLEAN_DST = true
+ifneq ($(findstring s,$(firstword -$(MAKEFLAGS))),s)
ifndef V
QUIET = @
QUIET_GEN = $(QUIET)echo ' ' GEN '$@' &&
@@ -89,6 +90,7 @@ ifndef V
REMOVE_F0 = dst=
REMOVE_F1 = && echo ' ' REMOVE `basename "$$dst"` && $(RM_RF) "$$dst"
endif
+endif
TCLTK_PATH ?= wish
ifeq (./,$(dir $(TCLTK_PATH)))
@@ -97,10 +99,6 @@ else
TCL_PATH ?= $(dir $(TCLTK_PATH))$(notdir $(subst wish,tclsh,$(TCLTK_PATH)))
endif
-ifeq ($(findstring $(firstword -$(MAKEFLAGS)),s),s)
-QUIET_GEN =
-endif
-
-include config.mak
DESTDIR_SQ = $(subst ','\'',$(DESTDIR))
base-commit: 9ac3f193c05c2237e2b14ebaa1149e9fc8a1abe0
--
gitgitgadget
^ permalink raw reply related
* Re: [PATCH v1 2/4] read-cache: move 'ce_mode_from_stat()' to 'read-cache.c'
From: Patrick Steinhardt @ 2026-06-04 6:47 UTC (permalink / raw)
To: Tian Yuchen; +Cc: git, christian.couder, Ayush Chandekar, Olamide Caleb Bello
In-Reply-To: <20260530160520.77859-3-cat@malon.dev>
On Sun, May 31, 2026 at 12:05:17AM +0800, Tian Yuchen wrote:
> diff --git a/read-cache.h b/read-cache.h
> index 043da1f1aa..3c4af2faeb 100644
> --- a/read-cache.h
> +++ b/read-cache.h
> @@ -5,20 +5,8 @@
> #include "object.h"
> #include "pathspec.h"
>
> -static inline unsigned int ce_mode_from_stat(const struct cache_entry *ce,
> - unsigned int mode)
> -{
> - extern int trust_executable_bit, has_symlinks;
> - if (!has_symlinks && S_ISREG(mode) &&
> - ce && S_ISLNK(ce->ce_mode))
> - return ce->ce_mode;
> - if (!trust_executable_bit && S_ISREG(mode)) {
> - if (ce && S_ISREG(ce->ce_mode))
> - return ce->ce_mode;
> - return create_ce_mode(0666);
> - }
> - return create_ce_mode(mode);
> -}
> +unsigned int ce_mode_from_stat(const struct cache_entry *ce,
> + unsigned int mode);
This is moving goalposts a bit, so please feel free to ignore: should we
maybe add a small comment what the function does while at it?
Patrick
^ permalink raw reply
* Re: [PATCH v2 2/4] doc: replay: improve config description
From: Kristoffer Haugsbakk @ 2026-06-04 6:31 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: Junio C Hamano, Siddharth Asthana, git
In-Reply-To: <aiEa5EWeAaaMsqRR@pks.im>
On Thu, Jun 4, 2026, at 08:27, Patrick Steinhardt wrote:
> On Wed, Jun 03, 2026 at 06:04:23PM +0200,
> kristofferhaugsbakk@fastmail.com wrote:
>> From: Kristoffer Haugsbakk <code@khaugsbakk.name>
>>
>> First of all, this bullet list for `--ref-action` introduces a term with
>> a colon. This is exactly what a description list is, structurally. Let’s
>> be sylistically consistent and use the description list markup
>
> s/sylistically/stylistically/
Thanks, I’ll make the correction.
>
>> diff --git a/Documentation/git-replay.adoc b/Documentation/git-replay.adoc
>> index f9ca2db2833..4de85088d6c 100644
>> --- a/Documentation/git-replay.adoc
>> +++ b/Documentation/git-replay.adoc
>> @@ -211,6 +211,7 @@ to use bare commit IDs instead of branch names.
>>
>> CONFIGURATION
>> -------------
>> +:git-replay: 1
>> include::config/replay.adoc[]
>
> Not quite sure, but was this change supposed to be part of the preceding
> commit, where you also added the include?
No, because the conditional is only being put to use now. That was the
intention anyway. Maybe there is some reason to put it in the first
commit?
Thanks!
^ permalink raw reply
* Re: [PATCH v2 2/4] doc: replay: improve config description
From: Patrick Steinhardt @ 2026-06-04 6:27 UTC (permalink / raw)
To: kristofferhaugsbakk
Cc: Junio C Hamano, Kristoffer Haugsbakk, Siddharth Asthana, git
In-Reply-To: <V2_doc_replay_improve_config.769@msgid.xyz>
On Wed, Jun 03, 2026 at 06:04:23PM +0200, kristofferhaugsbakk@fastmail.com wrote:
> From: Kristoffer Haugsbakk <code@khaugsbakk.name>
>
> First of all, this bullet list for `--ref-action` introduces a term with
> a colon. This is exactly what a description list is, structurally. Let’s
> be sylistically consistent and use the description list markup
s/sylistically/stylistically/
> diff --git a/Documentation/git-replay.adoc b/Documentation/git-replay.adoc
> index f9ca2db2833..4de85088d6c 100644
> --- a/Documentation/git-replay.adoc
> +++ b/Documentation/git-replay.adoc
> @@ -211,6 +211,7 @@ to use bare commit IDs instead of branch names.
>
> CONFIGURATION
> -------------
> +:git-replay: 1
> include::config/replay.adoc[]
Not quite sure, but was this change supposed to be part of the preceding
commit, where you also added the include?
Patrick
^ permalink raw reply
* Re: [PATCH] read_gitfile_gently(): return non-repo path on error
From: Jeff King @ 2026-06-04 6:27 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Tian Yuchen
In-Reply-To: <ah6WEtk2pXyViEQA@pks.im>
On Tue, Jun 02, 2026 at 10:36:34AM +0200, Patrick Steinhardt wrote:
> > The correct output (which this patch produces) is:
> >
> > fatal: not a git repository: /home/peff/compile/git/.git/worktrees/worktree3
> >
> > And indeed, that path is missing. But why? I feel like I've run into
> > this same problem occasionally over the last year or so, but never
> > before. Did we get more aggressive about removing worktrees at some
> > point? I haven't been able to reproduce whatever is killing off the
> > worktree directory, and by the time I see the error it is long gone.
>
> Both git-gc(1) and git-maintenance(1) prune orphaned worktrees that are
> older than three months by default, which can be configured via
> "gc.worktreePruneExpire". That logic has changed in 4dda60c9df (Merge
> branch 'ps/maintenance-missing-tasks', 2025-05-15), which would kind of
> match your timeline.
>
> But rereading that patch series I cannot really see how it could result
> in more aggressive pruning of worktrees. We used `git worktree prune
> --expire <expiry>` before that series, and we still use that logic now.
Yeah, but this .git/worktrees/ directory shouldn't be pruned _at all_.
The worktree itself is still there (which is why I'm getting the error).
So perhaps there's a bug in checking that things are still there, or
perhaps something is corrupting .git/worktrees/*/gitdir.
Another option is "I moved my git checkout and the worktree prune
couldn't find the directory as an absolute path", but I'm sure I didn't
do that.
An even more exotic option is that I run Git's test suite a lot, and
very occasionally bugs in the test suite cause the script to escape the
trash directory. And some scripts do run "rm -r .git/worktrees". I find
it pretty unlikely for that to be the culprit though.
Oh well. I don't have any good leads, so I guess I'll see if it happens
again. But maybe now if somebody else sees it we can commiserate. :)
-Peff
^ permalink raw reply
* Re: Mirror repositories for submodules
From: Jeff King @ 2026-06-04 6:16 UTC (permalink / raw)
To: Simon Richter; +Cc: Junio C Hamano, Benson Muite, git
In-Reply-To: <d64e7f31-4e00-478c-ab31-b671242865fb@hogyros.de>
On Thu, Jun 04, 2026 at 02:11:38PM +0900, Simon Richter wrote:
> Cloning from our server will, depending on what upstream uses, either a
> relative URL (which will go to our server, but we have little control over
> what the name part of the repository base URL is going to be), or an
> absolute URL that instructs clients to pull from another place, which
> conflicts with our goal to have a self-contained archive.
>
> The idea posited earlier, to have a "repository identity" that remains the
> same across forks and clones, is somewhat appealing, but the best idea I can
> come up with is generating some kind of repository UUID, and adding a
> symlink -- not a great design because it pollutes outside the repo:
>
> $ mkdir myproject
> $ cd myproject
> $ git init
> $ ls -l ..
> lrwxrwxrwx 1 simon simon 9 Jun 4 14:05
> 12345678-9abc-def0-1234-56789abcdef0.git -> myproject
> drwxrwxr-x 2 simon simon 40 Jun 4 14:04 myproject
>
> On the other hand, this can be used to construct a stable relative submodule
> URL.
Here's a thought experiment. What if you put the UUID into a URL, like:
repoid://123456789.git
Then your in-repo .gitconfig would point to that repo id and be
consistent. Of course you need some way to tell Git how to retrieve
repoid:// URLs. You could do so with a custom remote helper
(git-remote-repoid), but presumably that helper is eventually going to
end up going over one of the normal Git protocols.
So we just need to tell Git how to resolve repo id URLs into concrete
URLs. And indeed, we have url.*.insteadOf to do rewriting already. So
for example, you can add a submodule but convert it into a uuid like
this:
$ git submodule add https://github.com/git/git.git
$ git config -f .gitmodules submodule.git.url
https://github.com/git/git.git
$ git config -f .gitmodules submodule.git.url repoid://123456789.git
$ git commit -am 'add submodule with magic repoid'
Now if somebody else comes along and clones it naively, the repo uuid is
not useful to git by itself:
$ git clone --recurse-submodules repo
Submodule 'git' (repoid://123456789.git) registered for path 'git'
Cloning into '/home/peff/tmp/repo/git'...
fatal: transport 'repoid' not allowed
fatal: clone of 'repoid://123456789.git' into submodule path '/home/peff/tmp/repo/git' failed
But imagine that "somehow" they have learned that 123456789.git can be
found at some URL. You can do this:
git -c url.https://github.com/git/git.git.insteadOf=repoid://123456789.git \
clone --recurse-submodules repo.git
which would clone from the original URL. Or you could even imagine that
they have a cache of repositories named by uuid, and then:
git -c url.https://my/cache/.insteadOf=repoid:// ...
would rewrite all repoid://'s automatically.
The use of "-c" here is mostly for illustration. It is a per-command
config, so when you later try to update the submodule, you'd run into
the same problem. Probably you'd want to stuff your mapping into on-disk
config (either ~/.gitconfig, or if you have a lot of them, perhaps some
file included from there).
It would be nice if you could use "git clone -c" (note "-c" as an option
to "clone", not to "git") to set a permanent per-repo config variable.
But sadly the URL rewriting happens in the submodule repository, not the
parent. So it has to be a per-user setting.
Now, all of that said, do we still need uuids at all? If the canonical
submodule name is https://github.com/git/git.git, then anybody can just
rewrite that locally in the same way using url.*.insteadOf config. And I
think this is a pretty standard way of using submodules. E.g., you might
rewrite https:// into ssh:// if you prefer that protocol. Or point to a
local server if it's faster for you.
Which makes me wonder if I am missing something about the original
request that started this thread. But it sounds to me like it is just
asking for the existing URL-rewriting feature.
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Jun 2026, #02)
From: Jeff King @ 2026-06-04 6:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Patrick Steinhardt, git
In-Reply-To: <xmqq8q8vowvt.fsf@gitster.g>
On Thu, Jun 04, 2026 at 11:35:50AM +0900, Junio C Hamano wrote:
> * ps/t7527-fix-tap-output (2026-06-02) 4 commits
> - t: let prove fail when parsing invalid TAP output
> - t/lib-git-p4: silence output when killing p4d and its watchdog
> - t/test-lib: silence EBUSY errors on Windows during test cleanup
> - t7527: fix broken TAP output
>
> A recent regression in t7527 that broke TAP output has been fixed,
> some other test noise that also broke TAP output has been silenced,
> and 'prove' is now configured to fail on invalid TAP output to
> prevent future regressions.
>
> Expecting a (small and hopefully final) reroll.
> cf. <xmqqtsrlw09t.fsf@gitster.g>
> source: <20260603-pks-t7527-fix-tap-output-v2-0-cf3af5694e20@pks.im>
I guess this is the source of several CI failures on jch/seen that look
like:
Test Summary Report
-------------------
t7810-grep.sh (Wstat: 0 Tests: 264 Failed: 0)
Parse errors: Unknown TAP token: "/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)"
This happens in the dockerized jobs whose images presumably have a very
minimal locale setup. I don't know if this is a sign that the tests have
never been doing quite what we expect on those platforms, or if it's
simply noise that is now being caught.
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Jun 2026, #02)
From: Patrick Steinhardt @ 2026-06-04 6:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqq8q8vowvt.fsf@gitster.g>
On Thu, Jun 04, 2026 at 11:35:50AM +0900, Junio C Hamano wrote:
> * ps/t7527-fix-tap-output (2026-06-02) 4 commits
> - t: let prove fail when parsing invalid TAP output
> - t/lib-git-p4: silence output when killing p4d and its watchdog
> - t/test-lib: silence EBUSY errors on Windows during test cleanup
> - t7527: fix broken TAP output
>
> A recent regression in t7527 that broke TAP output has been fixed,
> some other test noise that also broke TAP output has been silenced,
> and 'prove' is now configured to fail on invalid TAP output to
> prevent future regressions.
>
> Expecting a (small and hopefully final) reroll.
> cf. <xmqqtsrlw09t.fsf@gitster.g>
> source: <20260603-pks-t7527-fix-tap-output-v2-0-cf3af5694e20@pks.im>
I think this status here is stale -- v2 didn't have any comments yet as
far as I can see.
Patrick
^ permalink raw reply
* Re: [PATCH v2 0/8] setup: centralize object database creation
From: Patrick Steinhardt @ 2026-06-04 6:08 UTC (permalink / raw)
To: Karthik Nayak; +Cc: git, Kristoffer Haugsbakk, Junio C Hamano
In-Reply-To: <CAOLa=ZS4mSHEThYD0GKFXxqDf1Yz9U7pQkXYQJ+54V5C2FPBOg@mail.gmail.com>
On Wed, Jun 03, 2026 at 06:04:01AM -0700, Karthik Nayak wrote:
> Patrick Steinhardt <ps@pks.im> writes:
>
> > Hi,
> >
> > this small patch series refactors the logic for how we discover and
> > configure repositories. Most importantly, this involves the following
> > two steps:
> >
> > 1. We unify the logic to apply the repository format, which is
> > currently open-coded across multiple sites. These sites have
> > already diverged, where some repository extensions are not
> > consistently applied.
> >
> > 2. We then centralize creation of the object database to happen at the
> > same time we apply the repository format.
> >
> > The end result is that we apply the repository format exactly once, and
> > that's also the point in time where we can finalize the setup of the
> > repo's data structures as we know about all details of the repo at that
> > time. Ultimately, this makes it trivial to introduce the "objectStorage"
> > extension, even though that's not part of this patch series.
> >
> > The series is built on top of aec3f58750 (Sync with 'maint', 2026-05-21)
> > with ps/setup-wo-the-repository at df69f40c34 (setup: stop using
> > `the_repository` in `init_db()`, 2026-05-19) merged into it.
> >
>
> Apart from some questions/comments, the series looks good. Thanks
Thanks for your review! Will send v3 in a bit.
Patrick
^ permalink raw reply
* Re: [PATCH v2 4/8] repository: stop initializing the object database in `repo_set_gitdir()`
From: Patrick Steinhardt @ 2026-06-04 6:08 UTC (permalink / raw)
To: Karthik Nayak; +Cc: git, Kristoffer Haugsbakk, Junio C Hamano
In-Reply-To: <CAOLa=ZQ5u+J-f=xS7RDym0cwt+=R2dzMFo5P34cp-CBbza7NRg@mail.gmail.com>
On Wed, Jun 03, 2026 at 05:49:50AM -0700, Karthik Nayak wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> > diff --git a/repository.c b/repository.c
> > index 58a13f7c4f..2c2395105f 100644
> > --- a/repository.c
> > +++ b/repository.c
> > @@ -181,12 +181,6 @@ void repo_set_gitdir(struct repository *repo,
> > free(old_gitdir);
> >
> > repo_set_commondir(repo, o->commondir);
> > -
> > - if (!repo->objects)
> > - repo->objects = odb_new(repo, o->object_dir, o->alternate_db);
> > - else if (!o->skip_initializing_odb)
> > - BUG("cannot reinitialize an already-initialized object directory");
> > -
>
> This always confuses me, so we were creating the odb even if
> `o->skip_initializing_odb` was set to true, if `repo->objects` didn't
> exist. Weird.
Agreed, it was weird. It was my first iteration towards centralizing
`odb_new()`: before we had the above logic we were basically recreating
the ODB multiple times, which was even more weird. At least things are
getting somewhat sensible with this patch now.
Patrick
^ permalink raw reply
* Re: [PATCH v2 3/8] setup: deduplicate logic to apply repository format
From: Patrick Steinhardt @ 2026-06-04 6:08 UTC (permalink / raw)
To: Karthik Nayak; +Cc: git, Kristoffer Haugsbakk, Junio C Hamano
In-Reply-To: <CAOLa=ZSnDz1+C8y7ozFDdv68vqLFk-E+FsXhAnhwbm2D6a1Fng@mail.gmail.com>
On Wed, Jun 03, 2026 at 05:43:34AM -0700, Karthik Nayak wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> > diff --git a/repository.c b/repository.c
> > index db57b8308b..58a13f7c4f 100644
> > --- a/repository.c
> > +++ b/repository.c
> > @@ -262,8 +262,8 @@ void repo_set_worktree(struct repository *repo, const char *path)
> > trace2_def_repo(repo);
> > }
> >
> > -static int read_and_verify_repository_format(struct repository_format *format,
> > - const char *commondir)
> > +static int read_repository_format_from_commondir(struct repository_format *format,
> > + const char *commondir)
>
> Nit: The commit explicitly calls out one rename, but this one wasn't.
Fair. I'll add a sentence or two about this.
> > @@ -272,11 +272,6 @@ static int read_and_verify_repository_format(struct repository_format *format,
> > read_repository_format(format, sb.buf);
> > strbuf_reset(&sb);
> >
> > - if (verify_repository_format(format, &sb) < 0) {
> > - warning("%s", sb.buf);
> > - ret = -1;
> > - }
> > -
>
> So we remove this, so that the callee would independently verify the
> format I assume.
>
> Edit: seems like we call verify_repository_format() within
> apply_repository_format() and the latter is called by the callee.
>
> > strbuf_release(&sb);
> > return ret;
> > }
Yeah. I guess this could be explained a bit better.
> > @@ -290,6 +285,8 @@ int repo_init(struct repository *repo,
> > const char *worktree)
> > {
> > struct repository_format format = REPOSITORY_FORMAT_INIT;
> > + struct strbuf err = STRBUF_INIT;
> > +
> > memset(repo, 0, sizeof(*repo));
> >
> > initialize_repository(repo);
> > @@ -297,21 +294,13 @@ int repo_init(struct repository *repo,
> > if (repo_init_gitdir(repo, gitdir))
> > goto error;
> >
> > - if (read_and_verify_repository_format(&format, repo->commondir))
> > + if (read_repository_format_from_commondir(&format, repo->commondir))
> > goto error;
> >
> > - repo_set_hash_algo(repo, format.hash_algo);
> > - repo_set_compat_hash_algo(repo, format.compat_hash_algo);
> > - repo_set_ref_storage_format(repo, format.ref_storage_format,
> > - format.ref_storage_payload);
> > - repo->repository_format_worktree_config = format.worktree_config;
> > - repo->repository_format_relative_worktrees = format.relative_worktrees;
> > - repo->repository_format_precious_objects = format.precious_objects;
> > - repo->repository_format_submodule_path_cfg = format.submodule_path_cfg;
> > -
> > - /* take ownership of format.partial_clone */
>
> I see that we now do an xstrdup for format.partial_clone, meaning we
> have our own memory segment to care about. Do we have to worry about
> format.partial_clone not being free'd?
No, `clear_repository_format()` already releases the memory for us. It
also did beforehand, but there we did the dance of just moving ownership
over. So we already had to free the string before.
> > diff --git a/setup.h b/setup.h
> > index 9409326fe4..5ed92f53fa 100644
> > --- a/setup.h
> > +++ b/setup.h
> > @@ -221,6 +221,15 @@ void clear_repository_format(struct repository_format *format);
> > int verify_repository_format(const struct repository_format *format,
> > struct strbuf *err);
> >
> > +/*
> > + * Apply the given repository format to the repo. This initializes extensions
> > + * and basic data structures required for normal operation. Returns 0 on
> > + * success, a negative error code otherwise.
> > + */
>
> Nit: perhaps we should also mention that we verify the format?
Will do.
Patrick
^ permalink raw reply
* Re: [PATCH v2 2/3] Documentation/MyFirstContribution: recommend the use of b4
From: Toon Claes @ 2026-06-04 5:25 UTC (permalink / raw)
To: Patrick Steinhardt, git
Cc: Junio C Hamano, Tuomas Ahola, Weijie Yuan, Ramsay Jones
In-Reply-To: <20260603-pks-b4-v2-2-a8aea0aa2c23@pks.im>
Patrick Steinhardt <ps@pks.im> writes:
> The b4 tool originates from the Linux kernel community and is intended
> to help mailing-list based workflows. It automates a lot of the annoying
> bookkeeping tasks that contributors typically need to do: tracking the
> list of recipients, Message-IDs, range-diffs and the like. In addition
> to that, b4 also has many other subcommands that help the maintainer and
> reviewers.
>
> The Git project uses the same infrastructure as the kernel, so this tool
> is also a very good fit for us. Adapt "MyFirstContribution" to
> explicitly recommend its use.
>
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
> Documentation/MyFirstContribution.adoc | 92 ++++++++++++++++++++++++++++++++--
> Documentation/SubmittingPatches | 6 ++-
> 2 files changed, 93 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/MyFirstContribution.adoc b/Documentation/MyFirstContribution.adoc
> index 069020196c..fc0b06ae67 100644
> --- a/Documentation/MyFirstContribution.adoc
> +++ b/Documentation/MyFirstContribution.adoc
> @@ -833,7 +833,7 @@ This patchset is part of the MyFirstContribution tutorial and should not
> be merged.
> ----
>
> -At this point the tutorial diverges, in order to demonstrate two
> +At this point the tutorial diverges, in order to demonstrate three
> different methods of formatting your patchset and getting it reviewed.
>
> The first method to be covered is GitGitGadget, which is useful for those
> @@ -845,9 +845,14 @@ more fine-grained control over the emails to be sent. This method requires some
> setup which can change depending on your system and will not be covered in this
> tutorial.
>
> +The third method to be covered is `b4`, which builds on top of `git
> +format-patch` and `git send-email`. This method is the recommended way to
> +submit patches via mail as it automates a lot of the bookkeeping required by
> +`git send-email`.
The GitGitGadget method includes Running CI, maybe that's worth
mentioning the user is responsible themselves to run the whole test
suite? Or is this outside the scope of this series, since `git
send-email` doesn't include that too.
--
Cheers,
Toon
^ permalink raw reply
* [GSoC] [Blog] week 1: Improving the new git repo command
From: K Jayatheerth @ 2026-06-04 5:23 UTC (permalink / raw)
To: GIT Mailing-list, Justin Tobler, Lucas Seiki Oshiro
Hey everyone,
My Week 1 GSoC blog is live!
https://jayatheerth.com/blogs/gsoc/week-1-path-foundation
Feel free to give it a read and share any feedback ; )
Regards,
- K Jayatheerth
^ permalink raw reply
* Re: Mirror repositories for submodules
From: Simon Richter @ 2026-06-04 5:11 UTC (permalink / raw)
To: Junio C Hamano, Benson Muite; +Cc: git
In-Reply-To: <xmqqcxy7qfgk.fsf@gitster.g>
Hi,
On 6/4/26 10:09 AM, Junio C Hamano wrote:
> So, no, I do not think a contribution to add mirror repositories as
> alternate submodule sources should be considered for inclusion, as
> it artificially limits usefulness of the feature. A feature to add
> mirror repositories as alternate sources might be worth considering,
> though.
This is relevant to the Debian use case: we run a git server that
archives git trees for Debian packages, and ideally the objects on this
server should be identical to what you get from upstream projects.
This is a big problem for archiving projects that use submodules,
because we cannot alter the reference URLs.
Cloning from our server will, depending on what upstream uses, either a
relative URL (which will go to our server, but we have little control
over what the name part of the repository base URL is going to be), or
an absolute URL that instructs clients to pull from another place, which
conflicts with our goal to have a self-contained archive.
The idea posited earlier, to have a "repository identity" that remains
the same across forks and clones, is somewhat appealing, but the best
idea I can come up with is generating some kind of repository UUID, and
adding a symlink -- not a great design because it pollutes outside the repo:
$ mkdir myproject
$ cd myproject
$ git init
$ ls -l ..
lrwxrwxrwx 1 simon simon 9 Jun 4 14:05
12345678-9abc-def0-1234-56789abcdef0.git -> myproject
drwxrwxr-x 2 simon simon 40 Jun 4 14:04 myproject
On the other hand, this can be used to construct a stable relative
submodule URL.
Making the symlinks optional would require keeping a list of local
clones and their UUIDs, and resolving them.
I don't like that design, but as I said it's the best idea I have for now.
I also fully expect that Debian's servers will be used by a lot of
people outside the project as soon as it becomes a convenient fallback,
in the same way people are pulling .orig.tar.gz archives from Debian
mirrors, so we need to make it easy to set up a mirror, to allow this to
scale.
Simon
^ permalink raw reply
* What's cooking in git.git (Jun 2026, #02)
From: Junio C Hamano @ 2026-06-04 2:35 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).
I'll be away from my tree and the list, so expect not much change
in this report until next week.
Copies of the source code to Git live in many repositories, and the
following is a list of the ones I push into or their mirrors. Some
repositories have only a subset of branches.
With maint, master, next, seen, todo:
git://git.kernel.org/pub/scm/git/git.git/
git://repo.or.cz/alt-git.git/
https://kernel.googlesource.com/pub/scm/git/git/
https://github.com/git/git/
https://gitlab.com/git-scm/git/
With all the integration branches and topics broken out:
https://github.com/gitster/git/
Even though the preformatted documentation in HTML and man format
are not sources, they are published in these repositories for
convenience (replace "htmldocs" with "manpages" for the manual
pages):
git://git.kernel.org/pub/scm/git/git-htmldocs.git/
https://github.com/gitster/git-htmldocs.git/
Release tarballs are available at:
https://www.kernel.org/pub/software/scm/git/
--------------------------------------------------
[New Topics]
* ap/http-redirect-wwwauth-fix (2026-06-02) 1 commit
- http: preserve wwwauth_headers across redirects
When cURL follows a redirect, the WWW-Authenticate headers from the
redirect target were lost because credential_from_url() cleared the
credential state. This has been fixed by preserving the collected
headers across the redirect update.
Expecting a reroll.
cf. <5144a29d-a53f-4446-beff-e1f549345bf9@nvidia.com>
source: <20260602161150.1527493-1-aplattner@nvidia.com>
* ps/doc-recommend-b4 (2026-06-02) 3 commits
- b4: introduce configuration for the Git project
- Documentation/MyFirstContribution: recommend the use of b4
- Documentation/MyFirstContribution: recommend shallow threading
Project-specific configuration for b4 has been introduced, and the
documentation has been updated to recommend using it as a
streamlined method for submitting patches.
Waiting for response(s) to review comment(s).
cf. <aiACDLOtd_0_CCD7@wyuan.org>
source: <20260603-pks-b4-v2-0-a8aea0aa2c23@pks.im>
--------------------------------------------------
[Stalled]
* 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.
Waiting for response(s) to review comment(s) for too long, consider discarding.
cf. <xmqqldf7y95a.fsf@gitster.g>
source: <pull.2258.v2.git.git.1774971267.gitgitgadget@gmail.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.
Waiting for response(s) to review comment(s) for too long, consider discarding.
cf. <xmqqv7c13o5l.fsf@gitster.g>
source: <20260305-cs-subtree-split-recursion-v2-0-7266be870ba9@howdoi.land>
--------------------------------------------------
[Cooking]
* kh/free-commit-list (2026-05-28) 2 commits
(merged to 'next' on 2026-05-31 at 154f83b192)
+ commit: remove deprecated functions
+ *: replace deprecated free_commit_list
Code clean-up.
Will merge to 'master'.
source: <V2_CV_commit.h_remove_deprecated.732@msgid.xyz>
* kk/streaming-walk-pqueue (2026-05-27) 3 commits
- revision: use priority queue for non-limited streaming walks
- revision: introduce rev_walk_mode to clarify get_revision_1()
- pack-objects: call release_revisions() after cruft traversal
Streaming revision walks have been optimized by using a priority queue
for date-sorting commits, speeding up walks repositories with many
merges.
Will merge to 'next'?
source: <pull.2127.git.1779897003.gitgitgadget@gmail.com>
* kk/wildmatch-windows-ls-files-prereq (2026-05-28) 1 commit
(merged to 'next' on 2026-06-04 at 6dc748aa63)
+ t3070: skip ls-files tests with backslash patterns on Windows
In t3070-wildmatch, "via ls-files" test variants with patterns
containing backslash escapes are now skipped on Windows, avoiding 36
test failures caused by pathspec separator conversion.
Will merge to 'master'.
cf. <xmqqecivjn7k.fsf@gitster.g>
source: <pull.2128.git.1779958849319.gitgitgadget@gmail.com>
* sn/rebase-update-refs-symrefs (2026-06-03) 1 commit
- rebase: skip branch symref aliases
"git rebase --update-refs" has been taught to resolve local branch
symrefs to their referents before queuing updates. This correctly
skips aliases of the current branch and avoids duplicate updates for
underlying real branches, fixing failures when branch aliases (like a
default branch rename) are present.
Comments?
source: <pull.2126.v2.git.1780482436865.gitgitgadget@gmail.com>
* lp/http-fetch-pack-index-leak-fix (2026-06-01) 2 commits
(merged to 'next' on 2026-06-04 at f4090b5068)
+ http: fix memory leak in fetch_and_setup_pack_index()
+ http: cleanup function fetch_and_setup_pack_index()
A memory leak in `fetch_and_setup_pack_index()` when verification of
the downloaded pack index fails has been plugged. Also an obsolete
`unlink()` call on parse failure has been cleaned up.
Will merge to 'master'.
cf. <20260529053659.GC1099450@coredump.intra.peff.net>
source: <cover.1780321770.git.lorenzo.pegorari2002@gmail.com>
* jk/describe-contains-all-match-fix (2026-06-01) 1 commit
- describe: fix --exclude, --match with --contains and --all
The 'git describe --contains --all' command has been fixed to
properly honor the '--match' and '--exclude' options by passing
them down to 'git name-rev' with the appropriate reference
prefixes.
Will merge to 'next'?
source: <20260601233727.43558-1-jacob.e.keller@intel.com>
* wy/docs-typofixes (2026-05-29) 1 commit
- docs: fix typos and grammar
Various typos, grammatical errors, and duplicated words in both
documentation and code comments have been corrected.
Waiting for response(s) to review comment(s).
cf. <xmqq8q8x3nox.fsf@gitster.g>
source: <7b502e20e9495cd4720496bd6738a1fbeb453410.1780041658.git.wy@wyuan.org>
* ab/index-pack-retain-child-bases (2026-06-02) 1 commit
- index-pack: retain child bases in delta cache
"git index-pack" has been optimized by retaining child bases in the
delta cache instead of immediately freeing them, letting the existing
cache limit policy decide eviction.
Waiting for response(s) to review comment(s).
cf. <c4a32a6f-70bf-4ff4-abbf-d6e301246b5b@gmail.com>
source: <pull.2131.v3.git.1780445118653.gitgitgadget@gmail.com>
* hn/macos-linker-warning (2026-06-02) 1 commit
(merged to 'next' on 2026-06-04 at db2ca164c4)
+ config.mak.uname: avoid macOS linker warning on Xcode 16.3+
A linker warning on macOS when building with Xcode 16.3 or newer has
been avoided by passing -fno-common to the compiler when a
sufficiently new linker is detected.
Will merge to 'master'.
source: <pull.2313.v3.git.git.1780385878555.gitgitgadget@gmail.com>
* mm/diff-process-hunks (2026-05-29) 6 commits
- blame: consult diff process for no-hunk detection
- diff: bypass diff process with --no-ext-diff and in format-patch
- diff: add long-running diff process via diff.<driver>.process
- sub-process: separate process lifecycle from hashmap management
- userdiff: add diff.<driver>.process config
- xdiff: support external hunks via xpparam_t
A new `diff.<driver>.process` configuration has been introduced to
allow a long-running external process to act as a hunk provider to
allows external tools to control which lines Git considers changed
while leaving all output formatting (word diff, color, blame, etc.) to
Git's standard pipeline.
Breaks CI.
cf. <xmqq5x43dfk4.fsf@gitster.g>
source: <pull.2120.v3.git.1780087700.gitgitgadget@gmail.com>
* tb/pack-path-walk-bitmap-delta-islands (2026-06-02) 5 commits
- pack-objects: support `--delta-islands` with `--path-walk`
- pack-objects: extract `record_tree_depth()` helper
- pack-objects: support reachability bitmaps with `--path-walk`
- t/perf: drop p5311's lookup-table permutation
- Merge branch 'ds/path-walk-filters' into tb/pack-path-walk-bitmap-delta-islands
The pack-objects command now supports using reachability bitmaps and
delta-islands concurrently with the `--path-walk` option, allowing
faster packaging by falling back to path-walk when bitmaps cannot
fully satisfy the request.
Comments?
source: <cover.1780438896.git.me@ttaylorr.com>
* ty/migrate-trust-executable-bit (2026-05-30) 4 commits
- read-cache: pass 'istate' to stat/mode helper functions
- environment: move 'trust_executable_bit' into repo_config_values
- read-cache: move 'ce_mode_from_stat()' to 'read-cache.c'
- read-cache: remove redundant extern declarations
The 'trust_executable_bit' (coming from 'core.filemode'
configuration) has been migrated into 'repo_config_values' to tie it
to a specific repository instance.
Waiting for response(s) to review comment(s).
cf. <CAP8UFD1GJ=caPh-M97KLCfB1ZKtpomzosYN0uYBOnay+G23GcA@mail.gmail.com>
cf. <CAP8UFD20yij=1ZEYnR74DoCJ3g=b39yOsUxZecYuuf7nFGaKyA@mail.gmail.com>
source: <20260530160520.77859-1-cat@malon.dev>
* ak/typofixes (2026-05-31) 1 commit
- doc: fix typos via codespell
Typofixes.
Will merge to 'next'.
source: <20260531184428.55905-1-algonell@gmail.com>
* kk/prio-queue-cascade-sift (2026-06-01) 1 commit
- prio-queue: use cascade-down for faster extract-min
prio_queue_get() has been optimized by using a cascade-down approach
(promoting the smaller child at each level and sifting up the last
element from the leaf vacancy), which halves the number of comparisons
per extract-min operation in the common case.
Expecting a reroll.
cf. <CAL71e4Ob-B5MJ5DPY+_tzpj6nyrbQ5WutxED2T93SWJV6kJGPA@mail.gmail.com>
source: <pull.2132.v2.git.1780301856444.gitgitgadget@gmail.com>
* mm/subprocess-handshake-fix (2026-06-01) 1 commit
- sub-process: use gentle handshake to avoid die() on startup failure
The subprocess handshake during startup has been made gentler by using
packet_read_line_gently() instead of packet_read_line() to prevent the
parent Git process from dying abruptly when a configured subprocess
(e.g., a clean/smudge filter) fails to start.
Will merge to 'next'?
source: <pull.2133.v2.git.1780348848489.gitgitgadget@gmail.com>
* jk/repo-info-path-keys (2026-06-01) 4 commits
- repo: add path.commondir with absolute and relative suffix formatting
- repo: add path.gitdir with absolute and relative suffix formatting
- rev-parse: use strbuf_add_path for path formatting
- path: add strbuf_add_path for formatting paths
The "git repo info" command has been taught new keys to output both
absolute and relative paths for "gitdir" and "commondir", supported by
a new path-formatting helper extracted from "git rev-parse".
Waiting for response(s) to review comment(s).
cf. <8ebc3d98-40a5-4e99-a205-34254cf5172b@gmail.com>
source: <20260601151950.30686-1-jayatheerthkulkarni2005@gmail.com>
* ps/history-drop (2026-06-03) 9 commits
- builtin/history: implement "drop" subcommand
- builtin/history: split handling of ref updates into two phases
- reset: stop assuming that the caller passes in a clean index
- reset: allow the caller to specify the current HEAD object
- reset: introduce ability to skip reference updates
- reset: introduce dry-run mode
- reset: modernize flags passed to `reset_head()`
- reset: drop `USE_THE_REPOSITORY_VARIABLE`
- read-cache: split out function to drop unmerged entries to stage 0
The experimental "git history" command has been taught a new "drop"
subcommand to remove a commit and replay its descendants onto its
parent.
Comments?
source: <20260603-b4-pks-history-drop-v2-0-742cb5b5176d@pks.im>
* ls/doc-raw-timestamp-prefix (2026-06-02) 1 commit
- doc: document and test `@` prefix for raw timestamps
Documentation and tests have been added to clarify that Git's internal
raw timestamp format requires a `@` prefix for values less than
100,000,000 to prevent ambiguity with other formats like YYYYMMDD.
Will merge to 'next'?
cf. <xmqqmrxdxq1r.fsf@gitster.g>
source: <20260602081924.673763-2-dev@luna.gl>
* jk/setup-gitfile-diag-fix (2026-06-01) 1 commit
- read_gitfile_gently(): return non-repo path on error
A regression in the error diagnosis code for invalid .git files has
been fixed, avoiding a potential NULL-pointer crash when reporting
that a .git file does not point to a valid repository.
Expecting a reroll?
cf. <ah6WEtk2pXyViEQA@pks.im>
source: <20260602061159.GA693928@coredump.intra.peff.net>
* jc/submitting-patches-cover-letter (2026-06-02) 2 commits
- SubmittingPatches: describe cover letter
- SubmittingPatches: separate typofixes section
Guidelines on how to write a cover letter for a multi-patch series
have been added to SubmittingPatches, which also got a new marker
to separate the section for typofixes.
Will merge to 'next'?
cf. <c54f3571-ff7b-4caa-b75d-a739ed87ec9d@gmail.com>
source: <20260602144304.3341000-1-gitster@pobox.com>
* ps/t7527-fix-tap-output (2026-06-02) 4 commits
- t: let prove fail when parsing invalid TAP output
- t/lib-git-p4: silence output when killing p4d and its watchdog
- t/test-lib: silence EBUSY errors on Windows during test cleanup
- t7527: fix broken TAP output
A recent regression in t7527 that broke TAP output has been fixed,
some other test noise that also broke TAP output has been silenced,
and 'prove' is now configured to fail on invalid TAP output to
prevent future regressions.
Expecting a (small and hopefully final) reroll.
cf. <xmqqtsrlw09t.fsf@gitster.g>
source: <20260603-pks-t7527-fix-tap-output-v2-0-cf3af5694e20@pks.im>
* ob/more-repo-config-values (2026-06-02) 8 commits
- environment: move "warn_on_object_refname_ambiguity" into `struct repo_config_values`
- environment: move "sparse_expect_files_outside_of_patterns" into `struct repo_config_values`
- environment: 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`
Many core configuration variables have been migrated from global
variables into 'repo_config_values' to tie them to a specific
repository instance, avoiding cross-repository state leakage.
Will merge to 'next'?
source: <20260602170921.35869-1-belkid98@gmail.com>
* 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.
Expecting a reroll.
cf. <5508ee49-2f78-4c3a-accf-a2350666bfb8@app.fastmail.com>
source: <V2_CV_doc_int-tr_key_format.613@msgid.xyz>
* za/completion-hide-dotfiles (2026-05-26) 1 commit
- completion: hide dotfiles for selected path completion
The path completion for commands like `git rm` and `git mv`, is being
updated to hide dotfiles by default, unless the user explicitly starts
the path with a dot, matching standard shell-completion behavior.
Comments?
cf. <xmqqqzmxlep3.fsf@gitster.g>
source: <pull.2311.v2.git.git.1779808987825.gitgitgadget@gmail.com>
* ds/restore-sparse-index (2026-05-26) 2 commits
(merged to 'next' on 2026-05-31 at e85a961bc7)
+ restore: avoid sparse index expansion
+ t1092: test 'git restore' with sparse index
'git restore --staged' has been optimized to avoid unnecessarily expanding
the sparse index when operating on paths within the sparse checkout
definition, by handling sparse directory entries at the tree level.
Will merge to 'master'.
source: <pull.2121.v2.git.1779827195.gitgitgadget@gmail.com>
* kk/commit-reach-optim (2026-05-25) 3 commits
(merged to 'next' on 2026-05-31 at eeb8d0c207)
+ commit-reach: replace queue_has_nonstale() scan with O(1) tracking
+ commit-reach: deduplicate queue entries in paint_down_to_common
+ object.h: fix stale entries in object flag allocation table
The check for non-stale commits in the priority queue used by
`paint_down_to_common` and `ahead_behind` has been optimized by
replacing an O(N) scan with an O(1) counter, yielding performance
improvements in repositories with wide histories.
Will merge to 'master'.
cf. <xmqqzf1ncded.fsf@gitster.g>
source: <pull.2124.v2.git.1779719286.gitgitgadget@gmail.com>
* ar/receive-pack-worktree-env (2026-05-25) 1 commit
(merged to 'next' on 2026-05-27 at 9c246d1969)
+ receive-pack: fix updateInstead with core.worktree
The GIT_WORK_TREE variable prepared to invoke the push-to-checkout
hook was leaking into the environment even when there was no hook
used and broke the default push-to-deploy (i.e., let "git checkout"
update the working tree only when the working tree is clean).
Will merge to 'master'.
source: <20260525162311.66240-2-hi@alyssa.is>
* ib/doc-push-default-simple (2026-05-25) 1 commit
(merged to 'next' on 2026-06-02 at 5c1ff2a769)
+ doc: clarify push.default=simple behavior
The documentation for `push.default = simple` has been clarified to
better explain its behavior, making it clear that it pushes the
current branch to a same-named branch on the remote, and detailing
the upstream requirements for centralized workflows.
Will merge to 'master'.
cf. <pull.2115.v2.git.1779767888508.gitgitgadget@gmail.com>
source: <pull.2115.v2.git.1779767888508.gitgitgadget@gmail.com>
* jc/doc-monitor-ghci (2026-05-24) 1 commit
(merged to 'next' on 2026-06-02 at 46fb5fe1c2)
+ SubmittingPatches: proactively monitor GHCI pages
Encourage original authors to monitor the CI status.
Will merge to 'master'.
source: <xmqq1pf0gpp3.fsf@gitster.g>
* ec/commit-fixup-options (2026-05-26) 2 commits
- commit: allow -c/-C for all kinds of --fixup
- commit: allow -m/-F for all kinds of --fixup
The -m/-F/-c/-C options to supply commit log message from outside the
editor are now supported for all "git commit --fixup" variations.
Comments?
source: <cover.1779792311.git.erik@cervined.in>
* gh/jump-auto-mode (2026-05-21) 1 commit
(merged to 'next' on 2026-06-02 at f70dd05c9c)
+ git-jump: pick a mode automatically when invoked without arguments
The 'git-jump' command (in contrib/) has been taught to automatically
pick a mode (merge, diff, or ws) when invoked without arguments.
Will merge to 'master'.
cf. <20260522052821.GC861761@coredump.intra.peff.net>
source: <pull.2108.v3.git.1779371110195.gitgitgadget@gmail.com>
* ps/odb-source-loose (2026-06-01) 19 commits
(merged to 'next' on 2026-06-04 at 660909ad66)
+ odb/source-loose: drop pointer to the "files" source
+ odb/source-loose: stub out remaining callbacks
+ odb/source-loose: wire up `write_object_stream()` callback
+ object-file: refactor writing objects to use loose source
+ odb/source-loose: wire up `write_object()` callback
+ loose: refactor object map to operate on `struct odb_source_loose`
+ odb/source-loose: wire up `freshen_object()` callback
+ odb/source-loose: drop `odb_source_loose_has_object()`
+ odb/source-loose: wire up `count_objects()` callback
+ odb/source-loose: wire up `find_abbrev_len()` callback
+ odb/source-loose: wire up `for_each_object()` callback
+ odb/source-loose: wire up `read_object_stream()` callback
+ odb/source-loose: wire up `read_object_info()` callback
+ odb/source-loose: wire up `close()` callback
+ odb/source-loose: wire up `reprepare()` callback
+ odb/source-loose: start converting to a proper `struct odb_source`
+ odb/source-loose: store pointer to "files" instead of generic source
+ odb/source-loose: move loose source into "odb/" subsystem
+ Merge branch 'ps/odb-in-memory' into ps/odb-source-loose
The loose object source has been refactored into a proper `struct
odb_source`.
Will merge to 'master'.
source: <20260601-b4-pks-odb-source-loose-v2-0-90ff159430af@pks.im>
* ps/setup-centralize-odb-creation (2026-05-25) 9 commits
- setup: construct object database in `apply_repository_format()`
- repository: stop reading loose object map twice on repo init
- setup: stop initializing object database without repository
- setup: stop creating the object database in `setup_git_env()`
- repository: stop initializing the object database in `repo_set_gitdir()`
- setup: deduplicate logic to apply repository format
- setup: drop `setup_git_env()`
- t0001: plug test gaps for git-init(1) with GIT_OBJECT_DIRECTORY
- Merge branch 'ps/setup-wo-the-repository' into ps/setup-centralize-odb-creation
The setup logic to discover and configure repositories has been
refactored, and the initialization of the object database has been
centralized.
Comments?
source: <20260526-b4-pks-setup-centralize-odb-creation-v2-0-2fa5b385c13e@pks.im>
* kh/doc-replay-config (2026-06-03) 4 commits
- doc: replay: move “default” to the right-hand side
- doc: replay: use a nested description list
- doc: replay: improve config description
- doc: link to config for git-replay(1)
Doc update for "git replay" to actually refer to its configuration
variables.
Comments?
source: <V2_CV_doc_replay_config.767@msgid.xyz>
* aj/stash-patch-optimize-temporary-index (2026-05-22) 1 commit
(merged to 'next' on 2026-05-31 at d1b1dd94f5)
+ stash: reuse cached index entries in --patch temporary index
"git stash -p" has been optimized by reusing cached index
entries in its temporary index, avoiding unnecessary lstat()
calls on unchanged files.
Will merge to 'master'.
cf. <xmqqse7m6deh.fsf@gitster.g>
source: <pull.2306.v2.git.git.1779491545531.gitgitgadget@gmail.com>
* tb/bitmap-build-performance (2026-05-27) 9 commits
(merged to 'next' on 2026-06-02 at d1a84a996a)
+ pack-bitmap: build pseudo-merge bitmaps after regular bitmaps
+ pack-bitmap: remember pseudo-merge parents
+ pack-bitmap: sort bitmaps before XORing
+ pack-bitmap: cache object positions during fill
+ pack-bitmap: consolidate `find_object_pos()` success path
+ pack-bitmap: reuse stored selected bitmaps
+ pack-bitmap: check subtree bits before recursing
+ pack-bitmap: pass object position to `fill_bitmap_tree()`
+ Merge branch 'tb/pseudo-merge-bugfixes' into tb/bitmap-build-performance
Reachability bitmap generation has been significantly optimized. By
reordering tree traversal, caching object positions, and refining how
pseudo-merge bitmaps are constructed, the performance of "git repack
--write-midx-bitmaps" is improved, especially for large repositories
and when using pseudo-merges.
Will merge to 'master'.
cf. <20260529083439.GD1106035@coredump.intra.peff.net>
source: <cover.1779911733.git.me@ttaylorr.com>
* hn/status-pull-advice-qualified (2026-05-21) 1 commit
- remote: qualify "git pull" advice for non-upstream compareBranches
Advice shown by "git status" when the local branch is behind or has
diverged from its push branch has been updated to suggest "git pull
<remote> <branch>".
Comments?
source: <pull.2301.v4.git.git.1779372367317.gitgitgadget@gmail.com>
* rs/strbuf-add-uint (2026-05-12) 4 commits
(merged to 'next' on 2026-06-02 at f5be02d8ec)
+ ls-tree: use strbuf_add_uint()
+ ls-files: use strbuf_add_uint()
+ cat-file: use strbuf_add_uint()
+ strbuf: add strbuf_add_uint()
Adding a decimal integer with strbuf_addf("%u") appears commonly;
they have been optimized by using a custom formatter.
Will merge to 'master'.
cf. <20260512184619.GD70851@coredump.intra.peff.net>
source: <20260512115603.80780-1-l.s.r@web.de>
* mm/doc-word-diff (2026-05-28) 1 commit
(merged to 'next' on 2026-06-04 at 9fa723ec63)
+ doc: clarify that --word-diff operates on line-level hunks
The documentation for "--word-diff" has been extended with a bit of
implementation detail of where these different words come from.
Will merge to 'master'.
source: <pull.2113.v2.git.1779996106005.gitgitgadget@gmail.com>
* rs/strbuf-add-oid-hex (2026-05-13) 1 commit
(merged to 'next' on 2026-06-02 at 4876f95de0)
+ hex: add and use strbuf_add_oid_hex()
Formatting object name in full hexadecimal form has been optimized
by using a new strbuf_add_oid_hex() helper function.
Will merge to 'master'.
cf. <20260513160155.GA103037@coredump.intra.peff.net>
source: <183aa0fd-d455-4ec9-9c42-d511fac8b3e4@web.de>
* hn/config-typo-advice (2026-06-02) 2 commits
- config: improve diagnostic for "set" with missing value
- config: add git_config_key_is_valid() for quiet validation
"git config foo.bar=baz" is not likely to be a request to read the
value of such a variable with '=' in its name; rather it is plausible
that the user meant "git config set foo.bar baz". Give advice when
giving an error message.
Will merge to 'next'?
source: <pull.2302.v6.git.git.1780425808.gitgitgadget@gmail.com>
* ja/doc-synopsis-style-again (2026-05-25) 6 commits
(merged to 'next' on 2026-05-31 at cc4fe82d87)
+ doc: convert git-imap-send synopsis and options to new style
+ doc: convert git-apply synopsis and options to new style
+ doc: convert git-am synopsis and options to new style
+ doc: convert git-grep synopsis and options to new style
+ doc: git bisect: clarify the usage of the synopsis vs actual command
+ doc: convert git-bisect to synopsis style
A batch of documentation pages has been updated to use the modern
synopsis style.
Will merge to 'master'.
cf. <pull.2117.v2.git.1779704908.gitgitgadget@gmail.com>
source: <pull.2117.v2.git.1779704908.gitgitgadget@gmail.com>
* jt/config-lock-timeout (2026-05-17) 1 commit
- config: retry acquiring config.lock, configurable via core.configLockTimeout
Configuration file locking now retries for a short period, avoiding
failures when multiple processes attempt to update the configuration
simultaneously.
Waiting for response(s) to review comment(s).
cf. <agrIrGwSMFlKTx9x@pks.im>
source: <20260517132111.1014901-1-joerg@thalheim.io>
* hn/branch-prune-merged (2026-06-03) 6 commits
- branch: add --dry-run for --prune-merged
- branch: add branch.<name>.pruneMerged opt-out
- branch: add --prune-merged <branch>
- branch: prepare delete_branches for a bulk caller
- branch: let delete_branches warn instead of error on bulk refusal
- branch: add --forked filter for --list mode
"git branch" command learned "--prune-merged" option to remove
local branches that have already been merged to the remote-tracking
branches they track.
Comments?
source: <pull.2285.v12.git.git.1780477479.gitgitgadget@gmail.com>
* st/daemon-sockaddr-fixes (2026-05-27) 3 commits
(merged to 'next' on 2026-06-04 at 17684e6158)
+ daemon: guard NULL REMOTE_PORT in execute() logging
+ daemon: fix IPv6 address truncation in ip2str()
+ daemon: fix IPv6 address corruption in lookup_hostname()
Correct use of sockaddr API in "git daemon".
Will merge to 'master'.
source: <pull.2300.v3.git.git.1779937016.gitgitgadget@gmail.com>
* cc/promisor-auto-config-url-more (2026-05-27) 8 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'
The handling of promisor-remote protocol capability has been
loosened to allow the other side to add to the list of promisor
remotes via the promisor.acceptFromServerURL configuration
variable.
Comments?
source: <20260527140820.1438165-1-christian.couder@gmail.com>
* hn/checkout-track-fetch (2026-05-23) 2 commits
- checkout: extend --track with a "fetch" mode to refresh start-point
- branch: expose helpers for finding the remote owning a tracking ref
"git checkout --track=..." learned to optionally fetch the branch
from the remote the new branch will work with.
Comments?
source: <pull.2281.v13.git.git.1779565714.gitgitgadget@gmail.com>
* mf/revision-max-count-oldest (2026-05-18) 1 commit
- revision.c: implement --max-count-oldest
"git rev-list" (and "git log" family of commands) learned a new "--max-count-oldest"
that picks oldest N commits in the range instead of the usual newest.
Will merge to 'next'.
source: <8210d60832b9a58aa4d71fc3790e44d8989564ce.1779152064.git.mroik@delayed.space>
* mm/line-log-cleanup (2026-05-28) 3 commits
(merged to 'next' on 2026-06-04 at 02f8bea278)
+ 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
The `git log -L` implementation has been refactored to use the
standard diff output pipeline, enabling pickaxe and diff-filter to
work as expected. Additionally, metadata-only diff formats like
--raw and --name-only are now supported with -L.
Will merge to 'master'.
cf. <B59BA5B1-184D-48A8-8BAD-11EB6F8EB50C@gmail.com>
source: <pull.2094.v3.git.1780001267.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.
Waiting for response(s) to review comment(s).
cf. <xmqqldcy4f07.fsf@gitster.g>
source: <pull.2096.git.1776731171.gitgitgadget@gmail.com>
* pw/status-rebase-todo (2026-05-01) 2 commits
- status: improve rebase todo list parsing
- sequencer: factor out parsing of todo commands
The display of the rebase todo list in "git status" has been
improved to correctly abbreviate object IDs for more commands and
avoid misinterpreting refs as object IDs.
Waiting for response(s) to review comment(s).
cf. <xmqqbjdwcsno.fsf@gitster.g>
source: <cover.1777648598.git.phillip.wood@dunelm.org.uk>
* cl/conditional-config-on-worktree-path (2026-05-24) 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.
Waiting for response(s) to review comment(s).
cf. <xmqq8q97et9b.fsf@gitster.g>
source: <20260525-includeif-worktree-v5-0-1efe525d025a@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.
Expecting a reroll.
cf. <CAN5EUNQoKRqt3FGLmzRGpPU1nO5jCAogP8Wm9gBZXuPbMNbQAw@mail.gmail.com>
source: <20260427102838.44867-2-pabloosabaterr@gmail.com>
* th/promisor-quiet-per-repo (2026-04-06) 1 commit
(merged to 'next' on 2026-06-02 at 02a749d7fe)
+ 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.
Will merge to 'master'.
cf. <c87f1f12-d0cc-4150-8f43-4dc9cc1fe24f@malon.dev>
source: <20260406183041.783800-1-vikingtc4@gmail.com>
* ua/push-remote-group (2026-05-03) 3 commits
(merged to 'next' on 2026-06-02 at ba5d6aebaa)
+ 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.
Will merge to 'master'.
cf. <20260518182721.155070-1-usmanakinyemi202@gmail.com>
source: <20260503153402.1333220-1-usmanakinyemi202@gmail.com>
* js/parseopt-subcommand-autocorrection (2026-04-27) 11 commits
- SQUASH???
- doc: document autocorrect API
- parseopt: add tests for subcommand autocorrection
- parseopt: enable subcommand autocorrection for git-remote and git-notes
- parseopt: autocorrect mistyped subcommands
- autocorrect: provide config resolution API
- autocorrect: rename AUTOCORRECT_SHOW to AUTOCORRECT_HINT
- autocorrect: use mode and delay instead of magic numbers
- help: move tty check for autocorrection to autocorrect.c
- help: make autocorrect handling reusable
- parseopt: extract subcommand handling from parse_options_step()
The parse-options library learned to auto-correct misspelled
subcommand names.
Expecting a reroll.
cf. <SY0P300MB0801E50FCB7EB2F45CD15208CE042@SY0P300MB0801.AUSP300.PROD.OUTLOOK.COM>
source: <SY0P300MB0801677A2A1E0FD38D06A841CE2A2@SY0P300MB0801.AUSP300.PROD.OUTLOOK.COM>
* jc/neuter-sideband-post-3.0 (2026-03-05) 2 commits
- sideband: delay sanitizing by default to Git v3.0
- Merge branch 'jc/neuter-sideband-fixup' into jc/neuter-sideband-post-3.0
The final step, split from earlier attempt by Dscho, to loosen the
sideband restriction for now and tighten later at Git v3.0 boundary.
On hold to help the base topic with wider exposure.
(this branch uses jc/neuter-sideband-fixup.)
source: <20260305233452.3727126-8-gitster@pobox.com>
--------------------------------------------------
[Discarded]
* kk/fetch-store-ref-optimization (2026-05-24) 1 commit
- fetch: pass transport to post-fetch connectivity check
When fetching from a transport that provides a self-contained pack,
pass the transport pointer to the post-fetch `check_connected()` call
to optimize connectivity check.
Retracted.
cf. <CAL71e4MrVqC1=AR6x0_8S=8kVqPdDkhgCZRb4etFsxTzd6s_8Q@mail.gmail.com>
source: <pull.2123.git.1779625693328.gitgitgadget@gmail.com>
* lp/repack-propagate-promisor-debugging-info (2026-04-18) 6 commits
- repack-promisor: add missing headers
- t7703: test for promisor file content after geometric repack
- t7700: test for promisor file content after repack
- repack-promisor: preserve content of promisor files after repack
- repack-promisor add helper to fill promisor file after repack
- pack-write: add explanation to promisor file content
When fetching objects into a lazily cloned repository, .promisor
files are created with information meant to help debugging. "git
repack" has been taught to carry this information forward to
packfiles that are newly created.
Retracted.
cf. <agx_GPfBKpkSc3Gx@lorenzo-VM>
source: <cover.1776384902.git.lorenzo.pegorari2002@gmail.com>
^ permalink raw reply
* Re: [PATCH 1/2] b4: introduce configuration for the Git project
From: Junio C Hamano @ 2026-06-04 1:11 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Patrick Steinhardt, Weijie Yuan, Tuomas Ahola, git
In-Reply-To: <aiAK9eLvew+mgWt+@szeder.dev>
SZEDER Gábor <szeder.dev@gmail.com> writes:
> No, in Git shallow threading means that all patches are sent as a
> respose to the current cover letter, period. It has nothing to do
> with whether the current cover letter is sent as a reply to the cover
> letter of the first or the previous version.
> ...
> Deep threading means that every mail is a reply to the previous one.
> Again, it has nothing to do with the relation of the current cover
> letter and the previous cover letters.
>
> Therefore, we do not recommend deep threading.
The above exactly matches my understanding of the current best
practice. Inside an iteration of a series, we want a cover letter
with everybody else responding to it. We do not have a word to
describe how the latest iteration refers to its previous iteration
via In-reply-to: or References: headers, but our preference is to
make the cover letter of iteration N+1 to be a response to the cover
letter of iteration N.
For a single-patch topic (without a cover letter) with multiple
iterations, each iteration would be response to its previous
iteration, which may make it look like "deep threading", but as you
pointed out, the "deep threading" concept does not go across
iterations.
Having said that, I've seen a cover letter of iteration N (for any
value of N > 1) that respondes to the cover letter of the initial
iteration. While it seems not to break "br" and the lore archive
does not seem unhappy about it, I am not sure if tooling used by
other people are also happy with it.
Thanks.
^ permalink raw reply
* Re: [PATCH] transport-helper: fix TSAN race in transfer_debug()
From: Junio C Hamano @ 2026-06-04 1:09 UTC (permalink / raw)
To: Pushkar Singh; +Cc: git, peff
In-Reply-To: <20260602201309.38434-2-pushkarkumarsingh1970@gmail.com>
Pushkar Singh <pushkarkumarsingh1970@gmail.com> writes:
> +static int transfer_debug_enabled = -1;
> ...
> - if (debug_enabled < 0)
> - debug_enabled = getenv("GIT_TRANSLOOP_DEBUG") ? 1 : 0;
> - if (!debug_enabled)
> + if (!transfer_debug_enabled)
> return;
Would it be possible that transfer_debug_enabled is still -1 at this
point? We would proceed in such a case, which is a bit different from
what would have happened in the original.
Perhaps
if (transfer_debug_enabled <= 0)
return;
is what you want? I dunno.
> @@ -1648,6 +1640,9 @@ int bidirectional_transfer_loop(int input, int output)
> {
> struct bidirectional_transfer_state state;
>
> + if (transfer_debug_enabled < 0)
> + transfer_debug_enabled = getenv("GIT_TRANSLOOP_DEBUG") ? 1 : 0;
> +
> /* Fill the state fields. */
> state.ptg.src = input;
> state.ptg.dest = 1;
^ permalink raw reply
* Re: [PATCH v6 0/2] config: suggest the correct form when key contains "="
From: Junio C Hamano @ 2026-06-04 1:09 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget
Cc: git, Kristoffer Haugsbakk, Harald Nordgren
In-Reply-To: <pull.2302.v6.git.git.1780425808.gitgitgadget@gmail.com>
"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
> * The quiet parameter now lives on a static do_parse_config_key() instead
> of git_config_parse_key() itself. git_config_parse_key() is back to its
> three-argument signature; existing callers don't change.
> * New public git_config_key_is_valid() for callers that only need a yes/no
> check.
>
> Harald Nordgren (2):
> config: add git_config_key_is_valid() for quiet validation
> config: improve diagnostic for "set" with missing value
>
> builtin/config.c | 32 ++++++++++++++++++++++++++-
> config.c | 38 ++++++++++++++++++++++++--------
> config.h | 2 ++
> t/t1300-config.sh | 56 +++++++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 118 insertions(+), 10 deletions(-)
Looking good. Thanks. Will queue.
^ 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