* Re: .mailmap etiquette (was "Re: [PATCH 1/7] parse-options: introduce OPT_HIDDEN_GROUP")
From: Junio C Hamano @ 2026-07-16 22:31 UTC (permalink / raw)
To: D. Ben Knoble
Cc: Christian Couder, Git, Patrick Steinhardt, Elijah Newren,
Jeff King, brian m . carlson, Johannes Schindelin, Justin Tobler,
Christian Couder
In-Reply-To: <CALnO6CCauJhCmgKjV6QJ44cZD=2ah6=rJaV0+2ZMYTo7ycghEA@mail.gmail.com>
"D. Ben Knoble" <ben.knoble@gmail.com> writes:
> Speaking of .mailmap… if I were going to send future patches under a
> new email address, would you prefer
>
> (a) a series with the 1st commit being a .mailmap update (subsequent
> commits bearing the new email address, of course, but unrelated to the
> .mailmap update)
> (b) a one-patch email with a .mailmap update
> (c) the same as (b), but only after commits with the new email address
> have stabilized in next or master
I am not sure what sort of complexity you are anticipating, but
having you send (b) and me applying it directly to 'master'
would be the simplest approach, wouldn't it? After all, adding
a new entry to .mailmap does not invalidate your old identity;
it merely links the new one to the same person.
^ permalink raw reply
* .mailmap etiquette (was "Re: [PATCH 1/7] parse-options: introduce OPT_HIDDEN_GROUP")
From: D. Ben Knoble @ 2026-07-16 22:14 UTC (permalink / raw)
To: Junio C Hamano
Cc: Christian Couder, Git, Patrick Steinhardt, Elijah Newren,
Jeff King, brian m . carlson, Johannes Schindelin, Justin Tobler,
Christian Couder
In-Reply-To: <xmqqcxwmeiwq.fsf@gitster.g>
On Thu, Jul 16, 2026 at 5:17 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Christian Couder <christian.couder@gmail.com> writes:
>
> > Hidden options are not shown by `git <cmd> -h`, but are still shown by
> > `git <cmd> --help-all`. If there are a lot of hidden options or if they
> > don't belong to the same categories as other options, there is
> > currently no way to properly group them.
> >
> > Using `OPT_GROUP("Foo")` means that "Foo" will always be shown which we
> > don't want if that group contains only hidden options.
> >
> > To provide a way to have groups shown only when hidden options are
> > shown, let's implement an OPT_HIDDEN_GROUP macro.
> >
> > To test this new macro, let's also improve `test-tool parse-options`
> > and test its output with `--help-all`.
> >
> > Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
> > ---
>
> We have been doing this for quite some time, but I just noticed
> that the 'From' address your MUA uses ("Christian Couder
> <christian.couder@gmail.com>") does not match your Sign-off. Could
> you add an in-body 'From:' line if you plan to keep sending your
> patches from the Gmail address?
>
> I suppose nobody has noticed it so far because .mailmap hides the
> discrepancy once the commit lands.
>
> The changes in this step looks alright, though.
>
> Thanks.
Speaking of .mailmap… if I were going to send future patches under a
new email address, would you prefer
(a) a series with the 1st commit being a .mailmap update (subsequent
commits bearing the new email address, of course, but unrelated to the
.mailmap update)
(b) a one-patch email with a .mailmap update
(c) the same as (b), but only after commits with the new email address
have stabilized in next or master
?
[PS happy to drop anyone from CC who doesn't want this one; list
etiquette is a bit unclear to me on this kind of subject change,
though I would lean towards emptying CC and keeping only Junio…]
--
D. Ben Knoble
^ permalink raw reply
* Re: Please provide help with how to fix
From: D. Ben Knoble @ 2026-07-16 22:08 UTC (permalink / raw)
To: Randy Kroeger; +Cc: git@vger.kernel.org
In-Reply-To: <BY5PR06MB6548F18EA532E3EF021AA93DBAC72@BY5PR06MB6548.namprd06.prod.outlook.com>
On Thu, Jul 16, 2026 at 4:52 PM Randy Kroeger <kroegerr@cseasy.com> wrote:
>
>
> I am having a bit of an issue trying to figure out the best route in fixing the following.
The advice I give my colleagues:
1. Don't panic
2. Figure out where you are
3. Figure out where you want to go
4. Decide how to get there
> What happened is on my second machine, in which was out dated (source code), I upgraded to VS 2026 (from 2022), then tried to do a pull. What happened was that I received a bunch of modifications, which was confusing. All I want is to pull all changes since I did last on this machine. I then had a bit of a problem with the gitignore file, so I decided to just commit it (my train of thought is it is a file being committed to source control - that is it). However, what happened is this file took on a life and decided to make itself the head and bypass all changes to the head in which it knew about last. Please see image below where the history shows a line from this commit to the parent below. This by passes a bunch of chances.
A suite of helpful "where am I" commands:
- git status: is the repo clean? before we go further, let's not lose work
- git log --graph [--oneline]: what's the shape of commits? (this
would be useful to copy/paste, optionally with annotations, in place
of your diagram below)
- git reflog HEAD: what operations brought me here, and what are some
interesting recent checkouts?
Then (repeating a line from a previous quote):
> All I want is to pull all changes since I did last on this machine.
Once we know where you are, we can talk about where you want to go.
When you say "pull all changes," do you mean a "fetch" (update my
local repository's notions of where remote branches are) or a "pull"
(merge or rebase local branches with/on their upstreams)?
> Question: How can I fix this issue? I would like to restore all my changes again and remove this bypass. I have been reviewing your documentation, but am very hesitant as my understanding, once again, may not match how GIT actually functions.
Only when you know where you are and where you want to go can you find
appropriate fixes ;)
> I greatly appreciate the help!
>
> In this example, Commit 3 was done on July 12 and since it was on a machine that had done its last pull on 6/09/2026, the commit created a new parent below Commit 5. Now when I pull, the changes for Commit4, Commit5 are not included in the pull. I am assuming I need to do a rebase, but am not 100% confident and in reading the documentation, I am still not confident.
>
> --Commit6 7/14/2026
> --Commit5 7/13/2026
> |<-Commit4 7/12/2026 -child
> | --Commit2 6/11/2026
> | --Commit1 6/10/2026
> |>-Commit4 7/12/2026 -parent
>
> Randy
I'm not sure how to interpret this diagram; perhaps you could use "git
log --graph --oneline" to show your current and desired states?
--
D. Ben Knoble
^ permalink raw reply
* Re: [PATCH 7/7] fast-import: use struct option for usage string
From: Junio C Hamano @ 2026-07-16 21:35 UTC (permalink / raw)
To: Christian Couder
Cc: git, Patrick Steinhardt, Elijah Newren, Jeff King,
brian m . carlson, Johannes Schindelin, Justin Tobler,
Christian Couder
In-Reply-To: <20260716165517.433849-8-christian.couder@gmail.com>
Christian Couder <christian.couder@gmail.com> writes:
> + unsigned long pack_size_limit, big_file_threshold, depth, active_branches;
> + char *edges, *signed_commits, *signed_tags, *date_format, *import_marks;
> + char *import_marks_if_exists, *export_marks, *submodules_from, *submodules_to;
> + int opt_quiet, opt_show_stats, opt_relative_marks, opt_force, opt_done;
> + int opt_allow_unsafe;
> + int cat_blob;
>
> - fast_import_state_init(&state, argc, argv, prefix);
> + /*
> + * NEEDSWORK: For now this is used only to render
> + * `-h`/`--help-all` usage messages. The actual parsing is
> + * done by parse_one_option()/parse_one_feature().
> + */
OK, I am a bit torn on this. On one hand:
(1) I do agree that it would be nice to eventually have
fast_import_state_init() (or some other helper that groks
argc/argv) use this options array to parse the command line
arguments.
(2) I am sympathetic to the position that doing so is a bit
outside the scope of this series, whose focus is strictly on
"git fast-import -h" and nothing else.
(3) I suspect that when fast_import_state_init() does start using
the options array to initialize the state, the parsed results
will not be stored in the variables this caller currently holds,
but will instead live inside the fast_import_state structure.
So in that sense, the huge list of unused function-local variables
above are merely throw-away placeholders. When the real code is
written, they will disappear, and the references to them in the
fast_import_options[] array will have to be updated to point to
members of the structure (or global variables).
Still, seeing all of those variables left uninitialized leaves a
slightly sour taste. And because of (3), it would be a clear waste
of time to go through the motions of initializing these throw-away
locals.
Perhaps we would end up in a better position if we bent (2) a bit.
After all, my hesitation likely stems from the feeling that this
series stops short at a slightly awkward spot, having already
completed 90% of the journey.
For example, instead of inventing a local, throw-away
"pack_size_limit" variable, wouldn't it make more sense to refer to
the existing global "max_packsize" variable from the options[]
array below?
> + struct option fast_import_options[] = {
> + OPT_GROUP(N_("Common")),
> + OPT_STRING_F(0, "date-format", &date_format, N_("fmt"),
> + N_("format of the commit/tag dates"), PARSE_OPT_NONEG),
> + OPT_BOOL_F(0, "stats", &opt_show_stats,
> + N_("display some basic statistics (objects, packfiles and memory)"),
> + PARSE_OPT_NONEG),
> + OPT_BOOL_F(0, "quiet", &opt_quiet,
> + N_("disable the output shown by --stats"), PARSE_OPT_NONEG),
> + OPT_BOOL_F(0, "force", &opt_force,
> + N_("force updating modified existing branches"), PARSE_OPT_NONEG),
> + OPT_BOOL_F(0, "done", &opt_done,
> + N_("require a terminating 'done' command"), PARSE_OPT_NONEG),
> + OPT_UNSIGNED(0, "max-pack-size", &pack_size_limit,
> + N_("maximum size of each output pack file")),
> + OPT_UNSIGNED(0, "big-file-threshold", &big_file_threshold,
Thanks.
^ permalink raw reply
* Re: [PATCH 3/3] bisect: add --auto-reset to leave when done
From: Harald Nordgren @ 2026-07-16 21:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Harald Nordgren via GitGitGadget, git
In-Reply-To: <xmqqse5ihmsz.fsf@gitster.g>
> > Add an "--auto-reset" option, accepted by both "git bisect start" and
> > "git bisect run", that resets as soon as the first bad commit is found,
> > returning to the commit checked out before "git bisect start". The flag
> > is persisted in a BISECT_AUTO_RESET state file and the restoring
> > checkout is done quietly.
>
> I often find myself, after the culprit is found, running 'git
> reset --hard' or 'git bisect reset' to jump to the problematic
> commit to investigate further. If '--auto-reset' leaves me
> checked out on that bad commit, that would be a very welcome
> change.
No it's the opposite, returns to where we started before the bisection.
I don't mind changing it assuming no one likes the original idea. I
guess the name shouldn't be '--auto-reset' then.
Harald
^ permalink raw reply
* Re: [PATCH 1/7] parse-options: introduce OPT_HIDDEN_GROUP
From: Junio C Hamano @ 2026-07-16 21:14 UTC (permalink / raw)
To: Christian Couder
Cc: git, Patrick Steinhardt, Elijah Newren, Jeff King,
brian m . carlson, Johannes Schindelin, Justin Tobler,
Christian Couder
In-Reply-To: <20260716165517.433849-2-christian.couder@gmail.com>
Christian Couder <christian.couder@gmail.com> writes:
> Hidden options are not shown by `git <cmd> -h`, but are still shown by
> `git <cmd> --help-all`. If there are a lot of hidden options or if they
> don't belong to the same categories as other options, there is
> currently no way to properly group them.
>
> Using `OPT_GROUP("Foo")` means that "Foo" will always be shown which we
> don't want if that group contains only hidden options.
>
> To provide a way to have groups shown only when hidden options are
> shown, let's implement an OPT_HIDDEN_GROUP macro.
>
> To test this new macro, let's also improve `test-tool parse-options`
> and test its output with `--help-all`.
>
> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
> ---
We have been doing this for quite some time, but I just noticed
that the 'From' address your MUA uses ("Christian Couder
<christian.couder@gmail.com>") does not match your Sign-off. Could
you add an in-body 'From:' line if you plan to keep sending your
patches from the Gmail address?
I suppose nobody has noticed it so far because .mailmap hides the
discrepancy once the commit lands.
The changes in this step looks alright, though.
Thanks.
^ permalink raw reply
* Re: [RFC PATCH 1/7] builtin/repack.c: add --drop-filtered and --dry-run options
From: Junio C Hamano @ 2026-07-16 21:08 UTC (permalink / raw)
To: Siddharth Shrimali
Cc: git, christian.couder, siddharthasthana31, me, ps,
johannes.schindelin, l.s.r
In-Reply-To: <20260716132848.95982-2-r.siddharth.shrimali@gmail.com>
Siddharth Shrimali <r.siddharth.shrimali@gmail.com> writes:
> --drop-filtered is incompatible with bitmap writing: filtering breaks
> the "all objects in one pack" closure that bitmaps require. An explicit
> -b is rejected with a clear error and a default-on bitmap configuration is
> silently disabled for the duration of the command.
That is very well intentioned.
> @@ -231,6 +234,10 @@ int cmd_repack(int argc,
> N_("pack prefix to store a pack containing pruned objects")),
> OPT_STRING(0, "filter-to", &filter_to, N_("dir"),
> N_("pack prefix to store a pack containing filtered out objects")),
> + OPT_BOOL(0, "drop-filtered", &drop_filtered,
> + N_("delete filtered out objects (requires --filter)")),
> + OPT_BOOL(0, "dry-run", &dry_run,
> + N_("only show which objects would be dropped")),
> OPT_END()
> };
>
> @@ -252,6 +259,43 @@ int cmd_repack(int argc,
> po_args.depth = xstrdup_or_null(opt_depth);
> po_args.threads = xstrdup_or_null(opt_threads);
>
> + die_for_incompatible_opt2(drop_filtered, "--drop-filtered",
> + !!filter_to, "--filter-to");
> +
> + die_for_incompatible_opt2(drop_filtered, "--drop-filtered",
> + write_bitmaps > 0, "--write-bitmap-index");
Hmph. Since this step does not change the parsing or configuration
for write_bitmaps, we cannot tell if (write_bitmaps == 1) at this
point in the execution came from the command line (e.g., an earlier
call to parse_options() around line 247 of builtin/repack.c) or from
the configuration files (e.g., a call to repo_config() around
line 245). In other words, wouldn't it be ...
> + if (dry_run && !drop_filtered)
> + die(_("--dry-run only takes effect with --drop-filtered"));
> +
> + if (drop_filtered) {
> + if (!dry_run)
> + die(_("--drop-filtered doesn't work without --dry-run yet"));
> +
> + if (!po_args.filter_options.choice)
> + die(_("--drop-filtered requires --filter"));
> +
> + if (!(pack_everything & ALL_INTO_ONE))
> + die(_("--drop-filtered requires -a"));
> +
> + /*
> + * Only blob:limit=<n> is supported for now. Reject other
> + * filter choices early, before walking the object database.
> + */
> + if (po_args.filter_options.choice != LOFC_BLOB_LIMIT)
> + die(_("--drop-filtered only supports --filter=blob:limit=<n> for now"));
> +
> + /*
> + * Without a promisor remote there is nowhere to re-fetch the
> + * dropped objects from, so dropping them would be permanent
> + * data loss.
> + */
> + if (!repo_has_promisor_remote(repo))
> + die(_("--drop-filtered requires a promisor remote"));
> +
> + write_bitmaps = 0;
... way too late to drop the flag here?
> + }
> +
> if (delete_redundant && repo->repository_format_precious_objects)
> die(_("cannot delete packs in a precious-objects repo"));
^ permalink raw reply
* Re: [PATCH] stash: add 'rename' subcommand
From: brian m. carlson @ 2026-07-16 21:08 UTC (permalink / raw)
To: Junio C Hamano
Cc: Patrick Steinhardt, Emin Özata via GitGitGadget, git,
Greg Hewgill, Micheil Smith, Michael Haggerty,
Ævar Arnfjörð Bjarmason, Emin Özata
In-Reply-To: <xmqqh5lyhlp6.fsf@gitster.g>
[-- Attachment #1: Type: text/plain, Size: 1819 bytes --]
On 2026-07-16 at 17:46:13, Junio C Hamano wrote:
> Asking for the actual use case is indeed very useful, and I highly
> appreciate the nudge.
>
> "I cannot reword the message shown in 'git stash list' without this
> change" is not a use case. It would be far more useful to know
> what real-world task you are blocked from accomplishing just
> because you cannot reword a misspelled entry in 'git stash list'.
>
> Personally, I cannot think of any such roadblock. If I find that
> a stash entry is worth tweaking right now, I would probably
> create a new branch for the task, unstash it there, and either
> make further changes or record the exact state with an updated
> message to help my future self. After all, having a branch I
> can start working on immediately is far more useful than having
> the same stash entry with its spelling corrected.
I have a large number of stashes in my git.git repository (211 at
present) and it may be that I, in a mad rush to solve some problem or
another, went with the default message. I do this kind of thing with
repositories at work all the time. But it's inconvenient to have to
search through `git stash list -p` to see which change it was and which
stash I need to pop to resume my work, so I can see the utility of this
approach.
In my case, the stash is likely on an existing branch (such as my
sha256-interop branch), so I don't want to create another branch right
now, but I do want to distinguish a couple of different stashes.
Of course, I don't know what Emin's use case is, but I think it would in
fact be useful to have and I can see myself using it. If my use case is
valuable to others, anyone is free to summarize it in the commit message
as a justification.
--
brian m. carlson (they/them)
Toronto, Ontario, CA
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 325 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] refspec: stop depending on `the_repository`
From: Junio C Hamano @ 2026-07-16 20:59 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
In-Reply-To: <20260716-pks-refspec-wo-the-repository-v1-3-aa40844d067f@pks.im>
Patrick Steinhardt <ps@pks.im> writes:
> The only remaining user of `the_hash_algo` in "refspec.c" is
> `refspec_append()`, which needs to know the hash algorithm so that it
> can parse the appended refspec item. In contrast to the functions
> adapted in the preceding commit, this function always operates on a
> `struct refspec`. As that structure is expected to only ever contain
> refspecs that all use the same hash function it doesn't make sense
> though to adapt each caller.
>
> Instead, adapt the structure itself so that it gets initialized with a
> hash function and use that hash function to parse new refspec items.
> Adapt callers accordingly.
>
> This removes the final dependency on the global repository variable in
> "refspec.c", so we can drop `USE_THE_REPOSITORY_VARIABLE`.
While we lost some references to the_repository, we gained
more references to the_hash_algo in exchange. Because
the_hash_algo is defined in terms of the_repository->hash_algo,
it is only available when the_repository is still in use.
So these changes do not really help callers, and only leave
more for them to clean up later.
Which is probably fine. We have to start somewhere, and
refspec parsing is a fairly well-isolated corner of the
universe that serves as a good starting point.
Thanks.
^ permalink raw reply
* Please provide help with how to fix
From: Randy Kroeger @ 2026-07-16 20:52 UTC (permalink / raw)
To: git@vger.kernel.org
I am having a bit of an issue trying to figure out the best route in fixing the following. What happened is on my second machine, in which was out dated (source code), I upgraded to VS 2026 (from 2022), then tried to do a pull. What happened was that I received a bunch of modifications, which was confusing. All I want is to pull all changes since I did last on this machine. I then had a bit of a problem with the gitignore file, so I decided to just commit it (my train of thought is it is a file being committed to source control - that is it). However, what happened is this file took on a life and decided to make itself the head and bypass all changes to the head in which it knew about last. Please see image below where the history shows a line from this commit to the parent below. This by passes a bunch of chances.
Question: How can I fix this issue? I would like to restore all my changes again and remove this bypass. I have been reviewing your documentation, but am very hesitant as my understanding, once again, may not match how GIT actually functions.
I greatly appreciate the help!
In this example, Commit 3 was done on July 12 and since it was on a machine that had done its last pull on 6/09/2026, the commit created a new parent below Commit 5. Now when I pull, the changes for Commit4, Commit5 are not included in the pull. I am assuming I need to do a rebase, but am not 100% confident and in reading the documentation, I am still not confident.
--Commit6 7/14/2026
--Commit5 7/13/2026
|<-Commit4 7/12/2026 -child
| --Commit2 6/11/2026
| --Commit1 6/10/2026
|>-Commit4 7/12/2026 -parent
Randy
^ permalink raw reply
* Re: [PATCH 1/5] compat/posix: introduce writev(3p) wrapper
From: Junio C Hamano @ 2026-07-16 20:44 UTC (permalink / raw)
To: Simon Richter
Cc: Patrick Steinhardt, git, Ben Knoble, Jeff King, brian m. carlson,
Randall S. Becker, Phillip Wood, Johannes Schindelin
In-Reply-To: <xmqqfr1ig0hv.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
> Simon Richter <Simon.Richter@hogyros.de> writes:
>
>> Hi,
>>
>>> + if (iov[i].iov_len > maximum_signed_value_of_type(ssize_t) ||
>>> + iov[i].iov_len + sum > maximum_signed_value_of_type(ssize_t)) {
>>
>> That feels like it could overflow.
>
> Isn't it checking if it would overflow (and dying if so)?
>
> Ah, wait. The addition "(iov[i].iov_len + sum)" can indeed wrap
> around, and comparing it with the maximum value of ssize_t wouldn't
> catch that. Is that what you mean?
>
> Would something like this:
>
> if (maximum_signed_value_of_type(ssize_t) < iov[i].iov_len ||
> iov[i].iov_len + sum < iov[i].iov_len ||
> maximum_signed_value_of_type(ssize_t) < iov[i].iov_len + sum)
>
> work better to catch the three cases independently?
>
> (1) The value is already too large on its own.
> (2) Adding them together would cause an unsigned wrap-around.
> (3) The sum does not wrap around, but it exceeds the maximum
> representable value of ssize_t anyway.
Actually, looking at it again, I think the original code is safe
after all, because:
* "sum", even though it is a size_t, is checked inside the loop to
ensure it stays below the maximum value of ssize_t each time it
gets a new value.
* iov[i].iov_len is checked to ensure it does not exceed the
maximum value of ssize_t by the first part of the condition.
If both values are less than or equal to the maximum value of
ssize_t, their sum is at most twice that limit. For an N-bit
size_t, this sum is at most (2^N - 2), which can be computed safely
without any unsigned wrap-around.
So...?
^ permalink raw reply
* Re: [PATCH v6 4/4] environment: move has_symlinks into repo_config_values
From: Junio C Hamano @ 2026-07-16 20:27 UTC (permalink / raw)
To: Tian Yuchen
Cc: git, ps, Christian Couder, Ayush Chandekar, Olamide Caleb Bello
In-Reply-To: <20260716084941.1101918-5-cat@malon.dev>
Tian Yuchen <cat@malon.dev> writes:
> Move the global 'has_symlinks' configuration into the
> repository-specific 'repo_config_values' struct.
>
> To ensure code readability, the getter function
> 'repo_has_symlinks()' has been introduced. Callers access
> this configuration by passing in 'repo' when possible,
> and explicitly fall back to 'the_repository' the rest
> of the time.
>
> Note:
> To support platform-specific overrides (MinGW) before
> repository initialization, the 'platform_has_symlinks()'
> macro is introduced in git-compat-util.h. Platforms can
> override this in their respective headers.
This shouldn't be a mere "Note:" but should be treated as an
integral part of the implementation details.
Move the global variable 'has_symlinks' into the
'repo_config_values struct.
Introduce 'repo_has_symlinks()' getter for readability,
and 'platform_has_symlinks()' macro to allow platform
specific customization, primarily to help MinGW.
may be sufficient.
The changes to compat/ looked reasonable to me.
Thanks.
^ permalink raw reply
* Re: [PATCH v6 2/4] read-cache: move 'ce_mode_from_stat()' to 'read-cache.c'
From: Junio C Hamano @ 2026-07-16 20:20 UTC (permalink / raw)
To: Tian Yuchen
Cc: git, ps, Christian Couder, Ayush Chandekar, Olamide Caleb Bello
In-Reply-To: <20260716084941.1101918-3-cat@malon.dev>
Tian Yuchen <cat@malon.dev> writes:
> The ce_mode_from_stat() function is declared as a static inline function
> in 'read-cache.h'. As we want to migrate configuration variables, this
> helper function will need access to corresponding repository-specific
> configuration logic. Move the implementation to 'read-cache.c' to
> cleanly encapsulate its dependencies.
>
> Note that the 'extern int trust_executable_bit, has_symlinks;' line is
> discarded because it's not necessary when the function lives in
> "read-cache.c".
A "static inline" function in a header typically signals that
it is expected to be called from the depths of a performance-
critical loop. I am not sure if this helper is still in such
a hot path, but I wonder if we can keep it inline and still
teach it to take a "struct repository *r" (or whatever extra
parameter you need) to move these two bits from being global
variables to members of a per-repository structure.
^ permalink raw reply
* Re: [PATCH 1/5] compat/posix: introduce writev(3p) wrapper
From: Junio C Hamano @ 2026-07-16 20:09 UTC (permalink / raw)
To: Simon Richter
Cc: Patrick Steinhardt, git, Ben Knoble, Jeff King, brian m. carlson,
Randall S. Becker, Phillip Wood, Johannes Schindelin
In-Reply-To: <a2676ec6-39d5-4220-8549-10a17daec668@hogyros.de>
Simon Richter <Simon.Richter@hogyros.de> writes:
> Hi,
>
>> + if (iov[i].iov_len > maximum_signed_value_of_type(ssize_t) ||
>> + iov[i].iov_len + sum > maximum_signed_value_of_type(ssize_t)) {
>
> That feels like it could overflow.
Isn't it checking if it would overflow (and dying if so)?
Ah, wait. The addition "(iov[i].iov_len + sum)" can indeed wrap
around, and comparing it with the maximum value of ssize_t wouldn't
catch that. Is that what you mean?
Would something like this:
if (maximum_signed_value_of_type(ssize_t) < iov[i].iov_len ||
iov[i].iov_len + sum < iov[i].iov_len ||
maximum_signed_value_of_type(ssize_t) < iov[i].iov_len + sum)
work better to catch the three cases independently?
(1) The value is already too large on its own.
(2) Adding them together would cause an unsigned wrap-around.
(3) The sum does not wrap around, but it exceeds the maximum
representable value of ssize_t anyway.
^ permalink raw reply
* git submodule ignores sparse-checkout?
From: Brad Larson @ 2026-07-16 19:47 UTC (permalink / raw)
To: git
I feel like this is incorrect. Curious if others agree.
sparse-checkout is fantastic for working in a subset of a large
repository. But if that repository also happens to use git
submodules, the sparse checkout configuration is ignored during
submodule updates.
git 2.55.0, built from e9019fcafe00
Steps to reproduce (I chose rust - it has a lot of submodules) :
$ git clone --filter=blob:none --no-checkout
https://github.com/rust-lang/rust.git
$ cd rust
$ git sparse-checkout set src/doc
$ git checkout main
(notice how we only have src/doc populated)
$ git submodule update --init
(initializes repositories in library/ and src/tools)
I think it would make sense for git submodule to only interact with
the set of directories in the sparse checkout configuration. Would
the maintainers be open to a commit which improves this behavior?
Thank you,
Brad
^ permalink raw reply
* Re: [PATCH] revision: fix --no-walk path filtering regression
From: Peter Colberg @ 2026-07-16 19:35 UTC (permalink / raw)
To: Kristofer Karlsson; +Cc: git
In-Reply-To: <pull.2181.git.1784198879711.gitgitgadget@gmail.com>
Hi Kristofer,
On Thu, Jul 16, 2026 at 10:47:58AM +0000, Kristofer Karlsson via GitGitGadget wrote:
> From: Kristofer Karlsson <krka@spotify.com>
>
> Since dd4bc01c0a (revision: use priority queue for non-limited
> streaming walks, 2026-05-27), "git rev-list --no-walk <commit>
> -- <path>" ignores the path arguments and outputs all commits
> regardless of whether they touch the given paths.
>
> That commit introduced a REV_WALK_NO_WALK enum value to separate
> --no-walk from the streaming walk in get_revision_1(). The new
> case skips process_parents(), which is correct for not enqueuing
> parents, but also skips try_to_simplify_commit() which
> process_parents() calls to evaluate whether each commit touches
> the given paths.
>
> Add a call to try_to_simplify_commit() for the
> REV_WALK_NO_WALK case, folding it into the existing
> REV_WALK_REFLOG case which already does the same.
>
> Add tests for --no-walk path filtering to t6017. The
> "single commit, match" test is defensive and passes without
> the fix, while the other two fail without it.
>
> Reported-by: Peter Colberg <pcolberg@redhat.com>
> Signed-off-by: Kristofer Karlsson <krka@spotify.com>
Thank you very much for the fix, which passes as well for my use case.
Peter
> ---
> revision: fix --no-walk path filtering regression
>
> Fix for a regression reported by Peter Colberg [1] where git rev-list
> --no-walk <commit> -- <path> ignores path arguments since dd4bc01c0a.
>
> Verified against linux.git with the exact example from the report:
>
> git rev-list --topo-order v7.0..v7.1 -- drivers/gpu/drm/ |
> git rev-list --stdin --no-walk=unsorted -- ':!drivers/gpu/drm/'
>
>
> Without fix: 2026 commits (all pass through unfiltered) With fix: 146
> commits (correctly filtered)
>
> [1]
> https://lore.kernel.org/git/CAL71e4NjDTHbKR8z7pSrPpzDrX19JOTR04sArm7P=m5ivqkskA@mail.gmail.com/T/#u
>
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2181%2Fspkrka%2Fkk%2Fno-walk-pathspec-fix-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2181/spkrka/kk/no-walk-pathspec-fix-v1
> Pull-Request: https://github.com/gitgitgadget/git/pull/2181
>
> revision.c | 2 +-
> t/t6017-rev-list-stdin.sh | 18 ++++++++++++++++++
> 2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/revision.c b/revision.c
> index ccbe2e03d1..e990e3f96b 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -4419,6 +4419,7 @@ static struct commit *get_revision_1(struct rev_info *revs)
>
> switch (mode) {
> case REV_WALK_REFLOG:
> + case REV_WALK_NO_WALK:
> try_to_simplify_commit(revs, commit);
> break;
> case REV_WALK_TOPO:
> @@ -4432,7 +4433,6 @@ static struct commit *get_revision_1(struct rev_info *revs)
> oid_to_hex(&commit->object.oid));
> }
> break;
> - case REV_WALK_NO_WALK:
> case REV_WALK_LIMITED:
> break;
> }
> diff --git a/t/t6017-rev-list-stdin.sh b/t/t6017-rev-list-stdin.sh
> index 4821b90e74..32284f1831 100755
> --- a/t/t6017-rev-list-stdin.sh
> +++ b/t/t6017-rev-list-stdin.sh
> @@ -148,4 +148,22 @@ test_expect_success '--not via stdin does not influence revisions from command l
> test_cmp expect actual
> '
>
> +test_expect_success '--no-walk filters by path (single commit, match)' '
> + git rev-parse side-1 >expect &&
> + git rev-list --no-walk side-1 -- file-1 >actual &&
> + test_cmp expect actual
> +'
> +
> +test_expect_success '--no-walk filters by path (single commit, no match)' '
> + git rev-list --no-walk side-2 -- file-1 >actual &&
> + test_must_be_empty actual
> +'
> +
> +test_expect_success '--no-walk with pathspec exclusion' '
> + git rev-parse side-3 side-2 >expect &&
> + git rev-parse side-1 side-2 side-3 >input &&
> + git rev-list --stdin --no-walk -- ":!file-1" <input >actual &&
> + test_cmp expect actual
> +'
> +
> test_done
>
> base-commit: d35c5399e3e54ac277bb391fc2f6be3e816d312b
> --
> gitgitgadget
>
^ permalink raw reply
* Re: [GIT PULL] gitk: Bulgarian+Spanish translations, silent make -s
From: Harald Nordgren @ 2026-07-16 19:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <xmqqcxwmhlm2.fsf@gitster.g>
Thanks!
Do these changes eventually go into mainline Git under
`gitk-git/Makefile` or how does it work?
Harald
On Thu, Jul 16, 2026 at 7:48 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Johannes Sixt <j6t@kdbg.org> writes:
>
> > The following changes since commit bad83ada0ebf9e293d570e6e7ca4f1cd7877f482:
> >
> > Merge branch 'horizontal-scroll' of github.com:ramcdona/gitk (2026-06-12 11:30:22 +0200)
> >
> > are available in the Git repository at:
> >
> > https://github.com/j6t/gitk.git master
> >
> > for you to fetch changes up to f1de86371cb85dd09d55070d139e5fcdc595f026:
> >
> > Merge branch 'spanish_pr_bis' of github.com:basuradeluis/gitkbis (2026-07-16 10:53:01 +0200)
>
> Pulled, thanks.
>
> >
> > ----------------------------------------------------------------
> > Alexander Shopov (1):
> > gitk i18n: Update Bulgarian translation (329t)
> >
> > Harald Nordgren (1):
> > gitk: make "make -s" silent
> >
> > Johannes Sixt (2):
> > Merge branch 'master' of github.com:alshopov/gitk
> > Merge branch 'spanish_pr_bis' of github.com:basuradeluis/gitkbis
> >
> > basuradeluis (1):
> > gitk: spanish translations
> >
> > Makefile | 6 +-
> > po/bg.po | 45 ++++--
> > po/es.po | 488 +++++++++++++++++++++++++++++++++++++--------------------------
> > 3 files changed, 321 insertions(+), 218 deletions(-)
^ permalink raw reply
* Re: [PATCH 0/5] Reintroduce writev(3p)
From: Johannes Sixt @ 2026-07-16 18:56 UTC (permalink / raw)
To: Patrick Steinhardt
Cc: Ben Knoble, Junio C Hamano, Jeff King, brian m. carlson,
Randall S. Becker, Phillip Wood, Johannes Schindelin, git
In-Reply-To: <20260716-pks-reintroduce-writev-v1-0-ea9038c884bc@pks.im>
Am 16.07.26 um 09:52 schrieb Patrick Steinhardt:
> this patch series reintroduces the writev(3p) wrapper. This wrapper was
> originally introduced as part of Git 2.54 [1], but was ejected due to
> issues on NonStop [2].
Please don't call the function "writev" so that nobody associates it
with the guarantees that only POSIX provides, but none of the
emulations. Call it "write_gather", for example.
Also, clearly document that its only purpose is to reduce sequences of
write() calls to a single function call, but that the additional writev
guarantees are not needed.
A range-diff to the earlier round would have been very helpful.
-- Hannes
^ permalink raw reply
* [PATCH] wt-status: avoid quadratic insertion for untracked paths
From: Sahitya Chandra @ 2026-07-16 18:50 UTC (permalink / raw)
To: git; +Cc: gitster, avarab, stolee, peff, Sahitya Chandra
wt_status_collect_untracked() copies entries from dir.entries and
dir.ignored into string_lists using string_list_insert(). That keeps the
destination lists sorted and deduplicated, but each insertion may shift
the backing array, making construction O(n^2) in the number of paths.
Collect the entries with string_list_append() instead, then sort and
deduplicate each list once. This preserves the sorted, duplicate-free
result while reducing the construction cost to O(n log n).
Signed-off-by: Sahitya Chandra <sahityajb@gmail.com>
---
Notes for reviewers:
fill_directory() currently sorts dir.entries and dir.ignored
before returning, so another possible approach would be to append the
entries directly and rely on that order, reducing this copy step to O(n).
That would require relying on these arrays not containing duplicate
entries, though, which I have not been able to verify yet. This patch
takes the safer approach of preserving the existing duplicate-removal
behavior from `string_list_insert()` by sorting and deduplicating once
after appending.
wt-status.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 58461e02f8..13a7cf7946 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -832,14 +832,18 @@ static void wt_status_collect_untracked(struct wt_status *s)
for (i = 0; i < dir.nr; i++) {
struct dir_entry *ent = dir.entries[i];
if (index_name_is_other(istate, ent->name, ent->len))
- string_list_insert(&s->untracked, ent->name);
+ string_list_append(&s->untracked, ent->name);
}
+ string_list_sort(&s->untracked);
+ string_list_remove_duplicates(&s->untracked, 0);
for (i = 0; i < dir.ignored_nr; i++) {
struct dir_entry *ent = dir.ignored[i];
if (index_name_is_other(istate, ent->name, ent->len))
- string_list_insert(&s->ignored, ent->name);
+ string_list_append(&s->ignored, ent->name);
}
+ string_list_sort(&s->ignored);
+ string_list_remove_duplicates(&s->ignored, 0);
dir_clear(&dir);
base-commit: d35c5399e3e54ac277bb391fc2f6be3e816d312b
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 0/2] Some wincred fixes
From: Junio C Hamano @ 2026-07-16 18:34 UTC (permalink / raw)
To: Johannes Schindelin via GitGitGadget; +Cc: git, Johannes Schindelin
In-Reply-To: <pull.2182.git.1784212072.gitgitgadget@gmail.com>
"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:
> These were rolled out as part of the security fix release Git for Windows
> v2.55.0(3).
Thanks. Let me merge it down fast.
>
> Johannes Schindelin (2):
> wincred: avoid memory corruption when erasing a credential
> wincred: prevent silent credential loss when storing OAuth tokens
>
> contrib/credential/wincred/git-credential-wincred.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
>
> base-commit: 94f057755b7941b321fd11fec1b2e3ca5313a4e0
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2182%2Fdscho%2Fwincred-fixes-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2182/dscho/wincred-fixes-v1
> Pull-Request: https://github.com/gitgitgadget/git/pull/2182
^ permalink raw reply
* Re: [PATCH] revision: fix --no-walk path filtering regression
From: Junio C Hamano @ 2026-07-16 17:59 UTC (permalink / raw)
To: Kristofer Karlsson via GitGitGadget
Cc: git, Peter Colberg, Kristofer Karlsson
In-Reply-To: <pull.2181.git.1784198879711.gitgitgadget@gmail.com>
"Kristofer Karlsson via GitGitGadget" <gitgitgadget@gmail.com>
writes:
> From: Kristofer Karlsson <krka@spotify.com>
>
> Since dd4bc01c0a (revision: use priority queue for non-limited
> streaming walks, 2026-05-27), "git rev-list --no-walk <commit>
> -- <path>" ignores the path arguments and outputs all commits
> regardless of whether they touch the given paths.
>
> That commit introduced a REV_WALK_NO_WALK enum value to separate
> --no-walk from the streaming walk in get_revision_1(). The new
> case skips process_parents(), which is correct for not enqueuing
> parents, but also skips try_to_simplify_commit() which
> process_parents() calls to evaluate whether each commit touches
> the given paths.
>
> Add a call to try_to_simplify_commit() for the
> REV_WALK_NO_WALK case, folding it into the existing
> REV_WALK_REFLOG case which already does the same.
>
> Add tests for --no-walk path filtering to t6017. The
> "single commit, match" test is defensive and passes without
> the fix, while the other two fail without it.
>
> Reported-by: Peter Colberg <pcolberg@redhat.com>
> Signed-off-by: Kristofer Karlsson <krka@spotify.com>
> ---
> revision: fix --no-walk path filtering regression
>
> Fix for a regression reported by Peter Colberg [1] where git rev-list
> --no-walk <commit> -- <path> ignores path arguments since dd4bc01c0a.
>
> Verified against linux.git with the exact example from the report:
>
> git rev-list --topo-order v7.0..v7.1 -- drivers/gpu/drm/ |
> git rev-list --stdin --no-walk=unsorted -- ':!drivers/gpu/drm/'
>
>
> Without fix: 2026 commits (all pass through unfiltered) With fix: 146
> commits (correctly filtered)
>
> [1]
> https://lore.kernel.org/git/CAL71e4NjDTHbKR8z7pSrPpzDrX19JOTR04sArm7P=m5ivqkskA@mail.gmail.com/T/#u
OK. Without this fix, a commit that applied this patch (which does
not touch Makefile) shows the commit message in
$ git show HEAD -- Makefile
but with this fix, just like Git 2.54 did, the command stays silent.
Will queue. Thanks.
^ permalink raw reply
* Re: [GIT PULL] git-gui: larger commit msg field, Bulgarian translation, silent make -s
From: Junio C Hamano @ 2026-07-16 17:49 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <c177a717-28c3-41f7-95d7-45fec5b304bb@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> The following changes since commit 1b2c2a2edbaa1638becef4c3755b3e0633b9c304:
>
> Merge branch 'ml/repo-discovery' (2026-06-12 11:05:28 +0200)
>
> are available in the Git repository at:
>
> https://github.com/j6t/git-gui.git master
>
> for you to fetch changes up to 5dcb97869546d600a114ef422a135e2e909c923c:
>
> Merge branch 'master' of github.com:alshopov/git-gui (2026-07-16 11:05:03 +0200)
Thanks, pulled.
>
> ----------------------------------------------------------------
> Alexander Shopov (2):
> git-gui i18n: Update Bulgarian translation (562t)
> git-gui: allow larger width for the commit message field
>
> Harald Nordgren (1):
> git-gui: drop msgfmt --statistics output
>
> Johannes Sixt (4):
> Merge branch 'master' of github.com:alshopov/git-gui
> git-gui: reduce complexity of the quiet msgfmt rule
> Merge branch 'hn/silence-make-s'
> Merge branch 'master' of github.com:alshopov/git-gui
>
> Makefile | 5 ++---
> lib/option.tcl | 2 +-
> po/bg.po | 37 ++++++++++++++++++++++++++-----------
> 3 files changed, 29 insertions(+), 15 deletions(-)
^ permalink raw reply
* Re: [GIT PULL] gitk: Bulgarian+Spanish translations, silent make -s
From: Junio C Hamano @ 2026-07-16 17:48 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List, Harald Nordgren
In-Reply-To: <fdef432d-0b84-4b58-9915-83eb4d7dae87@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> The following changes since commit bad83ada0ebf9e293d570e6e7ca4f1cd7877f482:
>
> Merge branch 'horizontal-scroll' of github.com:ramcdona/gitk (2026-06-12 11:30:22 +0200)
>
> are available in the Git repository at:
>
> https://github.com/j6t/gitk.git master
>
> for you to fetch changes up to f1de86371cb85dd09d55070d139e5fcdc595f026:
>
> Merge branch 'spanish_pr_bis' of github.com:basuradeluis/gitkbis (2026-07-16 10:53:01 +0200)
Pulled, thanks.
>
> ----------------------------------------------------------------
> Alexander Shopov (1):
> gitk i18n: Update Bulgarian translation (329t)
>
> Harald Nordgren (1):
> gitk: make "make -s" silent
>
> Johannes Sixt (2):
> Merge branch 'master' of github.com:alshopov/gitk
> Merge branch 'spanish_pr_bis' of github.com:basuradeluis/gitkbis
>
> basuradeluis (1):
> gitk: spanish translations
>
> Makefile | 6 +-
> po/bg.po | 45 ++++--
> po/es.po | 488 +++++++++++++++++++++++++++++++++++++--------------------------
> 3 files changed, 321 insertions(+), 218 deletions(-)
^ permalink raw reply
* Re: [PATCH] stash: add 'rename' subcommand
From: Junio C Hamano @ 2026-07-16 17:46 UTC (permalink / raw)
To: Patrick Steinhardt
Cc: Emin Özata via GitGitGadget, git, Greg Hewgill,
Micheil Smith, Michael Haggerty,
Ævar Arnfjörð Bjarmason, Emin Özata
In-Reply-To: <alitkCsplW_DIaRw@pks.im>
Patrick Steinhardt <ps@pks.im> writes:
> Hm. It's good to refer to to previous discussions. But I think it would
> make sense to also document why explicitly _you_ want to have this
> functionality. Like, what use case does it enable that you currently
> cannot have right now? How is this different to what was proposed back
> then that should make us reconsider whether or not to include it now?
We have one previous discussion thread on this, and there is no
need to refer to every single message in it. Just pointing to
the discussion starter should be enough to let us read what was
said. It was also very nice of Emin to summarize the viewpoints
expressed there, so that readers can follow along without having to
dig up external resources.
Asking for the actual use case is indeed very useful, and I highly
appreciate the nudge.
"I cannot reword the message shown in 'git stash list' without this
change" is not a use case. It would be far more useful to know
what real-world task you are blocked from accomplishing just
because you cannot reword a misspelled entry in 'git stash list'.
Personally, I cannot think of any such roadblock. If I find that
a stash entry is worth tweaking right now, I would probably
create a new branch for the task, unstash it there, and either
make further changes or record the exact state with an updated
message to help my future self. After all, having a branch I
can start working on immediately is far more useful than having
the same stash entry with its spelling corrected.
Thanks.
^ permalink raw reply
* Re: [PATCH v5 0/9] [RFC] diff: add diff.<driver>.process for external hunk providers
From: Michael Montalbo @ 2026-07-16 17:31 UTC (permalink / raw)
To: Junio C Hamano
Cc: Michael Montalbo via GitGitGadget, git, Johannes Schindelin
In-Reply-To: <xmqq8q7aj3b0.fsf@gitster.g>
On Thu, Jul 16, 2026 at 9:40 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> "Michael Montalbo via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > A "Which features consult the diff process" section in gitattributes(5) lays
> > out, per feature, why each does or does not consult the process (patch
> > output, blame, summary formats, and the -L line-range view do; pickaxe -G,
> > patch-id, merge, range-diff, --check, and --raw do not, with reasons).
> > Combined diffs (--cc) remain on the builtin algorithm and are noted as
> > future work.
> >
> > Changes since v4:
>
> This round does not play well with the mm/line-log-limited-ops
> topic, unfortunately, it seems.
Ah, thanks for the heads up and apologies for the hiccup. I will
rebase this series on top of mm/line-log-limited-ops and make
sure the two topics function together correctly.
^ 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