* Re: [PATCH v1 11/11] git-gui: add gui and pick as explicit subcommands
From: Mark Levedahl @ 2026-05-19 18:45 UTC (permalink / raw)
To: Johannes Sixt; +Cc: egg_mushroomcow, bootaina702, git
In-Reply-To: <3b16fbc6-074b-410d-861e-6f77794b02a0@kdbg.org>
On 5/19/26 4:21 AM, Johannes Sixt wrote:
> Am 16.05.26 um 17:42
>
>
> I think I would be happier with the structure
>
> if not subcommand pick
> discover gitdir
> if error
> set subcommand pick
>
> if subcommand pick
> pick_repo
> set subcommand gui
>
> because this clarifies that pick_repo must erase all current traces of
> GIT_DIR and GIT_WORK_TREE from the envionment and must complete with a
> valid setup.
>
> With the structure in the proposed patch
>
> if subcommand pick
> pick_repo
> set subcommand gui
>
> discover gitdir
> if error
> pick_repo
>
> we still need the same operation of pick_repo, but after it runs due to
> a pick command, we go into "discover gitdir" mode in an already modified
> environment, something that does not happen if pick_repo runs due to the
> error in the gitdir discovery.
>
> -- Hannes
>
What I have now is
if (enabled gitdir discovery) {
discover gitdir
maybe an error occurs and gitdir remains {}
}
if (enabled pick && gitdir eq {}) {
unset GIT_DIR .. (just to be friendly, could throw an error instead...)
pick
discover gitdir to VALIDATE pick gave us a good thing
}
if no gitdir {
error No Repository
}
then on to worktree discovery (which also validates what pick returns as pick may not have
done so).
So, we can independently enable normal discovery or pick, and with both enabled pick can
be used to recover from an error in normal discovery. Either way, there is only one block
of code running pick, it is not a separate proc invoked multiple places. I hope this
scratches your itch.
Still scrubbing things, should send out in a day or two.
Mark
^ permalink raw reply
* Re: [PATCH v1 10/11] git-gui: improve worktree discovery
From: Mark Levedahl @ 2026-05-19 19:00 UTC (permalink / raw)
To: Johannes Sixt; +Cc: egg_mushroomcow, bootaina702, git
In-Reply-To: <5081fcc5-19b5-49aa-a33c-2c13aba7edb1@kdbg.org>
On 5/19/26 4:16 AM, Johannes Sixt wrote:
> Am 16.05.26 um 17:28 schrieb Mark Levedahl:
>> On 5/16/26 4:16 AM, Johannes Sixt wrote:
>>> Am 14.05.26 um 16:33 schrieb Mark Levedahl:
>>>> + if {[is_gitvars_error $err]} {
>>>> + exit 1
>>>> + }
>>>> + set _gitworktree {}
>>>> + set _prefix {}
>>>> + if {[is_enabled bare]} {
>>>> + cd $_gitdir
>>> Why change the directory here? If we run `git gui browser master dir` we
>>> do not want to change the directory in an uncontrolled manner. The
>>> argument parser will want to check for the existence of files, and then
>>> we do not want to operate from a random directory.
>>>
>>> Also, I think that the check must be for [is_bare] and not [is_enabled
>>> bare].
>> [is_enabled_bare] is correct. This code handles the case:
>> - neither the startup directory nor GIT_WORK_TREE are useable worktrees, so [is_bare]
>> is currently true.
>> - the command given is browser or blame so a worktree is not needed. We can proceed.
> But in the case where the command is browser or blame, the argument
> parser must later check for the existence of files, provided that a
> worktree is present. But this conditional would change directory to
> somewhere that is not a worktree at all even though a worktree is
> available. So, I am still convinced that [is_bare] is correct.
I did change this. but...
I have reworked the blame/browser parser so it fully matches git blame parsing for the
single rev + path (or path rev) cases, all now do the same thing with or without a
worktree as they all work from git history, so having a worktree becomes almost moot (I
found issues with how git-gui handles --, it is dead wrong in some cases if the intent is
to match git-blame). What doesn't change is what blame displays based upon uncommitted or
staged changes in the worktree (if it does anything, but comments from 2007 suggest it
does, I haven't tested). I've done nothing to change that, only finding the args to pass
in to browser / blame. So, if a worktree exists, blame will still use the info there as it
does now.
Mark
^ permalink raw reply
* Re: [PATCH] http: fix memory leak in fetch_and_setup_pack_index()
From: Jeff King @ 2026-05-19 19:17 UTC (permalink / raw)
To: LorenzoPegorari; +Cc: git, Taylor Blau, Junio C Hamano, Patrick Steinhardt, fox
In-Reply-To: <agx5tblaCZNsYEBq@lorenzo-VM>
On Tue, May 19, 2026 at 04:54:45PM +0200, LorenzoPegorari wrote:
> Inside the function `fetch_and_setup_pack_index()`, when the pack
> obtained using `fetch_pack_index()` fails to be verified by
> `parse_pack_index()`, the function returns without closing and freeing
> said pack.
>
> Fix this by calling `close_pack_index()` to munmap the index file for
> the leaking pack (which might have been mmapped by `fetch_pack_index()`
> or `verify_pack_index()`), and then free it.
OK, I agree we are leaking here, but after reading the patch I'm left
with a few questions.
> ret = verify_pack_index(new_pack);
> - if (!ret)
> - close_pack_index(new_pack);
> +
> + close_pack_index(new_pack);
This part was a little confusing at first, because it looked like we are
already closing the index. But we were doing so on _success_, not on
failure. Which is a little funny since the point is to be able to read
from it later, but OK.
At any rate, that is an existing oddity, and I agree that closing it
before freeing the struct is obviously the right thing to do.
> free(tmp_idx);
> - if (ret)
> + if (ret) {
> + free(new_pack);
> return -1;
> + }
And here we free the actual struct. Good.
But this existing free(tmp_idx) is what puzzles me. We do not need the
filename anymore regardless of success or failure, so freeing it makes
sense. But earlier in the function we have:
new_pack = parse_pack_index(the_repository, sha1, tmp_idx);
if (!new_pack) {
unlink(tmp_idx);
free(tmp_idx);
return -1; /* parse_pack_index() already issued error message */
}
So on parse failure we actually unlink it, but not on verification
failure. Which seems like it would leave cruft after the process ends.
And I suspect we probably we did prior to 63aca3f7f1 (dumb-http: store
downloaded pack idx as tempfile, 2024-10-25), when we started
registering it as a tempfile to be deleted at process exit.
So I _think_ we could get away with dropping the existing unlink() call
and just let it get cleaned up at process exit. But if we are going to
keep it, do we want to also unlink() in this error path? At which point
it might make more sense to have an "out" label to consolidate all of
this cleanup.
If we are going to unlink() here it may also make sense to just return
the tempfile struct from fetch_pack_index(), and then we can call
delete_tempfile() on it. See the in-code comment in 63aca3f7f1 which
mentions this hackery.
So I dunno. I think your patch is doing the right thing as-is, but it
may be worth taking a moment to clean this up a bit further.
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (May 2026, #04)
From: Jeff King @ 2026-05-19 19:19 UTC (permalink / raw)
To: Taylor Blau; +Cc: Junio C Hamano, git
In-Reply-To: <agyPJa3E2lPI9K/G@nand.local>
On Tue, May 19, 2026 at 12:26:13PM -0400, Taylor Blau wrote:
> > * tb/incremental-midx-part-3.3 (2026-04-29) 16 commits
> [...]
> Apologies, I didn't realize you were waiting on these until seeing this
> WC report. I sent an extremely tiny reroll
>
> https://lore.kernel.org/git/cover.1779206239.git.me@ttaylorr.com/
>
> that addresses the two outstanding comments you linked. They are very
> minor changes, and queueing either version of the series would be
> equally fine IMHO.
I peeked at the v4 range diff, and it looks good to me.
-Peff
^ permalink raw reply
* Re: [PATCH 1/5] doc: convert git-bisect to synopsis style
From: Jean-Noël AVILA @ 2026-05-19 20:57 UTC (permalink / raw)
To: Jean-Noël Avila via GitGitGadget, Junio C Hamano; +Cc: git
In-Reply-To: <xmqq4ik5d0le.fsf@gitster.g>
On Monday, 18 May 2026 02:26:37 CEST Junio C Hamano wrote:
> "Jean-Noël Avila via GitGitGadget" <gitgitgadget@gmail.com> writes:
> > From: =?UTF-8?q?Jean-No=C3=ABl=20Avila?= <jn.avila@free.fr>
> >
> > Convert Documentation/git-bisect.adoc to the modern synopsis style.
> >
> > - Replace [verse] with [synopsis] in the SYNOPSIS block
>
> This was expected.
>
> > - Remove single quotes around command names in the synopsis
> > - Use backticks for inline commands, options, refs, and special values
> > - Apply [synopsis] attribute to in-body command-form code blocks
>
> This is very much unexpected. I think everybody thought [synopsis]
> was invented to be used for the SYNOPSIS section at the beginning of
> each manual page, and ...
In fact, the synopsis style was already applied before outside the SYNOPSIS
sections in diff-generate-patch.adoc when describing the output of the -p
option.
This formatting reaches beyond the synopsis, but the rationale is simple. Each
time a listing contains some <placeholder>, what is actually described is a
model, not an actual output. The <placeholder> needs a special formatting to
convey its special meaning.
That may mean that the naming of "synopsis style" may not be adequate.
>
> > SYNOPSIS
> > --------
> >
> > -[verse]
> > -'git bisect' start [--term-(bad|new)=<term-new> --term-(good|old)=<term-
old>]
> > - [--no-checkout] [--first-parent] [<bad> [<good>...]]
[--] [<pathspec>...]
> > ...
> > -'git bisect' help
> > +[synopsis]
> > +git bisect start [--term-(bad|new)=<term-new> --term-(good|old)=<term-
old>]
> > + [--no-checkout] [--first-parent] [<bad> [<good>...]] [--]
[<pathspec>...]
> > ...
> > +git bisect help
>
> ... a change like this is very much expected and understandable, but
>
> new appearances of [synonsis] in places like:
> > +[synopsis]
> >
> > ------------------------------------------------
> > $ git bisect reset <commit>
> > ------------------------------------------------
>
> and
>
> > +[synopsis]
> >
> > ------------------------------------------------
> > git bisect old [<rev>]
> > ------------------------------------------------
>
> were a bit surprising and confusing. They are not exactly command
> syntax definitions (which is the SYNOPSIS section is about), but
> examples of usage.
Are they? the "[<rev>]" block is typical of synopsis syntax, not something you
would actually type in.
> The one with '$' command line prompt feels
> particularly confusing, as the prompt is not something that the
> end-user gives, unlike what we write in the synopsis section.
>
The '$' is an error to me. Will fix.
> Other than that, this is quite exciting.
^ permalink raw reply
* Re: [PATCH 1/5] doc: convert git-bisect to synopsis style
From: Jean-Noël AVILA @ 2026-05-19 21:03 UTC (permalink / raw)
To: Jean-Noël Avila via GitGitGadget, Junio C Hamano; +Cc: git
In-Reply-To: <87tss5wjpp.fsf@gitster.g>
On Monday, 18 May 2026 04:10:58 CEST Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> >> +[synopsis]
> >>
> >> ------------------------------------------------
> >> $ git bisect reset <commit>
> >> ------------------------------------------------
> >
> > and
> >
> >> +[synopsis]
> >>
> >> ------------------------------------------------
> >> git bisect old [<rev>]
> >> ------------------------------------------------
> >
> > were a bit surprising and confusing. They are not exactly command
> > syntax definitions (which is the SYNOPSIS section is about), but
> > examples of usage. The one with '$' command line prompt feels
> > particularly confusing, as the prompt is not something that the
> > end-user gives, unlike what we write in the synopsis section.
> >
> > Other than that, this is quite exciting.
>
> Well, my local test with asciidoctor did not barf, but it seems that
> the documentation pipeline run in GitHub Actions CI is unhappy.
>
> https://github.com/git/git/actions/runs/26008649802/job/
76444895183#step:4:4846
>
> I do not know what the differences among the three environments
> (counting your development environment---only one of which fails)
> are offhand.
Thank you for pointing out that the test fails with Asciidoctor. On my debian
testing, both asciidoc.py and asciidoctor pass. I can try and revert to
paragraph styling instead of block styling.
^ permalink raw reply
* Re: [PATCH v1 11/11] git-gui: add gui and pick as explicit subcommands
From: Johannes Sixt @ 2026-05-19 21:15 UTC (permalink / raw)
To: Mark Levedahl; +Cc: egg_mushroomcow, bootaina702, git
In-Reply-To: <ffbbd733-2af9-4ff5-9354-cb2f333927a8@gmail.com>
Am 19.05.26 um 20:45 schrieb Mark Levedahl:
> What I have now is
>
> if (enabled gitdir discovery) {
> discover gitdir
> maybe an error occurs and gitdir remains {}
> }
>
> if (enabled pick && gitdir eq {}) {
> unset GIT_DIR .. (just to be friendly, could throw an error instead...)
> pick
> discover gitdir to VALIDATE pick gave us a good thing
> }
>
> if no gitdir {
> error No Repository
> }
>
> then on to worktree discovery (which also validates what pick returns as pick may not have
> done so).
Sounds good.
-- Hannes
^ permalink raw reply
* Re: [PATCH] git-jump: pick a mode automatically when invoked without arguments
From: Jeff King @ 2026-05-19 21:22 UTC (permalink / raw)
To: Greg Hurrell; +Cc: Erik Cervin Edin, git
In-Reply-To: <8f4b75d8-f875-434a-8fc5-06a708cbc53f@app.fastmail.com>
On Tue, May 19, 2026 at 11:03:44AM +0200, Greg Hurrell wrote:
> On Thu, May 14, 2026, at 5:40 PM, Erik Cervin Edin wrote:
> > On 26/05/08 09:07AM, Greg Hurrell via GitGitGadget wrote:
> > > -usage: git jump [--stdout] <mode> [<args>]
> > > +usage: git jump [--stdout] [<mode>] [<args>]
> >
> > The usage message makes <mode> optional but doesn't explain what
> > happens when you omit it. Seems worth documenting the auto-detect behavior
> > there too.
> >
> > If we're going to teach git-jump how to be more clever about where to jump,
> > does it also make sense to bake `git jump ws` into this?
> >
> > Also, if this is going to grow into a proper auto-detect heuristic, it
> > might be cleaner as a first-class mode rather than logic spliced into the
> > argument parser. Something like:
> >
> > mode_auto() {
> > if test -n "$(git ls-files -u)"; then
> > mode_merge "$@"
> > elif ! git diff --quiet; then
> > mode_diff "$@"
> > elif ! git diff --cached --check >/dev/null 2>&1; then
> > mode_ws --cached "$@"
> > else
> > return 0
> > fi
> > }
> >
> > That way `git jump auto` works explicitly, bare `git jump` defaults
> > to it (just `set -- auto` when $# -lt 1), and the usage text can
> > document the heuristic. It also keeps the detection and dispatch in
> > one place in case someone wants to tweak the priority later.
>
> All of those suggestions sound reasonable to me. Jeff, do you agree?
> If so, I can update the patch.
Yeah, I agree that having an explicit "auto" mode (and then just
defaulting to it) makes perfect sense.
I don't really have an opinion on adding "ws" in here. Despite being the
person who added the whitespace mode in the first place, I can't
remember ever using it in the last 10 years. ;) But the cost is fairly
low to support it, so we might as well.
-Peff
^ permalink raw reply
* Re: [PATCH] revision: use priority queue in limit_list()
From: Jeff King @ 2026-05-19 21:56 UTC (permalink / raw)
To: Kristofer Karlsson
Cc: Derrick Stolee, Junio C Hamano,
Kristofer Karlsson via GitGitGadget, git
In-Reply-To: <CAL71e4O6UcnqmxDgqyGqvgvfruSzeoz6Wj5muXiwEp_8y2wAcg@mail.gmail.com>
On Tue, May 19, 2026 at 11:33:19AM +0200, Kristofer Karlsson wrote:
> I took a look at your branch. Our approaches differ mainly in
> how broadly the prio_queue replaces the linked list. Here's a summary
> of the tradeoffs as I see them:
>
> Your approach: replace commits entirely with struct prio_queue.
> Every access site is converted, and boundary cases (bisect,
> topo-sort, simplify_merges) convert queue->list->queue when they need
> list-based APIs.
>
> My approach: keep the linked list for setup and add a separate
> commit_queue for the walk phase. External callers that read the
> list between prepare_revision_walk() and the walk are unchanged.
> The conversion happens once when the walk begins.
Yeah, I think that is an accurate summary. What I worry about with your
approach is any code that looks at or modifies the commit list during
the traversal. It has to know whether to use the queue or the list.
> On the walk side, my second and third commits refactor
> get_revision_1() to use a vtable ("walk_ops") that selects the right
> pop/expand strategy once and caches it:
>
> struct revision_walk_ops {
> void (*init)(struct rev_info *);
> struct commit *(*next)(struct rev_info *);
> int (*expand)(struct rev_info *, struct commit *);
> };
>
> static struct revision_walk_ops streaming_ops =
> { rev_info_commit_list_to_queue, next_streaming, expand_streaming };
> static struct revision_walk_ops limited_ops =
> { NULL, next_commit_list, NULL };
> /* ...reflog_ops, topo_ops, no_walk_ops... */
I looked at the patch you linked for this. I'm undecided on whether this
makes things simpler (because the if/else-cascade is in one spot) or
more confusing (because now the details are all hidden behind a layer of
abstraction).
> I benchmarked both approaches against a 2.4M-commit squash-merge-
> heavy monorepo (best of 3 runs each, commit-graph present):
>
> Benchmark mainline kk jk
> rev-list HEAD (streaming, full DAG) 21.8s 6.9s 6.9s
> --ancestry-path ~100K (limited) 21.8s 4.8s 5.0s
> rev-list --count HEAD~10000..HEAD 17.7s 3.7s 3.8s
> log --oneline -1000 0.1s 0.1s 0.1s
>
> Both give ~3-5x speedups over mainline. The streaming walk is
> identical. On limited walks kk is ~4% faster, which I think comes
> from avoiding the queue rebuild at the end of limit_list() -- jk's
> commit_list_to_queue() drains the result list back into the queue,
> while kk leaves the result as a linked list (which the limited walk
> then just pops from directly).
It would be easy-ish to further convert limit_list() to store newlist as
a queue, and then transfer ownership of its fields into revs->commits
(i.e., a struct assignment).
One possible complication is that we do pass "newlist" into a few
sub-functions, like cherry_pick_list(). Looking at that function, it
iterates over the list, but it's not clear to me if the order matters.
Certainly not in the first loop, but later we do some flag assignments.
I _think_ they're all independent, but I'm not sure.
Obviously we can iterate over the prio_queue in date order with a series
of get() calls, but that is roughly equivalent to building a list (and
we have to rebuild the queue after, too). Of course that is already
happening in limit_to_ancestry(), which builds the reverse-order list.
So I dunno. Moving to the dual-structure state feels messy and
error-prone to me, but it does perhaps let us move a little more
incrementally.
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (May 2026, #04)
From: Justin Tobler @ 2026-05-19 22:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqv7clbizy.fsf@gitster.g>
On 26/05/18 10:32AM, Junio C Hamano wrote:
> * jt/odb-transaction-write (2026-05-14) 7 commits
> - odb/transaction: make `write_object_stream()` pluggable
> - object-file: generalize packfile writes to use odb_write_stream
> - object-file: avoid fd seekback by checking object size upfront
> - object-file: remove flags from transaction packfile writes
> - odb: update `struct odb_write_stream` read() callback
> - odb/transaction: use pluggable `begin_transaction()`
> - odb: split `struct odb_transaction` into separate header
> (this branch is used by ps/odb-in-memory.)
>
> ODB transaction interface is being reworked to explicitly handle
> object writes.
>
> Will merge to 'next'?
> source: <20260514183740.1505171-1-jltobler@gmail.com>
I think this series should be ready to go now. The last version
submitted fixed the leak reported by Peff.
Thanks,
-Justin
^ permalink raw reply
* Re: [PATCH v4 04/13] path-walk: always emit directly-requested objects
From: Taylor Blau @ 2026-05-19 23:22 UTC (permalink / raw)
To: Derrick Stolee via GitGitGadget
Cc: git, christian.couder, gitster, johannes.schindelin, johncai86,
karthik.188, kristofferhaugsbakk, newren, peff, ps,
Derrick Stolee
In-Reply-To: <e77c8a6bbc22da3428751f81ff5ee79aa5364237.1778707135.git.gitgitgadget@gmail.com>
On Wed, May 13, 2026 at 09:18:46PM +0000, Derrick Stolee via GitGitGadget wrote:
> diff --git a/path-walk.c b/path-walk.c
> index 6e426af433..05bfc1c114 100644
> --- a/path-walk.c
> +++ b/path-walk.c
> @@ -248,6 +248,17 @@ static int add_tree_entries(struct path_walk_context *ctx,
> return 0;
> }
>
> +/*
> + * Paths starting with '/' (e.g., "/tags", "/tagged-blobs") hold objects that
> + * were directly requested by 'pending' objects rather than discovered during
> + * tree traversal.
> + */
> +static int path_is_for_direct_objects(const char *path)
> +{
> + ASSERT(path);
> + return path[0] == '/';
> +}
> +
Hmm, I still find this a little brittle. I think that 'path' here is
doing a number of jobs: it serves as a strmap key, it's visible to the
caller, and now also a "direct object" marker.
Could we instead store this explicitly on the type_and_oid_list, e.g. a
"direct" flag? I'm not sure whether that type has the right scope for
this information. If not, I wonder if there is another way to store this
information, since I worry that future callers may not know about this
convention and end up changing the result of the path-walk depending on
how they name their paths.
Thanks,
Taylor
^ permalink raw reply
* Re: [PATCH 1/9] Documentation/git-range-diff: add missing notes options in synopsis
From: Junio C Hamano @ 2026-05-19 23:47 UTC (permalink / raw)
To: Siddh Raman Pant
Cc: git, Calvin Wan, Patrick Steinhardt, Elijah Newren,
Kristoffer Haugsbakk
In-Reply-To: <290fe06d81e956253d3a06fc1e16848e0b86b603.1779207350.git.siddh.raman.pant@oracle.com>
Siddh Raman Pant <siddh.raman.pant@oracle.com> writes:
> Signed-off-by: Siddh Raman Pant <siddh.raman.pant@oracle.com>
> ---
> Documentation/git-range-diff.adoc | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
This has nothing to do with "external notes" topic, no?
>
> diff --git a/Documentation/git-range-diff.adoc b/Documentation/git-range-diff.adoc
> index 880557084533..5cc5e2ed5673 100644
> --- a/Documentation/git-range-diff.adoc
> +++ b/Documentation/git-range-diff.adoc
> @@ -11,7 +11,7 @@ SYNOPSIS
> git range-diff [--color=[<when>]] [--no-color] [<diff-options>]
> [--no-dual-color] [--creation-factor=<factor>]
> [--left-only | --right-only] [--diff-merges=<format>]
> - [--remerge-diff]
> + [--remerge-diff] [--no-notes | --notes[=<ref>]]
> ( <range1> <range2> | <rev1>...<rev2> | <base> <rev1> <rev2> )
> [[--] <path>...]
^ permalink raw reply
* Re: [PATCH 3/9] wrapper: add sleep_nanosec
From: Junio C Hamano @ 2026-05-19 23:50 UTC (permalink / raw)
To: Siddh Raman Pant
Cc: git, Calvin Wan, Patrick Steinhardt, Elijah Newren,
Kristoffer Haugsbakk
In-Reply-To: <6a8c2093643a385641ef0b2cde33839dc98d8678.1779207350.git.siddh.raman.pant@oracle.com>
Siddh Raman Pant <siddh.raman.pant@oracle.com> writes:
> Signed-off-by: Siddh Raman Pant <siddh.raman.pant@oracle.com>
> ---
The space above the signed-off-by line should be utilized to explain
why we want this change. For the purpose of this series, why do we
want to sleep at nanosecond precision?
> wrapper.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
> wrapper.h | 1 +
> 2 files changed, 50 insertions(+)
>
> diff --git a/wrapper.c b/wrapper.c
> index 16f5a63fbb61..1349255f1eb4 100644
> --- a/wrapper.c
> +++ b/wrapper.c
> @@ -10,6 +10,7 @@
> #include "gettext.h"
> #include "strbuf.h"
> #include "trace2.h"
> +#include <time.h>
>
> #ifdef HAVE_RTLGENRANDOM
> /* This is required to get access to RtlGenRandom. */
> @@ -708,6 +709,54 @@ void sleep_millisec(int millisec)
> poll(NULL, 0, millisec);
> }
>
> +#ifdef GIT_WINDOWS_NATIVE
> +/* No nanosleep() on Windows, so fall-back to using sleep_millisec(). */
> +int sleep_nanosec(uint64_t nanosec)
> +{
> + uint64_t ns_in_1ms = 1000000ULL; /* 1 ms = 10^6 ns */
> +
> + uint64_t millisec = nanosec / ns_in_1ms;
> + if (nanosec % ns_in_1ms)
> + millisec++;
> +
> + /* Chunked sleep if we can't represent in integer. */
> + while (millisec > INT_MAX) {
> + sleep_millisec(INT_MAX);
> + millisec -= INT_MAX;
> + }
> +
> + sleep_millisec((int)millisec);
> +
> + return 0;
> +}
> +#else
> +/* Not Windows, so use the more exact nanosleep(). */
> +int sleep_nanosec(uint64_t nanosec)
> +{
> + int ret;
> + struct timespec duration, remaining;
> +
> + /* Construct the duration by dividing the given total (1s = 10^9ns). */
> + duration.tv_sec = nanosec / 1000000000ULL;
> + duration.tv_nsec = nanosec % 1000000000ULL;
> +
> + while(1) {
> + ret = nanosleep(&duration, &remaining);
> +
> + /* Continue sleeping if interrupted. */
> + if (ret == -1 && errno == EINTR) {
> + duration = remaining;
> + continue;
> + }
> +
> + /* Either success or an error. */
> + break;
> + }
> +
> + return ret;
> +}
> +#endif /* GIT_WINDOWS_NATIVE */
> +
> int xgethostname(char *buf, size_t len)
> {
> /*
> diff --git a/wrapper.h b/wrapper.h
> index 15ac3bab6e97..c39992893a81 100644
> --- a/wrapper.h
> +++ b/wrapper.h
> @@ -130,6 +130,7 @@ int warn_on_fopen_errors(const char *path);
> int open_nofollow(const char *path, int flags);
>
> void sleep_millisec(int millisec);
> +int sleep_nanosec(uint64_t nanosec);
>
> enum {
> /*
^ permalink raw reply
* Re: [PATCH v4 03/13] t/perf: add pack-objects filter and path-walk benchmark
From: Taylor Blau @ 2026-05-19 23:51 UTC (permalink / raw)
To: Derrick Stolee via GitGitGadget
Cc: git, christian.couder, gitster, johannes.schindelin, johncai86,
karthik.188, kristofferhaugsbakk, newren, peff, ps,
Derrick Stolee
In-Reply-To: <fb8a0f9c43d4e41712839a93c4db6a294a7b5285.1778707135.git.gitgitgadget@gmail.com>
On Wed, May 13, 2026 at 09:18:45PM +0000, Derrick Stolee via GitGitGadget wrote:
> + >depth2-dirs &&
> + while read tdir
> + do
> + git ls-tree -d --name-only "HEAD:$tdir" 2>/dev/null || return 1
> + done <top-dirs >depth2-dirs.raw &&
> + sed "s|^|$tdir/|" <depth2-dirs.raw >depth2-dirs &&
Ugh, I think that this was a bad suggestion on my part, since $tdir
should be empty at this point.
Could we use --format here like so?
while read tdir
do
git ls-tree -d --format="$tdir/%(path)" "HEAD:$tdir" || return 1
done 2>/dev/null
I guess that breaks if $tdir contains a formatting atom, so perhaps we
should keep the spirit of the original (but using an intermediary file
instead of piping the output of Git to another command).
Sorry about that, I'm not sure why I thought that was a good idea when I
wrote it :-<.
Thanks,
Taylor
^ permalink raw reply
* Re: [PATCH v4 00/13] pack-objects: integrate --path-walk and some --filter options
From: Taylor Blau @ 2026-05-19 23:53 UTC (permalink / raw)
To: Derrick Stolee via GitGitGadget
Cc: git, christian.couder, gitster, johannes.schindelin, johncai86,
karthik.188, kristofferhaugsbakk, newren, peff, ps,
Derrick Stolee
In-Reply-To: <pull.2101.v4.git.1778707135.gitgitgadget@gmail.com>
On Wed, May 13, 2026 at 09:18:42PM +0000, Derrick Stolee via GitGitGadget wrote:
> UPDATES IN V4
> =============
>
> Thanks, Taylor for the careful review.
>
> * Several typos are fixed.
> * The performance test is corrected for issues around piping Git commands
> and made more robust to the existence of submodules.
> * BIG: The tree:0 patch is significantly updated in this version. Taylor
> correctly smelled a problem with the new logic to emit the /tagged-trees
> object set, and that signaled that those trees were previously never
> emitted. I update the test to demonstrate that changing the data shape
> (including tagged trees that are otherwise-unreachable) doesn't change
> the test behavior, signaling a bug. The behavior change details all the
> complexities of visiting only directly-requested trees under a tree:0
> filter and recursing on all trees in other cases.
Thanks for the new round; I gave this a lighter pass since I had
reviewed v3 in detail and the range-diff here looks good. I focused in
on a few patches in particular, and left a couple of minor comments.
My main reservation is that the "path starts with a '/' slash character
when directly requested" behavior feels brittle to me, and I am not sure
if there is a cleaner way to express that.
I'm curious what your thoughts are there. I think barring that things
are near-complete here, though I did note one issue with the t/perf
changes (that is my fault for having a bad suggestion on the earlier
round).
Thanks,
Taylor
^ permalink raw reply
* Re: [PATCH 7/9] notes: support an external command to display notes
From: Junio C Hamano @ 2026-05-20 0:03 UTC (permalink / raw)
To: Siddh Raman Pant
Cc: git, Calvin Wan, Patrick Steinhardt, Elijah Newren,
Kristoffer Haugsbakk
In-Reply-To: <9619077369f1a567bd505b1de1e4f672a5cd1950.1779207350.git.siddh.raman.pant@oracle.com>
Siddh Raman Pant <siddh.raman.pant@oracle.com> writes:
> This problem excaberates on scale.
>
> One solution to this is a realtime fetch or faster updation via
> external means, but unfortunately we lose the coherence in the
> display of information, and the user would end up reinventing
> git log.
>
> So let's add support for an external command to display the notes.
It is unclear how we would arrive at "So let's" from the previous
paragraph. It is not limited to notes but multiple people updating
the same thing racing against each other happens all the time in the
main part of the history, no? Isn't a better solution for such
racing situation usually based on a better merge support, I have to
wonder?
> We split the addition of documentation and tests from this commit for
> easier review. The new help text added in Documentation/ in the next
> commit should make the usage clear.
It is unclear why a large body of code that is not documented or
whose uses are not illustrated by examples found in the test scripts
is easier to review, though.
^ permalink raw reply
* Re: [PATCH v3 1/2] builtin/maintenance: fix locking with "--detach"
From: Taylor Blau @ 2026-05-20 0:10 UTC (permalink / raw)
To: Junio C Hamano
Cc: Patrick Steinhardt, git, Jean-Christophe Manciot,
Mikael Magnusson, Jeff King, Derrick Stolee
In-Reply-To: <xmqqy0hnipy4.fsf@gitster.g>
On Wed, May 13, 2026 at 07:06:27PM +0900, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
>
> > Note that this is a broader fix, as we now always reassign tempfiles
> > when daemonizing. This is a natural consequence of the semantics of
> > `daemonize()` though, as it essentially promises to continue running the
> > current process in the background.
>
> Exactly. I do agree that it is the right wy to look at it. The
> process that daemonise creates and leaves in the background is
> logically the process that continues to execute the service the
> process the user started, and unless the original process explicitly
> says "we are done serving this thing" and cleans up tempfile or
> lockfile it needed to serve that thing, it is natural to make the
> surviving process to take over the responsibility.
Yeah, this is how I had been thinking about it as well.
Thanks, Patrick, for making the change. I think that this series is in a
good spot, though I'd like to hear from Peff who had some comments on
the second patch from the previous round.
Once this is merged, I would suggest that we consider tagging a v2.54.1
with this in it, as the failure mode is pretty significant for users who
have concurrent maintenance processes running.
Thanks,
Taylor
^ permalink raw reply
* Re: [PATCH v3 4/8] promisor-remote: add 'local_name' to 'struct promisor_info'
From: Junio C Hamano @ 2026-05-20 0:12 UTC (permalink / raw)
To: Christian Couder
Cc: git, Patrick Steinhardt, Taylor Blau, Karthik Nayak,
Elijah Newren, Toon Claes, Christian Couder
In-Reply-To: <20260519153808.494105-5-christian.couder@gmail.com>
Christian Couder <christian.couder@gmail.com> writes:
> struct promisor_info {
> - const char *name;
> + const char *name; /* name the server advertised */
> + const char *local_name; /* name used locally (may be auto-generated) */
OK.
> @@ -449,6 +450,7 @@ struct promisor_info {
> static void promisor_info_free(struct promisor_info *p)
> {
> free((char *)p->name);
> + free((char *)p->local_name);
> free((char *)p->url);
> free((char *)p->filter);
> free((char *)p->token);
Having to cast away constness is irritating, but to the users of the
struct it may be safer to mark the members const so that they do not
touch them, perhaps. It is not a new problem with this patch but is
inherited from the existing code, so let's not worry too much about
it.
> +static const char *promisor_info_internal_name(struct promisor_info *p)
> +{
> + return p->local_name ? p->local_name : p->name;
> +}
Hmph.
> @@ -829,7 +836,7 @@ static bool promisor_store_advertised_fields(struct promisor_info *advertised,
> {
> struct promisor_info *p;
> struct string_list_item *item;
> - const char *remote_name = advertised->name;
> + const char *remote_name = promisor_info_internal_name(advertised);
Is this really a "remote_name", though? As ...
> @@ -937,7 +944,8 @@ static void filter_promisor_remote(struct repository *repo,
> /* Apply accepted remotes to the stable repo state */
> for_each_string_list_item(item, accepted_remotes) {
> struct promisor_info *info = item->util;
> - struct promisor_remote *r = repo_promisor_remote_find(repo, info->name);
> + const char *local = promisor_info_internal_name(info);
... this name "local" is "the name the thing is locally known to
us", promisor_info_local_name() might be a better name? I dunno.
I jsut found it odd that the return value of the same function is
stored in variables named "remote" and "local" at the same time ;-)
^ permalink raw reply
* Re: [PATCH] stash: reuse cached index entries in --patch temporary index
From: Junio C Hamano @ 2026-05-20 2:08 UTC (permalink / raw)
To: Adam Johnson via GitGitGadget
Cc: git, Thomas Gummerer, Elijah Newren, Phillip Wood, Victoria Dye,
Adam Johnson
In-Reply-To: <pull.2306.git.git.1779194605735.gitgitgadget@gmail.com>
"Adam Johnson via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Adam Johnson <me@adamj.eu>
>
> `git stash -p` prepares the interactive selection by creating a
> temporary index at HEAD, switching `GIT_INDEX_FILE` to it, and then
> running the `add -p` machinery.
>
> That temporary index was created by running `git read-tree HEAD`. The
> resulting index had no useful cached stat data or fsmonitor-valid bits
> from the real index. When `run_add_p()` refreshed that temporary index
> before showing the first prompt, it could end up lstat(2)-ing every
> tracked file, even in a repository where `git diff` and `git restore -p`
> can use fsmonitor to avoid that work.
>
> Create the temporary index in-process instead. Use `unpack_trees()` to
> reset the real index contents to HEAD while writing the result to the
> temporary index path. For paths whose index entries already match HEAD,
> `oneway_merge()` reuses the existing cache entries, preserving their
> cached stat data and `CE_FSMONITOR_VALID` state.
Clever. As the fsmonitor_valid bit is in-core only, updating the
index in-process would be an obvious and probably the only sensible
way to preserve it.
I however have to wonder if simply replacing the external process
invocation with "git read-tree -m HEAD" (i.e., oneway merge) gives
a similar speed-up.
> This makes the refresh performed by `run_add_p()` behave like the one
> used by `git restore -p`: unchanged paths can be skipped via fsmonitor
> instead of being scanned again.
>
> In a 206k file repository with `core.fsmonitor` enabled and a one-line
> change in one file, time to first prompt dropped from 34.774 seconds to
> 0.659 seconds.
Interesting.
> diff --git a/t/t3904-stash-patch.sh b/t/t3904-stash-patch.sh
> index 90a4ff2c10..4b3241c8cd 100755
> --- a/t/t3904-stash-patch.sh
> +++ b/t/t3904-stash-patch.sh
> @@ -84,6 +84,24 @@ test_expect_success 'none of this moved HEAD' '
> verify_saved_head
> '
>
> +test_expect_success 'stash -p with unmodified tracked files present' '
> + git reset --hard &&
> + echo line1 >alpha &&
> + echo line1 >beta &&
> + git add alpha beta &&
> + git commit -m "add alpha and beta" &&
> + echo line2 >>alpha &&
> + echo y | git stash -p &&
> + echo line1 >expect &&
> + test_cmp expect alpha &&
> + test_cmp expect beta &&
> + git stash pop &&
> + printf "line1\nline2\n" >expect &&
> + test_cmp expect alpha &&
> + echo line1 >expect &&
> + test_cmp expect beta
> +'
What I read from the proposed log message is that the change is
purely about performance and should not change any behaviour. Why
do we need a new test in t/t3904? I would not have surprised if we
saw a new test in t/perf/, though.
Thanks.
^ permalink raw reply
* Re: [PATCH] stash: reuse cached index entries in --patch temporary index
From: Junio C Hamano @ 2026-05-20 2:26 UTC (permalink / raw)
To: Adam Johnson via GitGitGadget
Cc: git, Thomas Gummerer, Elijah Newren, Phillip Wood, Victoria Dye,
Adam Johnson
In-Reply-To: <pull.2306.git.git.1779194605735.gitgitgadget@gmail.com>
"Adam Johnson via GitGitGadget" <gitgitgadget@gmail.com> writes:
> 2 files changed, 83 insertions(+), 6 deletions(-)
>
> diff --git a/builtin/stash.c b/builtin/stash.c
> index 32dbc97b47..48189cb9f7 100644
> --- a/builtin/stash.c
> +++ b/builtin/stash.c
> @@ -372,6 +372,57 @@ static int reset_tree(struct object_id *i_tree, int update, int reset)
> return 0;
> }
>
> +static int create_index_from_tree(const struct object_id *tree_id,
> + const char *index_path)
> +{
> + int nr_trees = 1;
> + int ret = 0;
> + struct unpack_trees_options opts;
> + struct tree_desc t[MAX_UNPACK_TREES];
> + struct tree *tree;
> + struct index_state dst_istate = INDEX_STATE_INIT(the_repository);
> + struct lock_file lock_file = LOCK_INIT;
> +
> + repo_read_index_preload(the_repository, NULL, 0);
> + if (refresh_index(the_repository->index, REFRESH_QUIET, NULL, NULL, NULL))
> + return -1;
Is this "non-zero return from refresh_index() leads to a failure"
intended? The old "git read-tree HEAD" wouldn't have cared if the
original index were unmerged, for example, but with this update, we
will see an immediate failure. There are other conditions that
refresh_index() flips its local variable has_errors on, which leads
to its non-zero return.
Since "git stash -p" is almost always invoked when the user has
unstaged modifications, I am not sure allowing refresh_index() to
notice and barf is what we want here.
^ permalink raw reply
* Re: [PATCH v6 0/8] fetch: rework negotiation tip options
From: Junio C Hamano @ 2026-05-20 2:34 UTC (permalink / raw)
To: Matthew John Cheetham
Cc: Derrick Stolee via GitGitGadget, git, ps, Derrick Stolee
In-Reply-To: <MRWPR03MB116167F956F0616EE71F527EEC0002@MRWPR03MB11616.eurprd03.prod.outlook.com>
Matthew John Cheetham <mjcheetham@outlook.com> writes:
> On 2026-05-19 17:24, Derrick Stolee via GitGitGadget wrote:
>
>> Updates in v6
>> =============
>>
>> Corrected reviewed-by annotations in commit messages.
>>
>> Thanks, -Stolee
>>
>
> v6 look good to me!
>
> Thanks,
> Matthew
Thanks.
^ permalink raw reply
* Re: What's cooking in git.git (May 2026, #04)
From: Junio C Hamano @ 2026-05-20 2:35 UTC (permalink / raw)
To: Jeff King; +Cc: Taylor Blau, git
In-Reply-To: <20260519191941.GB2269222@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, May 19, 2026 at 12:26:13PM -0400, Taylor Blau wrote:
>
>> > * tb/incremental-midx-part-3.3 (2026-04-29) 16 commits
>> [...]
>> Apologies, I didn't realize you were waiting on these until seeing this
>> WC report. I sent an extremely tiny reroll
>>
>> https://lore.kernel.org/git/cover.1779206239.git.me@ttaylorr.com/
>>
>> that addresses the two outstanding comments you linked. They are very
>> minor changes, and queueing either version of the series would be
>> equally fine IMHO.
>
> I peeked at the v4 range diff, and it looks good to me.
Thanks.
I went back to the list archive to check, because these "cf."
entries are not meant to be exhaustive and "I've addressed only
them" was a bad sign in general, but it seems that the latest round
is in very good shape.
Let's mark the topic for 'next'.
^ permalink raw reply
* Re: What's cooking in git.git (May 2026, #04)
From: Junio C Hamano @ 2026-05-20 2:37 UTC (permalink / raw)
To: Justin Tobler; +Cc: git
In-Reply-To: <agzGKQCfc7JYOyQx@denethor>
Justin Tobler <jltobler@gmail.com> writes:
> On 26/05/18 10:32AM, Junio C Hamano wrote:
>> * jt/odb-transaction-write (2026-05-14) 7 commits
>> - odb/transaction: make `write_object_stream()` pluggable
>> - object-file: generalize packfile writes to use odb_write_stream
>> - object-file: avoid fd seekback by checking object size upfront
>> - object-file: remove flags from transaction packfile writes
>> - odb: update `struct odb_write_stream` read() callback
>> - odb/transaction: use pluggable `begin_transaction()`
>> - odb: split `struct odb_transaction` into separate header
>> (this branch is used by ps/odb-in-memory.)
>>
>> ODB transaction interface is being reworked to explicitly handle
>> object writes.
>>
>> Will merge to 'next'?
>> source: <20260514183740.1505171-1-jltobler@gmail.com>
>
> I think this series should be ready to go now. The last version
> submitted fixed the leak reported by Peff.
Great. As there is another topic that builds on it, finally seeing
the topic stabilized enough is a great thing.
Let's merge it down to 'next'.
^ permalink raw reply
* Re: [PATCH v5 1/1] cat-file: add mailmap subcommand to --batch-command
From: Junio C Hamano @ 2026-05-20 3:26 UTC (permalink / raw)
To: Siddharth Asthana; +Cc: git, karthik.188, christian.couder, ps, toon, jn.avila
In-Reply-To: <20260416033250.4327-2-siddharthasthana31@gmail.com>
Siddharth Asthana <siddharthasthana31@gmail.com> writes:
> git-cat-file(1)'s --batch-command works with the --use-mailmap option,
> but this option needs to be set when the process is created. This means
> we cannot change this option mid-operation.
>
> At GitLab, Gitaly keeps interacting with a long-lived git-cat-file
> process and it would be useful if --batch-command supported toggling
> mailmap dynamically on an existing process.
>
> Add a `mailmap` subcommand to --batch-command that takes a boolean
> argument (usual ways you can specify a boolean value like 'yes', 'true',
> etc., are supported). Mailmap data is loaded lazily and kept in memory,
> while a helper centralizes the one-time load path used both at startup
> and from the batch-command handler.
>
> Extend tests to cover runtime toggling, startup option interactions
> (`--mailmap`/`--no-mailmap`), accepted boolean forms, and invalid values.
>
> Signed-off-by: Siddharth Asthana <siddharthasthana31@gmail.com>
> ---
> CI: https://gitlab.com/gitlab-org/git/-/pipelines/2456596910
I do not think we have heard any comment on this iteration, and it
seems to address the points raised in the reviews in previous
rounds. Shall we mark the topic for 'next'?
Thanks.
^ permalink raw reply
* Re: [PATCH v3 00/18] setup: drop uses of `the_repository`
From: Junio C Hamano @ 2026-05-20 3:31 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Karthik Nayak, Elijah Newren, Tian Yuchen
In-Reply-To: <20260519-pks-setup-wo-the-repository-v3-0-a00d8ea8b07f@pks.im>
Patrick Steinhardt <ps@pks.im> writes:
> Changes in v3:
> - Reverse the order of the commits that refactor `is_inside_gitdir()`
> and `is_inside_work_tree()` and clarify the logic around why we do
> (or do not) have to use realpath(3p). The code is ultimately not
> changed though, we still resolve the realpath for both even though
> it's not strictly necessary to do so for the working tree.
> - Link to v2: https://patch.msgid.link/20260518-pks-setup-wo-the-repository-v2-0-6933c0f1d568@pks.im
Looking good. Let me mark the topic for 'next'.
Thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox