* 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
* Re: [PATCH v5 1/2] config: let git_config_parse_key() validate quietly
From: Junio C Hamano @ 2026-06-04 1:09 UTC (permalink / raw)
To: Harald Nordgren
Cc: Harald Nordgren via GitGitGadget, git, Kristoffer Haugsbakk
In-Reply-To: <CAHwyqnXC=F-ewFy3nejzKZcSNNe5L73PcaH+b30wg_BKNpStYA@mail.gmail.com>
Harald Nordgren <haraldnordgren@gmail.com> writes:
>> Perhaps the updated "git_config_parse_key()" in this patch should be
>> renamed to be a file-scape static internal helper, and the existing
>> "git_config_parse_key()" should become a thin wrapper around that
>> new helper function, retaining the current external interface,
>> requiring no changes to existing callers.
>
> I want to remember a discussion on one of my earlier topics, a few
> months back, where someone else suggested instead of introducing two
> thin wrappers over a helper, we should update the callers instead.
>
> But for me either way is fine, maybe here it makes more sense, because
> of the repeated NULL/0/1 parameters.
If the "quiet" and "store_key" setting were independent, then I
wouldn't have made such a suggestion. But I got an impression that
with the updated code, there wasn't a valid use case to ask to
quietly store the discovered key.
An ideal refactoring would have been a low level helper function
that only yields error code, and git_config_parse_key() would call
it and react to the returned error code, stores the discovered key,
and produces error message on its own. Then such an "always quiet"
helper can be used for the purpose of the new caller, without having
to have "if (!quiet)" sprinkled all over. But that is certainly
cumbersome to arrange.
^ permalink raw reply
* Re: Mirror repositories for submodules
From: Junio C Hamano @ 2026-06-04 1:09 UTC (permalink / raw)
To: Benson Muite; +Cc: git
In-Reply-To: <875x42vlgv.fsf@emailplus.org>
Benson Muite <benson_muite@emailplus.org> writes:
> Would a contribution to add mirror repositories as alternate submodule
> sources be considered for inclusion? Some projects have mirror
> repositories on other hosting services, and may have bandwidth limits on
> their primary hosting service. Being able to indicate mirror
> repositories for where to check for updates and sources for submodules
> when doing `git clone --recurse-submodules https://my.repo ` or `git
> submodule update --init --recursive` would be helpful when there is a
> timeout.
I do not see why such a "oh, the repository at $URL1 seems to be
down, but we know $URL2 serves the equivalent information, so let's
go there instead" feature has to be limited to submodule use case.
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.
^ permalink raw reply
* Re: [PATCH] Makefile: drop duplicate %.a from link recipes
From: Junio C Hamano @ 2026-06-04 0:33 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget; +Cc: git, Harald Nordgren
In-Reply-To: <pull.2314.git.git.1780269406949.gitgitgadget@gmail.com>
"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.
^ permalink raw reply
* Re: [PATCH v2 9/9] builtin/history: implement "drop" subcommand
From: Junio C Hamano @ 2026-06-03 23:58 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Pablo Sabater
In-Reply-To: <20260603-b4-pks-history-drop-v2-9-742cb5b5176d@pks.im>
Patrick Steinhardt <ps@pks.im> writes:
> +static int update_worktree(struct repository *repo,
> + const struct commit *old_head,
> + const struct commit *new_head,
> + bool dry_run)
> +{
> + struct reset_head_opts opts = {
> + .oid_from = &old_head->object.oid,
> + .oid = &new_head->object.oid,
> + .flags = RESET_HEAD_SKIP_REF_UPDATES,
> + };
> + if (dry_run)
> + opts.flags |= RESET_HEAD_DRY_RUN;
> + return reset_head(repo, &opts);
> +}
> + ...
> + /*
> + * If HEAD will move as a result of the rewrite then we'll have to
> + * merge in the changes into the worktree and index. This merge can of
> + * course conflict, which will cause the whole operation to abort.
> + *
> + * If we had already updated the refs at that point then we'd have an
> + * inconsistent repository state. So we first perform a dry-run merge
> + * here before updating refs.
> + */
> + if (!dry_run && !is_bare_repository()) {
> + ret = find_head_tree_change(repo, &result, &old_head,
> + &new_head, &head_moves);
> + if (ret < 0)
> + goto out;
> +
> + if (head_moves && update_worktree(repo, old_head, new_head, true) < 0) {
> + ret = error(_("dropping this commit would "
> + "overwrite local changes; aborting"));
> + goto out;
> + }
> + }
This block is skipped under --dry-run, but update_worktree is
equipped to (and indeed run unconditionally here) run in the dry-run
mode. Does it mean that "git history drop --dry-run" that user runs
to see which refs may be updated will not get warned about possible
worktree conflicts that would prevent the real run from happening?
Unless there is a compelling reason not to, I think --dry-run should
be a close simulation of what would happen without it.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 5/9] reset: introduce ability to skip reference updates
From: Junio C Hamano @ 2026-06-03 23:51 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Pablo Sabater
In-Reply-To: <20260603-b4-pks-history-drop-v2-5-742cb5b5176d@pks.im>
Patrick Steinhardt <ps@pks.im> writes:
> @@ -112,6 +113,9 @@ int reset_head(struct repository *r, const struct reset_head_opts *opts)
> if (opts->branch_msg && !opts->branch)
> BUG("branch reflog message given without a branch");
>
> + if (skip_ref_updates && (opts->branch || refs_only))
> + BUG("asked to perform ref updates and skip them at the same time");
;-) That's certainly a careful safety valve.
Would we also want to catch skip_ref_updates && update_orig_head
being both set as a bogus request?
> if (!refs_only && !dry_run && repo_hold_locked_index(r, &lock, LOCK_REPORT_ON_ERROR) < 0) {
> ret = -1;
> goto leave_reset_head;
> @@ -196,7 +200,8 @@ int reset_head(struct repository *r, const struct reset_head_opts *opts)
> goto leave_reset_head;
> }
>
> - if (oid != &head_oid || update_orig_head || switch_to_branch)
> + if (!skip_ref_updates &&
> + (oid != &head_oid || update_orig_head || switch_to_branch))
> ret = update_refs(r, opts, oid, head);
>
> leave_reset_head:
> diff --git a/reset.h b/reset.h
> index 9f696382c1..cb0700ffa7 100644
> --- a/reset.h
> +++ b/reset.h
> @@ -27,6 +27,9 @@ enum reset_head_flags {
> * any user-visible state.
> */
> RESET_HEAD_DRY_RUN = (1 << 5),
> +
> + /* Skip updating any references, only update the worktree and index. */
> + RESET_HEAD_SKIP_REF_UPDATES = (1 << 6),
> };
>
> struct reset_head_opts {
^ permalink raw reply
* Re: [PATCH v2 4/9] reset: introduce dry-run mode
From: Junio C Hamano @ 2026-06-03 23:49 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Pablo Sabater
In-Reply-To: <20260603-b4-pks-history-drop-v2-4-742cb5b5176d@pks.im>
Patrick Steinhardt <ps@pks.im> writes:
> In a subsequent commit we'll add add another caller to `reset_head()`
add add?
> that wants to perform a dry-run check of whether it would be possible to
> udpate the index and working tree when moving to a new commit. Introduce
udpate?
> a new flag that lets the caller perform this operation.
>
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
> reset.c | 44 +++++++++++++++++++++++++++++++++-----------
> reset.h | 6 ++++++
> 2 files changed, 39 insertions(+), 11 deletions(-)
>
> diff --git a/reset.c b/reset.c
> index 9ff14f5ed1..a8d7eea4d6 100644
> --- a/reset.c
> +++ b/reset.c
> @@ -92,11 +92,14 @@ int reset_head(struct repository *r, const struct reset_head_opts *opts)
> unsigned reset_hard = opts->flags & RESET_HEAD_HARD;
> unsigned refs_only = opts->flags & RESET_HEAD_REFS_ONLY;
> unsigned update_orig_head = opts->flags & RESET_HEAD_ORIG_HEAD;
> + unsigned dry_run = opts->flags & RESET_HEAD_DRY_RUN;
> struct object_id *head = NULL, head_oid;
> struct tree_desc desc[2] = { { NULL }, { NULL } };
> struct lock_file lock = LOCK_INIT;
> struct unpack_trees_options unpack_tree_opts = { 0 };
> struct tree *tree;
> + struct index_state scratch_index = INDEX_STATE_INIT(r);
> + struct index_state *istate;
> const char *action;
> int ret = 0, nr = 0;
>
> @@ -109,7 +112,7 @@ int reset_head(struct repository *r, const struct reset_head_opts *opts)
> if (opts->branch_msg && !opts->branch)
> BUG("branch reflog message given without a branch");
>
> - if (!refs_only && repo_hold_locked_index(r, &lock, LOCK_REPORT_ON_ERROR) < 0) {
> + if (!refs_only && !dry_run && repo_hold_locked_index(r, &lock, LOCK_REPORT_ON_ERROR) < 0) {
> ret = -1;
> goto leave_reset_head;
> }
> @@ -124,16 +127,36 @@ int reset_head(struct repository *r, const struct reset_head_opts *opts)
> if (!oid)
> oid = &head_oid;
>
> - if (refs_only)
> - return update_refs(r, opts, oid, head);
> + if (refs_only) {
> + if (!dry_run)
> + return update_refs(r, opts, oid, head);
> + return 0;
> + }
> +
> + if (dry_run) {
> + if (read_index_from(&scratch_index, r->index_file, r->gitdir) < 0 ||
> + index_state_unmerged_to_stage0(&scratch_index) < 0) {
> + ret = error(_("could not read index"));
> + goto leave_reset_head;
> + }
> +
> + istate = &scratch_index;
> + } else {
> + if (repo_read_index_unmerged(r) < 0) {
> + ret = error(_("could not read index"));
> + goto leave_reset_head;
> + }
> + istate = r->index;
> + }
>
> action = reset_hard ? "reset" : "checkout";
> setup_unpack_trees_porcelain(&unpack_tree_opts, action);
> unpack_tree_opts.head_idx = 1;
> - unpack_tree_opts.src_index = r->index;
> - unpack_tree_opts.dst_index = r->index;
> + unpack_tree_opts.src_index = istate;
> + unpack_tree_opts.dst_index = istate;
> unpack_tree_opts.fn = reset_hard ? oneway_merge : twoway_merge;
> - unpack_tree_opts.update = 1;
> + unpack_tree_opts.update = !dry_run;
> + unpack_tree_opts.dry_run = dry_run;
> unpack_tree_opts.merge = 1;
> unpack_tree_opts.preserve_ignored = 0; /* FIXME: !overwrite_ignore */
> unpack_tree_opts.skip_cache_tree_update = 1;
> @@ -141,11 +164,6 @@ int reset_head(struct repository *r, const struct reset_head_opts *opts)
> if (reset_hard)
> unpack_tree_opts.reset = UNPACK_RESET_PROTECT_UNTRACKED;
>
> - if (repo_read_index_unmerged(r) < 0) {
> - ret = error(_("could not read index"));
> - goto leave_reset_head;
> - }
> -
> if (!reset_hard && !fill_tree_descriptor(r, &desc[nr++], &head_oid)) {
> ret = error(_("failed to find tree of %s"),
> oid_to_hex(&head_oid));
> @@ -162,6 +180,9 @@ int reset_head(struct repository *r, const struct reset_head_opts *opts)
> goto leave_reset_head;
> }
>
> + if (dry_run)
> + goto leave_reset_head;
> +
> tree = repo_parse_tree_indirect(r, oid);
> if (!tree) {
> ret = error(_("unable to read tree (%s)"), oid_to_hex(oid));
> @@ -181,6 +202,7 @@ int reset_head(struct repository *r, const struct reset_head_opts *opts)
> leave_reset_head:
> rollback_lock_file(&lock);
> clear_unpack_trees_porcelain(&unpack_tree_opts);
> + release_index(&scratch_index);
> while (nr)
> free((void *)desc[--nr].buffer);
> return ret;
> diff --git a/reset.h b/reset.h
> index 97ced2601e..9f696382c1 100644
> --- a/reset.h
> +++ b/reset.h
> @@ -21,6 +21,12 @@ enum reset_head_flags {
>
> /* Update ORIG_HEAD as well as HEAD */
> RESET_HEAD_ORIG_HEAD = (1 << 4),
> +
> + /*
> + * Perform a dry-run by performing the operation without updating
> + * any user-visible state.
> + */
> + RESET_HEAD_DRY_RUN = (1 << 5),
> };
>
> struct reset_head_opts {
^ permalink raw reply
* Re: [PATCH] worktree: record creation time and free-form note
From: Kiesel, Norbert @ 2026-06-03 22:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <CAPGaHksjsSefYmGPBxKLw8DDADR5AwTiHTbHq0UyBBtg3CKq9Q@mail.gmail.com>
Hi Junio,
I looked at the usage of `.git/description` and I could not find any
usage. We do have
Git branch descriptions which are stored in .git/config, but that does
not seem to be
usable to store the worktree description or the worktree creation timestamp.
So are you ok if I send the PR again, just using "description" instead
of "note"?
Best,
Norbert
On Tue, Jun 2, 2026 at 5:03 PM Kiesel, Norbert
<norbert.kiesel@creditkarma.com> wrote:
>
> Yes, I could change my PR to use $GIT_COMMON_DIR/worktrees/$worktree/description
> instead of the currently used $GIT_COMMON_DIR/worktrees/$worktree/note.
>
> Give me a day, and I can create the updated diff.
>
> Best,
> Norbert
>
> On Tue, Jun 2, 2026 at 4:52 PM Junio C Hamano <gitster@pobox.com> wrote:
> >
> > "Kiesel, Norbert" <norbert.kiesel@creditkarma.com> writes:
> >
> > > From 130cd5e4a25e6672b2a97268e1100b6ef03fa552 Mon Sep 17 00:00:00 2001
> > > From: Norbert Kiesel <norbert.kiesel@creditkarma.com>
> > > Date: Mon, 1 Jun 2026 17:03:39 -0700
> > > Subject: [PATCH] worktree: record creation time and free-form note
> > >
> > > Add per-worktree metadata so users can answer "what is this worktree
> > > for, and when did I make it?" without resorting to external notes.
> >
> > Although I am not personally interested in this topic all that much,
> > let me point out that we have $GIT_DIR/description file that may be
> > useful for something like this. It has been the canonical place for
> > the main repository to identify itself long before secondary worktrees
> > were invented and $GIT_COMMON_DIR/worktrees/$worktree/description would
> > be a natural extension of the concept, I'd presume.
>
>
>
> --
> Norbert Kiesel | Staff Software Engineer | Credit Karma
> norbert.kiesel@creditkarma.com | www.creditkarma.com
>
> This email may contain confidential and privileged information. Any
> review, use, distribution, or disclosure by anyone other than the
> intended recipient(s) is prohibited. If you are not the intended
> recipient, please contact the sender by reply email and delete all
> copies of this message.
--
Norbert Kiesel | Staff Software Engineer | Credit Karma
norbert.kiesel@creditkarma.com | www.creditkarma.com
This email may contain confidential and privileged information. Any
review, use, distribution, or disclosure by anyone other than the
intended recipient(s) is prohibited. If you are not the intended
recipient, please contact the sender by reply email and delete all
copies of this message.
^ permalink raw reply
* Re: [PATCH v2] git-gui: silence install recipes under "make -s"
From: Johannes Sixt @ 2026-06-03 21:38 UTC (permalink / raw)
To: Harald Nordgren; +Cc: git, Harald Nordgren via GitGitGadget
In-Reply-To: <pull.2318.v2.git.git.1780510415838.gitgitgadget@gmail.com>
Am 03.06.26 um 20:13 schrieb Harald Nordgren via GitGitGadget:
> 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.
>
> Signed-off-by: Harald Nordgren <harald.nordgren@kostdoktorn.se>
> ---
> git-gui: silence install recipes under "make -s"
>
> * Clarified commit message.
I appreciate that you made it more suitable to be used outside of the
Git repository, but it still does not explain why the change from ifeq
to ifneq is not sufficient to negate the condition.
In fact, the old version of the condition never worked as intended. The
parameters of findstring are in the order needle,haystack. The arguments
are -,s for normal `make` and -s,s for `make -s`. In no case is the
needle found in the haystack. The new version is correct. This is worth
to be mentioned.
> +ifneq ($(findstring s,$(firstword -$(MAKEFLAGS))),s)
> -ifeq ($(findstring $(firstword -$(MAKEFLAGS)),s),s)
-- Hannes
^ permalink raw reply
* Re: [PATCH v2 1/3] Documentation/MyFirstContribution: recommend shallow threading
From: Kristoffer Haugsbakk @ 2026-06-03 20:09 UTC (permalink / raw)
To: Patrick Steinhardt, git
Cc: Junio C Hamano, Tuomas Ahola, Weijie Yuan, Ramsay Jones
In-Reply-To: <20260603-pks-b4-v2-1-a8aea0aa2c23@pks.im>
On Wed, Jun 3, 2026, at 08:58, Patrick Steinhardt wrote:
> The "MyFirstContribution" document recommends the use of deep threading:
> every cover letter of subsequent iterations shall be linked to the cover
> letter of the preceding version. The result of this is that eventually,
> threads with many versions are getting nested so deep that it becomes
> hard to follow.
>
> Adapt the recommendation to instead propose shallow threading: instead
> of linking the cover letter to the previous cover letter, the user is
> supposed to always link it to the first cover letter. This still makes
> it easy to follow the iterations, but has the benefit of nesting to a
> much shallower level.
>
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
> Documentation/MyFirstContribution.adoc | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>[snip]
Only today did I notice that your eleven-version git-history(1) series
uses this style. (Or: today I noticed that it’a thing)
https://lore.kernel.org/git/20250819-b4-pks-history-builtin-v1-0-9b77c32688fe@pks.im/
That would have had a bad rightward drift with the usual reply to
previous version style.
I’ve been reading Lore on Safari on mobile and some threads go so deep
that the replies just become unclickable backticks. *Huh?* Well I can
use the Next/Previous buttons and maybe there is a way to make it work,
but I’ve just given up on those right-going subthreads. ;)
... and I also don’t see any drawbacks to that threading, using that
series as an example. It looks just as comprehensible as the usual
style.
^ 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