* Re: What's cooking in git.git (Nov 2024, #07; Wed, 20)
@ 2024-11-21 0:44 99% ` Junio C Hamano
2024-11-22 4:34 99% ` Junio C Hamano
1 sibling, 0 replies; 200+ results
From: Junio C Hamano @ 2024-11-21 0:44 UTC (permalink / raw)
To: Taylor Blau; +Cc: git
Taylor Blau <me@ttaylorr.com> writes:
> On Wed, Nov 20, 2024 at 05:49:34PM +0900, Junio C Hamano wrote:
>> * tb/incremental-midx-part-2 (2024-11-20) 15 commits
>> - midx: implement writing incremental MIDX bitmaps
>> - pack-bitmap.c: use `ewah_or_iterator` for type bitmap iterators
>> - pack-bitmap.c: keep track of each layer's type bitmaps
>> - ewah: implement `struct ewah_or_iterator`
>> - pack-bitmap.c: apply pseudo-merge commits with incremental MIDXs
>> - pack-bitmap.c: compute disk-usage with incremental MIDXs
>> - pack-bitmap.c: teach `rev-list --test-bitmap` about incremental MIDXs
>> - pack-bitmap.c: support bitmap pack-reuse with incremental MIDXs
>> - pack-bitmap.c: teach `show_objects_for_type()` about incremental MIDXs
>> - pack-bitmap.c: teach `bitmap_for_commit()` about incremental MIDXs
>> - pack-bitmap.c: open and store incremental bitmap layers
>> - pack-revindex: prepare for incremental MIDX bitmaps
>> - Documentation: describe incremental MIDX bitmaps
>> - Merge branch 'tb/pseudo-merge-bitmap-fixes' into tb/incremental-midx-part-2
>> - Merge branch 'tb/incremental-midx-part-1' into tb/incremental-midx-part-2
>>
>> Incrementally updating multi-pack index files.
>>
>> Needs review.
>> source: <cover.1732054032.git.me@ttaylorr.com>
>
> Sorry for not making clearer that I had changed the base to current
> 'master' for this topic, so these two merges should no longer be
> necessary.
Yeah, I know (see my other message on the topic). I just didn't see
a reason to rebase and keeping the same base is slighly easier to
compare the two iterations, with and without range-diff.
> One topic I did not see is [1], which appeared not to be picked up in
> this or the last cycle. That topic has been reviewed and should be in
> good shape. I think the thread died down after agreeing on some
> potentially interesting future improvements we could make, but I don't
> think there were any outstanding issues with the current patches.
> ...
> [1]: https://lore.kernel.org/git/cover.1730833506.git.me@ttaylorr.com/
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Nov 2024, #07; Wed, 20)
@ 2024-11-21 1:10 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-11-21 1:10 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Christian Couder, shejialuo, Derrick Stolee
Patrick Steinhardt <ps@pks.im> writes:
> On Wed, Nov 20, 2024 at 05:49:34PM +0900, Junio C Hamano wrote:
>> * ps/gc-stale-lock-warning (2024-11-20) 1 commit
> ...
> I'm never quite sure whether I should speak of the command or the code
> unit in this edge case, but this message here seems to indicate that it
> would be preferable to mention the actual command instead.
Either is probably fine, but when the commit describes a fix or an
update to an end-user observable behaviour, the command name would
make a better label to appear in "git shortlog".
>> * ps/send-pack-unhide-error-in-atomic-push (2024-11-15) 6 commits
> ...
> I'll review this patch series later this week.
Thanks.
>> * ps/leakfixes-part-10 (2024-11-13) 28 commits
>> ...
>> Will merge to 'next'?
>> source: <20241111-b4-pks-leak-fixes-pt10-v2-0-6154bf91f0b0@pks.im>
>
> Toon left another comment that I'll want to have a look at before
> merging this to "next".
I guess we now have a hopefully final reroll, which I saw and picked
up.
>> * ds/path-walk-1 (2024-11-11) 6 commits
>> - path-walk: mark trees and blobs as UNINTERESTING
>> - path-walk: visit tags and cached objects
>> - path-walk: allow consumer to specify object types
>> - t6601: add helper for testing path-walk API
>> - test-lib-functions: add test_cmp_sorted
>> - path-walk: introduce an object walk by path
>>
>> Introduce a new API to visit objects in batches based on a common
>> path, or by type.
>>
>> Comments?
>> source: <pull.1818.v2.git.1731181272.gitgitgadget@gmail.com>
>
> I think what's interesting in this case is the incompatibility between
> the path-walk API and bitmaps. It seems like there is some push back
> based on this, but from my point of view the path-walk API still has
> uses where bitmaps don't matter that much, like in the proposed new
> git-backfill and git-survey tools. Both of which are of interest to me.
Yup, I didn't have a chance to carefully read what the new code does
yet, and didn't get an impression that anybody did either for v1 or
v2, but I may be mistaken.
>> * cc/promisor-remote-capability (2024-09-10) 4 commits
> ...
> Chris is currently writing such a doc that tries to clarify the bigger
> picture. So I guess we can evict this topic for now, start to discuss
> the vision and then once we're all on the same page start to think
> re-submit the topic.
>
> I've Cc'd him in case he disagrees with me.
Then I'll wait for Christian to speak up.
>> * sj/ref-contents-check (2024-11-15) 9 commits
>> ...
> I've already reviewed this version and expect a (probably final) reroll.
Thanks, I saw that (hopefully) final reroll and picked it up.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Nov 2024, #07; Wed, 20)
@ 2024-11-21 12:59 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-11-21 12:59 UTC (permalink / raw)
To: Kristoffer Haugsbakk; +Cc: git
"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:
> What should be done about what one might call a
> trailer topic version for simple topics that might get included in `next` soon
> after being proposed?
Sorry, but I do not understand what you are asking here. Can you
elaborate?
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Nov 2024, #07; Wed, 20)
2024-11-21 0:44 99% ` Junio C Hamano
@ 2024-11-22 4:34 99% ` Junio C Hamano
1 sibling, 0 replies; 200+ results
From: Junio C Hamano @ 2024-11-22 4:34 UTC (permalink / raw)
To: Taylor Blau; +Cc: git
Taylor Blau <me@ttaylorr.com> writes:
> One topic I did not see is [1], which appeared not to be picked up in
> this or the last cycle. That topic has been reviewed and should be in
> good shape. I think the thread died down after agreeing on some
> potentially interesting future improvements we could make, but I don't
> think there were any outstanding issues with the current patches.
I didn't get the impression that there was a general concensus that
it was a good implementation, but perhaps I am misremembering things.
These two patches touch only the test helpers, but I am wondering if
it becomes easier to implement on top of your later changes that
allows the production side to also access the unsafe variant of the
algorithm?
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Nov 2024, #08; Fri, 22)
@ 2024-11-25 0:23 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-11-25 0:23 UTC (permalink / raw)
To: Philippe Blain; +Cc: git
Philippe Blain <levraiphilippeblain@gmail.com> writes:
> Hi Junio,
>
> Le 2024-11-22 à 05:11, Junio C Hamano a écrit :
>
>>
>> * pb/mergetool-errors (2024-11-13) 5 commits
>> - git-difftool--helper.sh: exit upon initialize_merge_tool errors
>> - git-mergetool--lib.sh: add error message for unknown tool variant
>> - git-mergetool--lib.sh: add error message in 'setup_user_tool'
>> - git-mergetool--lib.sh: use TOOL_MODE when erroring about unknown tool
>> - completion: complete '--tool-help' in 'git mergetool'
>>
>> End-user experience of "git mergetool" when the command errors out
>> has been improved.
>>
>> Will merge to 'next'?
>> source: <pull.1827.git.1731459128.gitgitgadget@gmail.com>
>
> I'll send a v2 with some enhancements you suggested, so maybe wait a bit.
Thanks, will do.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Nov 2024, #08; Fri, 22)
@ 2024-11-25 0:25 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-11-25 0:25 UTC (permalink / raw)
To: Caleb White; +Cc: git, Phillip Wood
Caleb White <cdwhite3@pm.me> writes:
> This latest round has been reviewed by Philip (cc'd) and I've addressed
> his comments (mainly in regards to using test functions I was unaware
> of). I was waiting for more comments before rerolling but if I don't
> hear anything in the next few days I'll go ahead and do that.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Nov 2024, #09; Mon, 25)
@ 2024-11-28 1:57 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-11-28 1:57 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, brian m. carlson
Patrick Steinhardt <ps@pks.im> writes:
> On Mon, Nov 25, 2024 at 05:07:59PM +0900, Junio C Hamano wrote:
>> * bc/ancient-ci (2024-11-01) 3 commits
>> - Add additional CI jobs to avoid accidental breakage
>> - ci: remove clause for Ubuntu 16.04
>> - gitlab-ci: switch from Ubuntu 16.04 to 20.04
>>
>> Drop support for ancient environments in various CI jobs.
>>
>> Needs review.
>> source: <20241031234934.3451390-1-sandals@crustytoothpaste.net>
>
> I've reviewed these changes in <ZyixnuBY5TcyrHEj@pks.im>, even though I
> don't feel a 100% qualified to comment on the GitHub changes. But given
> that bc/drop-ancient-libcurl-and-perl has been merged to `next` by now
> it would be nice if the above series could be merged soonish, as well,
> so that the GitLab CI is getting fixed.
Yeah, I think we saw on 'seen' what these changes do enough (at
least, it doesn't seem to break everything ;-). Let's mark it for
'next'.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Nov 2024, #10; Thu, 28)
@ 2024-12-02 0:39 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-12-02 0:39 UTC (permalink / raw)
To: Phillip Wood; +Cc: git, Caleb White
Phillip Wood <phillip.wood123@gmail.com> writes:
> Hi Junio
>
> On 28/11/2024 05:35, Junio C Hamano wrote:
>> * cw/worktree-extension (2024-11-26) 8 commits
>> - worktree: refactor `repair_worktree_after_gitdir_move()`
>> - worktree: add relative cli/config options to `repair` command
>> - worktree: add relative cli/config options to `move` command
>> - worktree: add relative cli/config options to `add` command
>> - worktree: add `write_worktree_linking_files()` function
>> - worktree: refactor infer_backlink return
>> - worktree: add `relativeWorktrees` extension
>> - setup: correctly reinitialize repository version
>> Introduce a new repository extension to prevent older Git versions
>> from mis-interpreting worktrees created with relative paths.
>> Will merge to 'next'?
>> source: <20241125-wt_relative_options-v5-0-356d122ff3db@pm.me>
>
> I've had a look at the range-diff for the latest version and had a
> query about the removal of a check from one of the tests[1]. Perhaps
> we should wait to hear from Caleb about that, but if you're keen to
> get these merged down in time for the next release we could just fix
> up the test later if it turns out to be necessary - I think the code
> changes are all fine.
Thanks for reviewing (and thanks Caleb for working on) this topic.
I see the latest iteration v6 has added back the extension checking,
so we probably are good to go.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Nov 2024, #10; Thu, 28)
@ 2024-12-02 0:48 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-12-02 0:48 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
Patrick Steinhardt <ps@pks.im> writes:
>> * ps/reftable-detach (2024-11-19) 8 commits
>> ...
>> Needs review.
>> source: <cover.1731943954.git.ps@pks.im>
>
> ... it depends on this series here. From my point of view it is ready,
> as well, and has gotten a favorable review by Karthik. So I wouldn't
> mind if we merged both series to `next` together.
Indeed this has seen careful reviews. I should have updated the
status described here much earlier.
>> * ps/build (2024-11-26) 24 commits
>> ...
>> Will merge to 'next'?
>> source: <20241125-pks-meson-v9-0-1c6cf242a5f1@pks.im>
>
> I've got two small fixes pending, but other than I think the series is
> in a good enough shape for a first iteration. There's of coure a couple
> of follow-up steps that I plan to do, like wiring up CI, but I think
> it's fine to do these in a separate series.
>
> I'll send this version out in a bit. If you decide to merge, please
> note that the tip of the branch is only for compatibility with "seen"
> and should not be merged to "next".
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Nov 2024, #10; Thu, 28)
@ 2024-12-02 2:48 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-12-02 2:48 UTC (permalink / raw)
To: Caleb White; +Cc: git
Caleb White <cdwhite3@pm.me> writes:
> On Wed Nov 27, 2024 at 11:35 PM CST, Junio C Hamano wrote:
>> * cw/worktree-extension (2024-11-26) 8 commits
>> - worktree: refactor `repair_worktree_after_gitdir_move()`
>> - worktree: add relative cli/config options to `repair` command
>> - worktree: add relative cli/config options to `move` command
>> - worktree: add relative cli/config options to `add` command
>> - worktree: add `write_worktree_linking_files()` function
>> - worktree: refactor infer_backlink return
>> - worktree: add `relativeWorktrees` extension
>> - setup: correctly reinitialize repository version
>>
>> Introduce a new repository extension to prevent older Git versions
>> from mis-interpreting worktrees created with relative paths.
>>
>> Will merge to 'next'?
>> source: <20241125-wt_relative_options-v5-0-356d122ff3db@pm.me>
>
> There is one test that I've updated (added a check that was accidentally
> removed). I can send that as a reroll if you'd like, otherwise I think
> this is ready to go.
Yup, v6 looks good. Will queue. Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Dec 2024, #01; Tue, 3)
@ 2024-12-03 23:09 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-12-03 23:09 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Karthik Nayak, Justin Tobler
Patrick Steinhardt <ps@pks.im> writes:
>> * ps/send-pack-unhide-error-in-atomic-push (2024-11-15) 6 commits
>> - push: not send push-options to server with --dry-run
>> - push: only ignore finish_connect() for dry-run mode
>> - t5543: atomic push reports exit code failure
>> - t5504: modernize test by moving heredocs into test bodies
>> - push: fix the behavior of the Done message for porcelain
>> - t5548: new test cases for push --porcelain and --dry-run
>>
>> "git push --atomic --porcelain" used to ignore failures from the
>> other side, losing the error status from the child process, which
>> has been corrected.
>>
>> Probably needs a redesign.
>> cf. <Z0Q0wfSTk_cUXH0F@pks.im>
>> source: <cover.1731603991.git.zhiyou.jx@alibaba-inc.com>
>
> I wonder whether we want to roll with the first version that I have sent
> instead of using v2 from Jiang.
That's a thought. Let's go back to the series and take a look.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Dec 2024, #03; Sun, 8)
@ 2024-12-09 23:53 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-12-09 23:53 UTC (permalink / raw)
To: Jonathan Tan; +Cc: git
Jonathan Tan <jonathantanmy@google.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>> * jt/fix-fattening-promisor-fetch (2024-12-04) 4 commits
>> - index-pack: work around false positive use of uninitialized variable
>> - index-pack --promisor: also check commits' trees
>> - index-pack --promisor: don't check blobs
>> - index-pack --promisor: dedup before checking links
>>
>> Fix performance regression of a recent "fatten promisor pack with
>> local objects" protection against an unwanted gc.
>>
>> Need to squash the fix-up at the tip.
>> source: <cover.1733262661.git.jonathantanmy@google.com>
>
> I just replied [1] to what I believe is the last outstanding question,
> so I don't think there is any code change needed besides the squashing
> of the fix-up (as you said). If you could squash it locally (onto
> "index-pack --promisor: dedup before checking links") that would be
> great; if not let me know and I'll send an updated version.
Thanks, will (try to remember to) do ;-)
There is nothing in the code that needs to be fixed, but we help
compilers so that they can help us. Let's merge it down to 'next'
after squashing it in.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Dec 2024, #05; Thu, 12)
@ 2024-12-13 14:33 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-12-13 14:33 UTC (permalink / raw)
To: karthik nayak; +Cc: git
karthik nayak <karthik.188@gmail.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
> [snip]
>
>> * kn/reftable-writer-log-write-verify (2024-12-07) 1 commit
>> - reftable/writer: ensure valid range for log's update_index
>>
>> source: <20241206-424-reftable-writer-add-check-for-limits-v2-1-82ca350b10be@gmail.com>
>>
>
> Hey Junio, this was reviewed by Patrick and Toon. I see this was added
> to 'seen'. Is it also scheduled for 'next'?
If it does not say "Will do X", it is not scheduled for that.
This applies to everybody, not specifically to you, but when you see
an empty entry like the above in the "What's cooking" report, three
things you can do are:
(1) offer a few lines of topic summary
(2) point at the review message(s)
(3) suggest for updated status with rationale (e.g. "let's move
this to 'next' by day X, as this and that reviews at URL1 and
URL2 seem to indicate that we have a concensus that it is ready".
Patrick's comments were on the previous one, IIRC, but I do see Toon
commented on the latest round.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Dec 2024, #05; Thu, 12)
@ 2024-12-13 14:48 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-12-13 14:48 UTC (permalink / raw)
To: Christian Couder; +Cc: git
Christian Couder <christian.couder@gmail.com> writes:
> A few typo fix suggestions:
Thanks. Very much appreciated.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Dec 2024, #05; Thu, 12)
@ 2024-12-16 16:26 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-12-16 16:26 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
Patrick Steinhardt <ps@pks.im> writes:
> On Thu, Dec 12, 2024 at 09:31:06PM +0900, Junio C Hamano wrote:
>> * ps/build-sign-compare (2024-12-06) 16 commits
>> - t/helper: don't depend on implicit wraparound
>> - scalar: address -Wsign-compare warnings
>> - builtin/patch-id: fix type of `get_one_patchid()`
>> - builtin/blame: fix type of `length` variable when emitting object ID
>> - gpg-interface: address -Wsign-comparison warnings
>> - daemon: fix type of `max_connections`
>> - daemon: fix loops that have mismatching integer types
>> - global: trivial conversions to fix `-Wsign-compare` warnings
>> - pkt-line: fix -Wsign-compare warning on 32 bit platform
>> - csum-file: fix -Wsign-compare warning on 32-bit platform
>> - diff.h: fix index used to loop through unsigned integer
>> - config.mak.dev: drop `-Wno-sign-compare`
>> - global: mark code units that generate warnings with `-Wsign-compare`
>> - compat/win32: fix -Wsign-compare warning in "wWinMain()"
>> - compat/regex: explicitly ignore "-Wsign-compare" warnings
>> - git-compat-util: introduce macros to disable "-Wsign-compare" warnings
>>
>> Start working to make the codebase buildable with -Wsign-compare.
>>
>> Will merge to 'next'?
>> source: <20241206-pks-sign-compare-v4-0-0344c6dfb219@pks.im>
>
> I think this series should be ready to go, yes.
OK, let me mark it for 'next', then. BTW, I found
https://staticthinking.wordpress.com/2023/07/25/wsign-compare-is-garbage/
amusing ;-).
>> * ps/send-pack-unhide-error-in-atomic-push (2024-11-14) 2 commits
>> - transport: don't ignore git-receive-pack(1) exit code on atomic push
>> - t5504: modernize test by moving heredocs into test bodies
>>
>> "git push --atomic --porcelain" used to ignore failures from the
>> other side, losing the error status from the child process, which
>> has been corrected.
>>
>> Needs review.
>> source: <20241113-pks-push-atomic-respect-exit-code-v1-0-7965f01e7f4e@pks.im>
>
> There was a newer version of this series again sent by Jiang Xin. I'll
> try to have a look today.
Thanks. I do not particularly like "competing" parallel topics that
do not talk much with each other, so I wanted to take a look at the
other one, too, to see why these two are not good enough.
>> * ds/path-walk-1 (2024-12-07) 7 commits
>> - path-walk: reorder object visits
>> - path-walk: mark trees and blobs as UNINTERESTING
>> - path-walk: visit tags and cached objects
>> - path-walk: allow consumer to specify object types
>> - t6601: add helper for testing path-walk API
>> - test-lib-functions: add test_cmp_sorted
>> - path-walk: introduce an object walk by path
>> (this branch is used by ds/backfill.)
>>
>> Introduce a new API to visit objects in batches based on a common
>> path, or by type.
>>
>> Will merge to 'next'?
>> source: <pull.1818.v3.git.1733514358.gitgitgadget@gmail.com>
>
> I was a bit late to the party, but have sent a couple of review comments
> to the mailing list late last week that Derrick may want to address.
Yup, I saw your comments. Let's hear what Derrick says.
>> * as/show-index-uninitialized-hash (2024-11-11) 2 commits
>> - t5300: add test for 'show-index --object-format'
>> - show-index: fix uninitialized hash function
>>
>> Regression fix for 'show-index' when run outside of a repository.
>>
>> Comments?
>> source: <20241109092739.14276-1-abhijeet.nkt@gmail.com>
>
> I've just had a look at it, looks good to me.
Thanks. This was fairly straight-forward and looked good to me,
too. Marked for 'next'.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Dec 2024, #08; Mon, 23)
@ 2024-12-26 16:05 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-12-26 16:05 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
Johannes Sixt <j6t@kdbg.org> writes:
> Am 23.12.24 um 20:27 schrieb Junio C Hamano:
>> Let's wait for git-gui, gitk, and possibly po/ and delay the tagging
>> of the -rc1.
>
> I've just sent a pull request for Git GUI to make the current master
> better visible for translators. Gitk is already up-to-date.
>
> I'll wait a week or so for translations to trickle in and then send
> another round of pull requests. Is this a practical workflow?
Yeah, it is that really slow part of the year now, so it would not
make much sense to have rc releases without much changes in them.
Let's have -rc1 on Monday, -rc2 after a week, and the final later on
the same week.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Dec 2024, #10; Sat, 28)
@ 2024-12-30 14:07 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-12-30 14:07 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
Patrick Steinhardt <ps@pks.im> writes:
> On Sat, Dec 28, 2024 at 02:23:56PM -0800, Junio C Hamano wrote:
>> * ps/more-sign-compare (2024-12-27) 10 commits
> ...
> There wasn't anything yet that needs addressing, unless I have missed
> something. Peff acked a couple of patches, and the questions from Jialuo
> have been addressed. So no rerolled is planney (yet).
OK. Let's merge and cook in 'next' then.
>> * sk/maintenance-remote-prune (2024-12-28) 1 commit
>> - maintenance: add prune-remote-refs task
>>
>> A new periodic maintenance task to run "git remote prune" has been
>> introduced.
>>
>> Will merge to 'next'?
>> source: <pull.1838.v2.git.1735380461980.gitgitgadget@gmail.com>
>
> I've had another look at this series just now.
Thanks for a review. Let's wait for a review response and go from
there.
>> --------------------------------------------------
>> [Cooking]
>>
>> * rs/reftable-realloc-errors (2024-12-28) 4 commits
>> - t-reftable-merged: handle realloc errors
>> - reftable: handle realloc error in parse_names()
>> - reftable: fix allocation count on realloc error
>> - reftable: avoid leaks on realloc error
>>
>> The custom allocator code in the reftable library did not handle
>> failing realloc() very well, which has been addressed.
>>
>> Will merge to 'next'?
>> source: <f4677194-0a3a-4f07-b003-c0295b51c100@web.de>
>
> I'm not a 100% happy with the split for reallocators that this series
> introduces, but don't think that the series is to blame because it
> simply fixes the underlying problem. So this is a good first iteration
> and we can improve the status quo in a follow-up.
>
> So yes, I think this can be merged.
OK. Again, thanks for a review.
^ permalink raw reply [relevance 99%]
* Re: a less-invasive racy-leak fix, was Re: What's cooking in git.git (Dec 2024, #11; Mon, 30)
@ 2025-01-02 0:25 99% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2025-01-02 0:25 UTC (permalink / raw)
To: Jeff King; +Cc: Patrick Steinhardt, git
Jeff King <peff@peff.net> writes:
> On Mon, Dec 30, 2024 at 09:33:20AM -0800, Junio C Hamano wrote:
>
>> * jk/lsan-race-with-barrier (2024-12-30) 5 commits
> ...
> This graduated faster than I expected. :)
Heh, it is before -rc2 and the change is only about tests, so ...
> ...
> So that line is doing something useful. But it may not be worth the racy
> pain it's causing. So some alternatives are:
>
> - we drop that line by default, and then when people are investigating
> a specific leak, they can override LSAN_OPTIONS themselves to get
> better output (though of course knowing that you can even do is
> tricky)
>
> - we keep that line by default, but override LSAN_OPTIONS for CI to
> avoid the race. That makes all local leak-checking traces
> informative by default. But CI ones may be truncated. I'm not sure
> if people use the CI ones directly, or investigate further
> themselves.
>
> - we could annotate individual scripts or even tests to disable the
> option (since it's really just threaded programs). This is more
> hassle, but would limit the blast radius.
>
> I don't love any of those, but they may be less bad than all of the
> barrier trickery. And it may be that this is even something we could get
> fixed in LSan upstream, and it would just be a temporary workaround. I'm
> still going to pursue that.
>
> And finally, one other option (that I'm not sure why I didn't consider
> before): can we just ignore the false positives, similar to what we did
> in 370ef7e40d (test-lib: ignore uninteresting LSan output, 2023-08-28).
Good point.
> I think we'd have to stop doing abort_on_error for the leak checker and
> just rely on the logs, but that's OK (we always check the logs these
> days).
> ...
> A little hacky, but it lets us have our cake and eat it, too. No changes
> to the code, and no bad stack traces.
>
> What do you think?
I like the small hack. "This is ultimately LSan's racy-ness and not
ours, so let's avoid changing our code to work it around when we can
do the workaround somewhere else" is an attitude that I would endorse
fully.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: a less-invasive racy-leak fix, was Re: What's cooking in git.git (Dec 2024, #11; Mon, 30)
@ 2025-01-02 14:42 99% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2025-01-02 14:42 UTC (permalink / raw)
To: Jeff King; +Cc: Patrick Steinhardt, git
Jeff King <peff@peff.net> writes:
> On Wed, Jan 01, 2025 at 04:25:02PM -0800, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>>
>> > On Mon, Dec 30, 2024 at 09:33:20AM -0800, Junio C Hamano wrote:
>> >
>> >> * jk/lsan-race-with-barrier (2024-12-30) 5 commits
>> > ...
>> > This graduated faster than I expected. :)
>>
>> Heh, it is before -rc2 and the change is only about tests, so ...
>
> Yeah, I figured as much. I also considered it of relatively low
> importance during -rc, but I guess CI false positives do tend to annoy
> everybody and waste their time. :)
>
> It looks like you pushed out the version of 'master' with it merged. I
> had figured you'd revert jk/lsan-race-with-barrier out of next, so I
> wondered how we would proceed (revert the whole merge from master to
> rebuild, or do a moral revert of the final three).
Revert the effect of the tip-part (except for the bottom two) and
then queue the new ones, which would allow me to merge the whole
thing in one go without losing the bottom two's effect (which would
happen if we reverted the whole thing first, and then reused the
bottom two commits to build the new iteration on top).
> Looking at jk/lsan-race-ignore-false-positive, it looks like you did the
> moral revert via fc89d14c63 (Revert barrier-based LSan threading race
> workaround, 2025-01-01). That commit's tree matches what I'd expect (I
> guess you probably used "revert -n HEAD~3..HEAD" just like I did).
I actually did "read-tree -u -m" followed by "commit" ;-)
> It would be nice if the 3-commit revert mentioned the specific commits
> it was reverting.
True. I should probably amend while I can.
> I wonder if revert should have a "squash" mode that reverts all of the
> commits (perhaps in reverse order of application in case they depend on
> each other textually), and then gives you a commit message template
> similar to git-fmt-merge-msg, where we list all of the commits, one per
> line (though probably with their commit ids in this case).
I am not sure if I follow. Should "revert HEAD~3..HEAD" give such
concatenation of messages, something similar to what "rebase -i"
gives us when seeing multiple "squash"es in a row?
^ permalink raw reply [relevance 99%]
* Re: a less-invasive racy-leak fix, was Re: What's cooking in git.git (Dec 2024, #11; Mon, 30)
@ 2025-01-02 19:33 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-01-02 19:33 UTC (permalink / raw)
To: Jeff King; +Cc: Patrick Steinhardt, git
Jeff King <peff@peff.net> writes:
> <SUBJECT: DESCRIBE YOUR REVERT HERE>
>
> Revert the following commits:
>
> - 7a8d9efc26 (grep: work around LSan threading race with barrier, 2024-12-29)
> - 526c0a851b (index-pack: work around LSan threading race with barrier, 2024-12-29)
> - 7d0037b59a (thread-utils: introduce optional barrier type, 2024-12-29)
Ah, I love it.
> You could perhaps even auto-populate the subject with:
>
> Revert jk/lsan-race-with-barrier~3..jk/lsan-race-with-barrier
>
> similar to how git-merge uses "Merge branch ...". But it's a little
> clunky to read, and unlike merge, it's a lot easier to use names that
> are not very meaningful (e.g., I checked out a new branch based on that
> one and then used HEAD~3..HEAD, which is worthless to mention).
Yup, agreed. The commit title is much less interesting to automate
than the "we revert these three" list.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2025, #02; Mon, 6)
@ 2025-01-07 23:12 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-01-07 23:12 UTC (permalink / raw)
To: Toon Claes; +Cc: git
Toon Claes <toon@iotcl.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> * ps/the-repository (2024-12-18) 15 commits
>> ...
> Reviewed by shejialuo, Karthik Nayak, and me.
Yeah, thanks, all. Marked for 'next'.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2025, #04; Tue, 14)
@ 2025-01-16 16:48 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-01-16 16:48 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Derrick Stolee, shejialuo
Patrick Steinhardt <ps@pks.im> writes:
>> * ds/backfill (2024-12-20) 6 commits
>> ...
>> source: <pull.1820.v2.git.1734712193.gitgitgadget@gmail.com>
>
> I had a couple of nits and expect another reroll, but think it's close
> to being ready.
Yeah, this one is looking better.
A new command with a new test script means it requires a bit of
meson.build adjustment but I think that is well under control.
>> * ds/path-walk-1 (2024-12-20) 7 commits
>> ...
>> source: <pull.1818.v4.git.1734711675.gitgitgadget@gmail.com>
>
> I had a single nit, but don't necessarily think that it needs to be
> addressed.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2025, #05; Fri, 17)
@ 2025-01-18 17:17 99% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2025-01-18 17:17 UTC (permalink / raw)
To: Jeff King; +Cc: git
Jeff King <peff@peff.net> writes:
> On Fri, Jan 17, 2025 at 04:42:01PM -0800, Junio C Hamano wrote:
>
>> * jk/pack-header-parse-alignment-fix (2025-01-17) 3 commits
>> ...
>> Will merge to 'next'.
>> source: <20250117125207.GB2356599@coredump.intra.peff.net>
>
> I was planning to re-roll this with your sparse fix included, and adding
> another patch to do get_be32() on the reading side. So maybe hold off
> for a moment.
Thanks.
> (I'd also be interested in any comments on the "maybe we should just
> align these buffers" approach; I'm undecided on it).
Unless we have the buffer _inside_ the helper function that may
perform the possibly-unaligned access, I am not sure how it helps.
I guess that we can align buffers used by two existing callers,
document that the helper function takes an aligned buffer and that
it is a fault of the caller if somebody passes an unaligned buffer,
but I am not sure if that is where we want to go.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2025, #05; Fri, 17)
@ 2025-01-21 19:17 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-01-21 19:17 UTC (permalink / raw)
To: Jeff King; +Cc: git
Jeff King <peff@peff.net> writes:
> I was thinking to just leave the offending code untouched in the
> individual commands if we went this route.
Ah, I see. Yeah, then we have a subtle and possibly brittle code
paths that are well contained inside two functions.
> But anyway, I'll prepare a version going the other get_be32() direction.
Thanks. That probably results in better code with fewer magic.
THanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2025, #05; Fri, 17)
@ 2025-01-21 19:23 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-01-21 19:23 UTC (permalink / raw)
To: David Aguilar; +Cc: git, Scott Chacon
David Aguilar <davvid@gmail.com> writes:
> (The text below is from the original thread; sorry I don't have it handy
> so I just replied here instead)
>
>> ... but would it be simpler if we made it an extended boolean, i.e.
>>
>> true, yes, on, 1 -> same as "immediate"
>> false, no, off, 0 -> same as "never"
>> immediate -> same as what we currently do
>> never -> same as what we currently do
>> prompt -> same as what we currently do
>> number -> same as what we currently do
>
> I do think that, "0 -> same as never," makes a lot of sense from a
> usability perspective.
I obviously do not agree. "Suggest the right spelling and let the
user decide without time-bomb" is a very useful and safe UI, and the
above summary was done by mistake.
> I would instead recommend that, "1 -> same as prompt," would be a safer
> and less surprising behavior. If the user wants "immediate" they can be
> explicit about it. "immediate" is the most dangerous of all of these
> options so adding ambiguous routes to it seems like a step backwards.
Thanks for raising your concern.
As somebody who does *not* use the time-bomb UI that makes me wait
when the heuristics guessed correctly and forces me to scramble to
hit \C-c when it didn't, I am not qualified to comment in favor of
such a huge behaviour change, so I won't, and let others discuss.
> I don't really think backwards-compatibility is much of a concern here
> at all. It *would* be a concern if we were moving from a safe behavior
> to a less-safe behavior (like this patch currently does) but not so in
> the other direction like I'm proposing by making "1" mean "prompt".
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2025, #05; Fri, 17)
@ 2025-01-21 20:30 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-01-21 20:30 UTC (permalink / raw)
To: Derrick Stolee; +Cc: git
Derrick Stolee <stolee@gmail.com> writes:
> On 1/17/25 7:42 PM, Junio C Hamano wrote:
>
>> * ds/name-hash-tweaks (2024-12-20) 8 commits
>> - pack-objects: add third name hash version
>> - pack-objects: prevent name hash version change
>> - test-tool: add helper for name-hash values
>> - p5313: add size comparison test
>> - pack-objects: add GIT_TEST_NAME_HASH_VERSION
>> - repack: add --name-hash-version option
>> - pack-objects: add --name-hash-version option
>> - pack-objects: create new name-hash function version
>> "git pack-objects" and its wrapper "git repack" learned an option
>> to use an alternative path-hash function to improve delta-base
>> selection to produce a packfile with deeper history than window
>> size.
>> Comments?
>> source: <pull.1823.v3.git.1734715194.gitgitgadget@gmail.com>
>
> I'll poke the thread, too, but this seems to be the most promising
> topic in the area of better delta compression. The latest version
> does not have any comments.
>
> The only decision point I think remains is whether or not to
> include the last patch (--name-hash-version=3) which I would be
> happy either way.
I am happy with the updated function that gives us better of both
worlds, without losing too much from the "renamed from other
directory" while making sure we do not lose too many bits in deeper
trees.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2025, #05; Fri, 17)
@ 2025-01-22 17:38 99% ` Junio C Hamano
1 sibling, 0 replies; 200+ results
From: Junio C Hamano @ 2025-01-22 17:38 UTC (permalink / raw)
To: Karthik Nayak; +Cc: git, Johannes Schindelin
Karthik Nayak <karthik.188@gmail.com> writes:
> Karthik Nayak <karthik.188@gmail.com> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> * kn/reflog-migration-fix (2025-01-15) 1 commit
>>> (merged to 'next' on 2025-01-16 at ae8f9ce9a0)
>>> + reftable: write correct max_update_index to header
>>> (this branch is used by kn/reflog-migration-fix-followup.)
>>>
>>> "git refs migrate" for migrating reflog data was broken.
>>>
>>> Will merge to 'master'.
>>> cf. <Z4mUizLNUdq_1BgY@tapette.crustytoothpaste.net>
>>> source: <CAOLa=ZTL9n_DPhNr49XAd6bT838kc09oVx_AH7Pb4o8VK_xQ9w@mail.gmail.com>
>>
>> This seems to be breaking on 'next'. I tested it locally with
>>
>> GIT_TEST_DEFAULT_REF_FORMAT=reftable meson test -v --test-args='-i' t1400-update-ref
>>
>> my local tests were made on files backend, and it didn't trigger on the
>> CI either for some reason (I shall investigate that soon). But dscho
>> (CC'd) reported that macos builds for reftable were failing [1] for his
>> branch and I could bisect it to this.
>>
>> I'm yet to understand why this fails and also why the CI didn't notify
>> of the issue. But that is something I shall do next. For now we need to
>> remove it from next.
>>
>> [1]: https://github.com/dscho/git/actions/runs/12906424058/job/35987723223
>
> This is reproducible when the leak sanitizier is enabled and tested
> against reftable:
>
> So setting up meson with:
> CC=clang meson setup --reconfigure -Db_sanitize=address,undefined build
> and running the test in the build folder with:
> GIT_TEST_DEFAULT_REF_FORMAT=reftable meson test -v
> --test-args='-ixd' t1400-update-ref
>
> reproduces the issue. I haven't found the root cause yet, but will
> mostly call it a day and get back to this tomorrow.
Thanks. I'll mark the topic as on-hold.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2025, #06; Wed, 22)
@ 2025-01-23 1:52 99% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2025-01-23 1:52 UTC (permalink / raw)
To: Jeff King; +Cc: Derrick Stolee, git
Jeff King <peff@peff.net> writes:
> Since this hit 'next', it made it into my Coverity runs, producing the
> small fixup below.
Thanks. A greedy me wonders if things like this can be caught by
them a bit earlier before they hit 'next', though ;-)
> -- >8 --
> Subject: [PATCH] path-walk: drop redundant parse_tree() call
>
> This call to parse_tree() was flagged by Coverity for ignoring the
> return value. But if we look a little further up the function, we can
> see that there is already a call to parse_tree_gently(), and we'll
> return early if that fails. So by this point the tree will always be
> parsed, and the call is redundant.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> path-walk.c | 1 -
> 1 file changed, 1 deletion(-)
Nice way to use extended context to show why the change makes sense.
Will queue. Thanks.
> diff --git a/path-walk.c b/path-walk.c
> index 136ec08fb0..9715a5550e 100644
> --- a/path-walk.c
> +++ b/path-walk.c
> @@ -116,27 +116,26 @@ static int add_tree_entries(struct path_walk_context *ctx,
>
> if (!tree) {
> error(_("failed to walk children of tree %s: not found"),
> oid_to_hex(oid));
> return -1;
> } else if (parse_tree_gently(tree, 1)) {
> error("bad tree object %s", oid_to_hex(oid));
> return -1;
> }
>
> strbuf_addstr(&path, base_path);
> base_len = path.len;
>
> - parse_tree(tree);
> init_tree_desc(&desc, &tree->object.oid, tree->buffer, tree->size);
> while (tree_entry(&desc, &entry)) {
> struct type_and_oid_list *list;
> struct object *o;
> /* Not actually true, but we will ignore submodules later. */
> enum object_type type = S_ISDIR(entry.mode) ? OBJ_TREE : OBJ_BLOB;
>
> /* Skip submodules. */
> if (S_ISGITLINK(entry.mode))
> continue;
>
> /* If the caller doesn't want blobs, then don't bother. */
> if (!ctx->info->blobs && type == OBJ_BLOB)
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2025, #06; Wed, 22)
@ 2025-01-23 1:53 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-01-23 1:53 UTC (permalink / raw)
To: Eric Sunshine; +Cc: git
Eric Sunshine <sunshine@sunshineco.com> writes:
> On Wed, Jan 22, 2025 at 5:49 PM Junio C Hamano <gitster@pobox.com> wrote:
>> * ps/reftable-sign-compare (2025-01-21) 10 commits
>> (merged to 'next' on 2025-01-22 at a5ae1ce801)
>> + reftable: address trivial -Wsign-compare warnings
>> + reftable/blocksource: adjust `read_block()` to return `ssize_t`
>> + reftable/blocksource: adjust type of the block length
>> + reftable/block: adjust type of the restart length
>> + reftable/block: adapt header and footer size to return a `size_t`
>> + reftable/basics: adjust `hash_size()` to return `uint32_t`
>> + reftable/basics: adjust `common_prefix_size()` to return `size_t`
>> + reftable/record: handle overflows when decoding varints
>> + reftable/record: drop unused `print` function pointer
>> + meson: stop disabling -Wsign-compare
>>
>> THe reftable/ library code has been made -Wsign-compare clean.
>
> s/THe/The/
Thanks.
>
>> Will merge to 'master'.
>> source: <20250120-b4-pks-reftable-sign-compare-v2-0-b4566d02e4a5@pks.im>
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2025, #05; Fri, 17)
@ 2025-01-23 18:25 99% ` Junio C Hamano
1 sibling, 0 replies; 200+ results
From: Junio C Hamano @ 2025-01-23 18:25 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: Karthik Nayak, git
Patrick Steinhardt <ps@pks.im> writes:
> Karthik has meanwhile sent a v2 [1] of the broken patch in (1) that
> fixes the issue discovered in (2). Given that (1) has already been in
> next, (2) probably needs to be rerolled to be a patch on top of what we
> already have in next.
>
> Other than that yes, I think (4) and (5) can be merged independently of
> (1) to (3).
Thanks for sanity checking me.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2025, #06; Wed, 22)
@ 2025-01-24 16:02 99% ` Junio C Hamano
1 sibling, 0 replies; 200+ results
From: Junio C Hamano @ 2025-01-24 16:02 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
Patrick Steinhardt <ps@pks.im> writes:
>> * ps/ci-misc-updates (2025-01-10) 10 commits
>> - ci: remove stale code for Azure Pipelines
>> - ci: use latest Ubuntu release
>> - ci: stop special-casing for Ubuntu 16.04
>> - gitlab-ci: add linux32 job testing against i386
>> - gitlab-ci: remove the "linux-old" job
>> - github: simplify computation of the job's distro
>> - github: convert all Linux jobs to be containerized
>> - github: adapt containerized jobs to be rootless
>> - t7422: fix flaky test caused by buffered stdout
>> - t0060: fix EBUSY in MinGW when setting up runtime prefix
>>
>> CI updates (containerization, dropping stale ones, etc.).
>> source: <20250110-b4-pks-ci-fixes-v4-0-6e4613446080@pks.im>
>
> This series was approved by Peff, but other than that it didn't get much
> feedback indeed. I'll rope in some additional reviewers.
This one I took another look while reordering topics for the next
integration and noticing that it had a bit of interaction with
another topic. It looked good, so let me mark it for 'next'.
Unless these others find anything objectionable, that is.
>> * sk/strlen-returns-size_t (2024-12-26) 1 commit
>> - date.c: Fix type missmatch warings from msvc
>>
>> Code clean-up.
>>
>> The remainder needs to be reviewed.
>> source: <20241223110407.3308-3-soekkle@freenet.de>
>
> This one seems stale to me, as there's been a v2 with [1].
IIRC the patches were pretty much independent, and this one was
clearly ready from the initial batch. I'll let it merged to 'next'
independently instead of waiting for the remainder, which was not.
>> * jc/show-index-h-update (2024-12-20) 1 commit
>> - show-index: the short help should say the command reads from its input
>>
>> Doc and short-help text for "show-index" has been clarified to
>> stress that the command reads its data from the standard input.
>>
>> Comments?
>> source: <xmqqfrmidyhk.fsf@gitster.g>
>
> This series looks good to me.
Will mark for 'next', then.
>> * ps/3.0-remote-deprecation (2025-01-22) 7 commits
>> - SQUASH???
>> - remote: announce removal of "branches/" and "remotes/"
>> - builtin/pack-redundant: remove subcommand with breaking changes
>> - ci: repurpose "linux-gcc" job for deprecations
>> - ci: merge linux-gcc-default into linux-gcc
>> - Makefile: wire up build option for deprecated features
>> - Merge branch 'ps/build' into ps/3.0-remote-deprecation
>>
>> Following the procedure we established to introduce breaking
>> changes for Git 3.0, allow an early opt-in for removing support of
>> $GIT_DIR/branches/ and $GIT_DIR/remotes/ directories to configure
>> remotes.
>>
>> Will merge to 'next'?
>> source: <20250122-pks-remote-branches-deprecation-v4-0-5cbf5b28afd5@pks.im>
>
> The squash-commit on top of the series looks good to me, so I think this
> should be ready.
OK, will squash and merge.
>> * ps/send-pack-unhide-error-in-atomic-push (2024-11-14) 2 commits
>> - transport: don't ignore git-receive-pack(1) exit code on atomic push
>> - t5504: modernize test by moving heredocs into test bodies
>>
>> "git push --atomic --porcelain" used to ignore failures from the
>> other side, losing the error status from the child process, which
>> has been corrected.
>>
>> Needs to see if competing parallel topic needs to replace this one.
>> source: <20241113-pks-push-atomic-respect-exit-code-v1-0-7965f01e7f4e@pks.im>
>
> I think v3 sent by Jiang Xin looks like a reasonable alternative to my
> fix, but it needs some fixups. I'll maybe wait one more week for them to
> reroll the series, and if that doesn't happen I might adopt their
> patches and do the fixups by myself.
OK, so just keep this one so that I can point to your above remark
in the message I am responding to ;-)
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2025, #06; Wed, 22)
@ 2025-01-24 17:05 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-01-24 17:05 UTC (permalink / raw)
To: Toon Claes; +Cc: Patrick Steinhardt, git
Toon Claes <toon@iotcl.com> writes:
> Patrick Steinhardt <ps@pks.im> writes:
>
>> On Wed, Jan 22, 2025 at 02:48:43PM -0800, Junio C Hamano wrote:
>>> * ps/build-meson-fixes (2025-01-22) 12 commits
>>> - ci: wire up Visual Studio build with Meson
>>> ...
>>> Will merge to 'next'?
>>> source: <20250122-b4-pks-meson-additions-v3-0-5a51eb5d3dcd@pks.im>
>>
>> Ready from my perspective.
>
> I can't really vouch for the last commit about Visual Studio, but the
> other commits are ready for me as well.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2025, #05; Fri, 17)
@ 2025-01-24 17:06 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-01-24 17:06 UTC (permalink / raw)
To: Karthik Nayak; +Cc: Patrick Steinhardt, git
Karthik Nayak <karthik.188@gmail.com> writes:
> This seems right, just providing another set of eyes here.
Thanks for helping me out.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2025, #07; Fri, 24)
@ 2025-01-28 17:59 99% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2025-01-28 17:59 UTC (permalink / raw)
To: Jeff King; +Cc: brian m. carlson, git
Jeff King <peff@peff.net> writes:
> I noticed CI complaining about a missing include file:
>
> 2025-01-28T15:51:45.3979314Z asciidoc: WARNING: difftool.adoc: line 16: include file not found: /home/runner/work/git/git/Documentation/mergetools-diff.txt
>
> The problem is that the line was introduced by another concurrent
> branch, aj/difftool-config-doc-fix. So we can't fix it independently on
> either branch; the line does not exist yet in brian's adoc branch, and
> the file is still ".txt" in Adam's doc-fix branch.
>
> It has to be fixed in an evil merge of the two (or brian's rebased on
> Adam's, which has since graduated to master).
Thanks; I had this one on my radar and I thought there was a
merge-fix I made somewhere, but it is likely to have been lost
during shuffling the order of merges. Will take a look again.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2025, #08; Tue, 28)
@ 2025-01-29 14:03 99% ` Junio C Hamano
2025-01-29 21:34 99% ` Junio C Hamano
1 sibling, 1 reply; 200+ results
From: Junio C Hamano @ 2025-01-29 14:03 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
Patrick Steinhardt <ps@pks.im> writes:
> On Tue, Jan 28, 2025 at 04:18:00PM -0800, Junio C Hamano wrote:
>> * ps/ci-misc-updates (2025-01-10) 10 commits
>> - ci: remove stale code for Azure Pipelines
>> - ci: use latest Ubuntu release
>> - ci: stop special-casing for Ubuntu 16.04
>> - gitlab-ci: add linux32 job testing against i386
>> - gitlab-ci: remove the "linux-old" job
>> - github: simplify computation of the job's distro
>> - github: convert all Linux jobs to be containerized
>> - github: adapt containerized jobs to be rootless
>> - t7422: fix flaky test caused by buffered stdout
>> - t0060: fix EBUSY in MinGW when setting up runtime prefix
>>
>> CI updates (containerization, dropping stale ones, etc.).
>>
>> Will merge to 'master'.
>> source: <20250110-b4-pks-ci-fixes-v4-0-6e4613446080@pks.im>
>
> I'm a bit confused about the state of this topic. You say it will be
> merged to 'master', but as far as I can see it's not even part of 'next'
> yet.
I am utterly confused---I'll figure out what happened here.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2025, #07; Fri, 24)
@ 2025-01-29 15:03 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-01-29 15:03 UTC (permalink / raw)
To: Derrick Stolee; +Cc: git
Derrick Stolee <stolee@gmail.com> writes:
> On 1/24/25 3:19 PM, Junio C Hamano wrote:
>
>
>> * ds/name-hash-tweaks (2024-12-20) 8 commits
> ...
> After Taylor's review, I believe the latest version is ready
> for 'next'.
>
>
>> * ds/backfill (2025-01-23) 6 commits
>> ...
> I plan to reroll this in a week or so. I wanted to focus on the
> other series for a bit and will bring this back up (and may submit
> the 'git-survey' series as well).
Excellent. Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2025, #08; Tue, 28)
2025-01-29 14:03 99% ` Junio C Hamano
@ 2025-01-29 21:34 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-01-29 21:34 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
Junio C Hamano <gitster@pobox.com> writes:
> Patrick Steinhardt <ps@pks.im> writes:
>
>> On Tue, Jan 28, 2025 at 04:18:00PM -0800, Junio C Hamano wrote:
>>> * ps/ci-misc-updates (2025-01-10) 10 commits
>>> ...
>>>
>>> CI updates (containerization, dropping stale ones, etc.).
>>>
>>> Will merge to 'master'.
>>> source: <20250110-b4-pks-ci-fixes-v4-0-6e4613446080@pks.im>
>>
>> I'm a bit confused about the state of this topic. You say it will be
>> merged to 'master', but as far as I can see it's not even part of 'next'
>> yet.
>
> I am utterly confused---I'll figure out what happened here.
This turns out to be a simple typo where I meant to say "next" and
typed "master". I was worried about something worse, like
accicentally removing one entry that was ready to be merged to
'master' that happened to be listed immediately after this one.
Thanks for noticing.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2025, #07; Fri, 24)
@ 2025-01-30 17:26 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-01-30 17:26 UTC (permalink / raw)
To: brian m. carlson; +Cc: Jeff King, git
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
> On 2025-01-28 at 18:26:12, Junio C Hamano wrote:
>> Here is what I'd directly apply to 'next'. The merge-fix mechanism
>> knows about the same change, so when I merge the bc/doc-adoc-not-txt
>> topic down to 'master', the same tweak will be made as an evil
>> merge.
>
> I agree that seems like the right solution.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2025, #08; Tue, 28)
@ 2025-01-31 17:51 99% ` Junio C Hamano
1 sibling, 0 replies; 200+ results
From: Junio C Hamano @ 2025-01-31 17:51 UTC (permalink / raw)
To: git; +Cc: Julian Prein
Junio C Hamano <gitster@pobox.com> writes:
> * jp/doc-trailer-config (2025-01-24) 1 commit
> - config.txt: add trailer.* variables
>
> Documentaiton updates.
>
> Will merge to 'next'?
> source: <pull.1871.git.git.1736429142334.gitgitgadget@gmail.com>
I've held the topic (and others that touch documentation) in 'seen'
as we have been seeing GitHub CI breakages on documentation task,
but I think I figured out that it was due to semantic mismerge with
this topic and the recent "everything in Documentation/ now ends
with *.adoc; they are no longer *.txt". I'll make a merge-fix and
will mark this topic for 'next' when the result proves OK.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2025, #06; Wed, 22)
@ 2025-02-02 23:39 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-02-02 23:39 UTC (permalink / raw)
To: Jeff King; +Cc: Derrick Stolee, git
Jeff King <peff@peff.net> writes:
> But I have a feeling it is just putting the same on
> both of us as we see the same CI failures and poke at them
> independently.
Certainly true.
> I dunno. I'll try it for a while and see how it goes.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2025, #08; Tue, 28)
@ 2025-02-03 21:32 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-02-03 21:32 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: Jeff King, git
Patrick Steinhardt <ps@pks.im> writes:
> On Fri, Jan 31, 2025 at 06:30:15PM -0500, Jeff King wrote:
>> On Wed, Jan 29, 2025 at 08:57:36AM +0100, Patrick Steinhardt wrote:
>> -- >8 --
>> Subject: [PATCH] ci: set CI_JOB_IMAGE for coverity job
>>
>> The main GitHub Actions workflow switched away from the "$distro"
>> variable in b133d3071a (github: simplify computation of the job's
>> distro, 2025-01-10). Since the Coverity job also depends on our
>> ci/install-dependencies.sh script, it needs to likewise set CI_JOB_IMAGE
>> to find the correct dependencies (without this patch, we don't install
>> curl and the build fails).
>>
>> Signed-off-by: Jeff King <peff@peff.net>
>> ---
>> Grepping for "distro:" doesn't find any other instances.
>
> Doh, indeed. Thanks for fixing!
Thanks, both. Queued and pushed out.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2025, #09; Fri, 31)
@ 2025-02-03 21:38 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-02-03 21:38 UTC (permalink / raw)
To: Derrick Stolee; +Cc: git, me, ps
Derrick Stolee <stolee@gmail.com> writes:
> On 1/31/25 9:51 PM, Junio C Hamano wrote:
>
>> * ds/backfill (2025-01-23) 6 commits
>> - backfill: assume --sparse when sparse-checkout is enabled
>> - backfill: add --sparse option
>> - backfill: add --min-batch-size=<n> option
>> - backfill: basic functionality and tests
>> - backfill: add builtin boilerplate
>> - Merge branch 'ds/path-walk-1' into ds/backfill
>> Lazy-loading missing files in a blobless clone on demand is costly
>> as it tends to be one-blob-at-a-time. "git backfill" is introduced
>> to help bulk-download necessary files beforehand.
>> Expecting a reroll.
>> cf. <Z4jeQSLmARruE5l3@pks.im>
>> source: <pull.1820.v2.git.1734712193.gitgitgadget@gmail.com>
>
> I've updated this onto 'master' now that ds/path-walk-1 is merged. v3
> is imminent.
>
> It required a few updates that I'm sure you've been making within the
> merge in order to keep 'seen' building.
;-)
>> * ds/name-hash-tweaks (2025-01-27) 7 commits
>> - pack-objects: prevent name hash version change
>> - test-tool: add helper for name-hash values
>> - p5313: add size comparison test
>> - pack-objects: add GIT_TEST_NAME_HASH_VERSION
>> - repack: add --name-hash-version option
>> - pack-objects: add --name-hash-version option
>> - pack-objects: create new name-hash function version
>> "git pack-objects" and its wrapper "git repack" learned an option
>> to use an alternative path-hash function to improve delta-base
>> selection to produce a packfile with deeper history than window
>> size.
>> Will merge to 'next'?
>> source: <pull.1823.v4.git.1738004554.gitgitgadget@gmail.com>
> Since this is still marked with a question mark, I'll mention that
> the last version seems stable and has Taylor's review.
Indeed this has an Ack in <Z51DHdS8SStRGalX@nand.local>. Let's
merge it down to 'next'.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2025, #09; Fri, 31)
@ 2025-02-04 17:48 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-02-04 17:48 UTC (permalink / raw)
To: Karthik Nayak; +Cc: git
Karthik Nayak <karthik.188@gmail.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
> [snip]
>
>> * kn/reflog-migration-fix (2025-01-15) 1 commit
> ...
> So all in all, this can be moved from 'on hold'.
This was on hold until the kn/reflog-migration-fix-fix topic
you did around "max_index" on top of this solidified. That
other topic needed to be in 'master' if this were to be, and
I think we already have them in 'master' as of the seventh batch.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Feb 2025, #01; Tue, 4)
@ 2025-02-05 20:37 99% ` Junio C Hamano
2025-02-06 0:04 99% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2025-02-05 20:37 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Justin Tobler, Johannes Sixt
Patrick Steinhardt <ps@pks.im> writes:
> On Tue, Feb 04, 2025 at 06:08:57PM -0800, Junio C Hamano wrote:
>> * tc/clone-single-revision (2025-02-04) 7 commits
>
> I'll do another review today.
Thanks
>
>> * ps/reftable-sans-compat-util (2025-02-03) 19 commits
>> ...
> From my POV it's ready, but I'd like to get an Ack from Justin and
> Johannes, as they both had comments on the last round. I've Cc'd them.
Noted.
>> * kn/reflog-migration-fix-followup (2025-01-22) 4 commits
> I think this topic should now be unblocked as all the preceding fixes
> and fixes of fixes have been merged.
Indeed.
>> * bf/fetch-set-head-fix (2025-01-27) 2 commits
> Yup, I think this series is ready.
OK.
>> * ds/backfill (2025-02-03) 7 commits
> I'll do another review today, but think it should be close or ready.
Agreed, and thanks.
>> * ps/send-pack-unhide-error-in-atomic-push (2025-02-03) 8 commits
>> Will merge to 'next'?
>> source: <20250203-pks-push-atomic-respect-exit-code-v5-0-d66481e36622@pks.im>
>
> I think so.
OK.
> One topic that I miss in the cover letter is [1]. You probably forgot to
> pick it up :)
>
> [1]: <20250125-b4-pks-reftable-win32-in-use-errors-v1-1-356dbc783b4f@pks.im>
OK, I was wondering if we are going to rethink after seeing some
comments but with blessing by j6t [*], I guess this is fine.
[*]: <37c14379-68e4-4c52-a08d-b78c7797ef26@kdbg.org>
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Feb 2025, #01; Tue, 4)
2025-02-05 20:37 99% ` Junio C Hamano
@ 2025-02-06 0:04 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-02-06 0:04 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Justin Tobler, Johannes Sixt
Junio C Hamano <gitster@pobox.com> writes:
> Patrick Steinhardt <ps@pks.im> writes:
>
>> One topic that I miss in the cover letter is [1]. You probably forgot to
>> pick it up :)
>>
>> [1]: <20250125-b4-pks-reftable-win32-in-use-errors-v1-1-356dbc783b4f@pks.im>
>
> OK, I was wondering if we are going to rethink after seeing some
> comments but with blessing by j6t [*], I guess this is fine.
>
> [*]: <37c14379-68e4-4c52-a08d-b78c7797ef26@kdbg.org>
Wait. This works by futzing with unlink() call that is imported via
<git-compat-util.h> which you got rid of in a separate topic, and
given the overall theme of sans-compat-util topic, I do not think
you want to include <compat/mingw.h> either directly or indirectly
(via <git-compat-util.h> as we used to), either.
So where would that leave us...?
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Feb 2025, #01; Tue, 4)
@ 2025-02-07 17:11 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-02-07 17:11 UTC (permalink / raw)
To: Toon Claes; +Cc: git
Toon Claes <toon@iotcl.com> writes:
>> * ps/reftable-sans-compat-util (2025-02-03) 19 commits
>> ...
>> - reftable/basics: stop using `UNUSED` annotation
>> ...
>> Will merge to 'next'?
>> source: <20250203-pks-reftable-drop-git-compat-util-v3-0-446c9ed4ee9e@pks.im>
>
> I gave v4 a round of review, and besides one question/possible
> suggestion these changes look good.
Yeah, I saw them. Very much appreciated.
Patrick's latest (i.e., v5) addresses the UNUSED one, so assuming
that one looks reasonable to everybody, we are in very good shape.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Feb 2025, #06; Tue, 18)
@ 2025-02-20 15:56 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-02-20 15:56 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
Patrick Steinhardt <ps@pks.im> writes:
> On Tue, Feb 18, 2025 at 05:31:54PM -0800, Junio C Hamano wrote:
>> * ps/path-sans-the-repository (2025-02-07) 16 commits
>> - path: adjust last remaining users of `the_repository`
>> - environment: move access to "core.sharedRepository" into repo settings
>> - environment: move access to "core.hooksPath" into repo settings
>> - repo-settings: introduce function to clear struct
>> - path: drop `git_path()` in favor of `repo_git_path()`
>> - rerere: let `rerere_path()` write paths into a caller-provided buffer
>> - path: drop `git_common_path()` in favor of `repo_common_path()`
>> - worktree: return allocated string from `get_worktree_git_dir()`
>> - path: drop `git_path_buf()` in favor of `repo_git_path_replace()`
>> - path: drop `git_pathdup()` in favor of `repo_git_path()`
>> - path: drop unused `strbuf_git_path()` function
>> - path: refactor `repo_submodule_path()` family of functions
>> - submodule: refactor `submodule_to_gitdir()` to accept a repo
>> - path: refactor `repo_worktree_path()` family of functions
>> - path: refactor `repo_git_path()` family of functions
>> - path: refactor `repo_common_path()` family of functions
>>
>> The path.[ch] API takes an explicit repository parameter passed
>> throughout the callchain, instead of relying on the_repository
>> singleton instance.
>> source: <20250207-b4-pks-path-drop-the-repository-v2-0-13cad3c11b8a@pks.im>
>
> This series has been Ack'd by both Karthik and Jialuo -- do you want me
> to pull in additional reviewers to move it forward?
Nah, I've seen their comments on the first round. Let me give it a
quick scan before marking it for 'next'.
>> * ps/build-meson-fixes-0130 (2025-01-30) 14 commits
>> - gitlab-ci: restrict maximum number of link jobs on Windows
>> - meson: consistently use custom program paths to resolve programs
>> - meson: fix overwritten `git` variable
>> - meson: prevent finding sed(1) in a loop
>> - meson: improve handling of `sane_tool_path` option
>> - meson: improve PATH handling
>> - meson: drop separate version library
>> - meson: stop linking libcurl into all executables
>> - meson: introduce `libgit_curl` dependency
>> - meson: simplify use of the common-main library
>> - meson: inline the static 'git' library
>> - meson: fix OpenSSL fallback when not explicitly required
>> - meson: fix exec path with enabled runtime prefix
>> - Merge branch 'ps/build-meson-fixes' into ps/build-meson-fixes-0130
>>
>> Assorted fixes and improvements to the build procedure based on
>> meson.
>>
>> Needs review.
>> source: <20250130-b4-pks-meson-improvements-v2-0-2f05581ffb44@pks.im>
>
> This one has also received two reviews by Toon and Justin and it has
> been cooking for quite a while, so the same question here.
Yup, this one looks good to me, too, from a cursory look. Let me
mark it for 'next'.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Feb 2025, #07; Mon, 24)
@ 2025-02-25 17:06 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-02-25 17:06 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
Patrick Steinhardt <ps@pks.im> writes:
> On Mon, Feb 24, 2025 at 06:47:23PM -0800, Junio C Hamano wrote:
>> * ps/meson-contrib-bits (2025-02-20) 10 commits
>> - ci: exercise credential helpers
>> - ci: fix propagating UTF-8 test locale in musl-based Meson job
>> - meson: wire up static analysis via Coccinelle
>> - meson: wire up git-contacts(1)
>> - meson: wire up credential helpers
>> - contrib/credential: fix compilation of "osxkeychain" helper
>> - contrib/credential: fix compiling "libsecret" helper
>> - contrib/credential: fix compilation of wincred helper with MSVC
>> - contrib/credential: fix "netrc" tests with out-of-tree builds
>> - GIT-BUILD-OPTIONS: propagate project's source directory
>>
>> Update meson-based build procedure to cover contrib/ and other
>> places as well.
>>
>> Expecting a reroll.
>> source: <20250218-b4-pks-meson-contrib-v1-0-c3edd292beb8@pks.im>
>
> v2 of this patch series hasn't yet received any comments that require a
> reroll, unless I've missed something.
I misread the exchange between you and Ramsay; I am fine with the
decision to leave the sparse and the hdr-check outside this series,
for some future follow-up work. Let me mark it for 'next'.
>> * ps/path-sans-the-repository (2025-02-24) 17 commits
>> - fixup! rerere: let `rerere_path()` write paths into a caller-provided buffer
>> - path: adjust last remaining users of `the_repository`
>> - environment: move access to "core.sharedRepository" into repo settings
>> - environment: move access to "core.hooksPath" into repo settings
>> - repo-settings: introduce function to clear struct
>> - path: drop `git_path()` in favor of `repo_git_path()`
>> - rerere: let `rerere_path()` write paths into a caller-provided buffer
>> - path: drop `git_common_path()` in favor of `repo_common_path()`
>> - worktree: return allocated string from `get_worktree_git_dir()`
>> - path: drop `git_path_buf()` in favor of `repo_git_path_replace()`
>> - path: drop `git_pathdup()` in favor of `repo_git_path()`
>> - path: drop unused `strbuf_git_path()` function
>> - path: refactor `repo_submodule_path()` family of functions
>> - submodule: refactor `submodule_to_gitdir()` to accept a repo
>> - path: refactor `repo_worktree_path()` family of functions
>> - path: refactor `repo_git_path()` family of functions
>> - path: refactor `repo_common_path()` family of functions
>>
>> The path.[ch] API takes an explicit repository parameter passed
>> throughout the callchain, instead of relying on the_repository
>> singleton instance.
>>
>> Will merge to 'next'?
>> source: <20250207-b4-pks-path-drop-the-repository-v2-0-13cad3c11b8a@pks.im>
>
> The fixup commit looks good to me, so I'll refrain from sending a v3
> only to roll the fix into the series.
OK. I read them over before saying "'next'?" and still missed what
Peff spotted, so I have no confidence in my reviews over these
patches, which is a bit of a problem for me.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Feb 2025, #09; Fri, 28)
@ 2025-03-03 17:03 99% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2025-03-03 17:03 UTC (permalink / raw)
To: shejialuo; +Cc: git, Karthik Nayak, Patrick Steinhardt
shejialuo <shejialuo@gmail.com> writes:
> On Fri, Feb 28, 2025 at 04:45:31PM -0800, Junio C Hamano wrote:
>
>> * sj/ref-consistency-checks-more (2025-02-27) 9 commits
>> - builtin/fsck: add `git refs verify` child process
>> - packed-backend: check whether the "packed-refs" is sorted
>> - packed-backend: add "packed-refs" entry consistency check
>> - packed-backend: check whether the refname contains NUL characters
>> - packed-backend: add "packed-refs" header consistency check
>> - packed-backend: check if header starts with "# pack-refs with: "
>> - packed-backend: check whether the "packed-refs" is regular file
>> - builtin/refs: get worktrees without reading head information
>> - t0602: use subshell to ensure working directory unchanged
>>
>> "git fsck" becomes more careful when checking the refs.
>>
>> Comments?
>> source: <Z8CMx7O19PMs9sVY@ArchLinux>
>
> I think I have addressed the comments from you, Patrick and Karthik.
> Could we make the patch into "next"?
Mine was merely a small kibitzing on the logic flow structure, and I
didn't really looked at the larger picture beyond that part of the
code I looked at. Let's hear from Patrick and Karthik (cc'ed) if
they find the result of the updates satisfactory.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Feb 2025, #09; Fri, 28)
@ 2025-03-04 15:30 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-03-04 15:30 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: shejialuo, git, Karthik Nayak
Patrick Steinhardt <ps@pks.im> writes:
> So while I think that executing the command in git-fsck(1) is a good
> thing overall, I would feel a bit more comfortable if that last commit
> of the series landed in the next release cycle. But maybe I'm just being
> overly cautious?
Anything not in 'next' by -rc1 needs strong justification to further
advance during the cycle, so by default it would stay and cook in
'next' before the release. I have a handful of topics in mind that
I do want to see merged before -rc2 but this was not one of them.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Mar 2025, #02; Thu, 6)
@ 2025-03-11 17:05 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-03-11 17:05 UTC (permalink / raw)
To: shejialuo; +Cc: git
shejialuo <shejialuo@gmail.com> writes:
> On Thu, Mar 06, 2025 at 04:55:31PM -0800, Junio C Hamano wrote:
>> [Cooking]
>> * ps/refname-avail-check-optim (2025-03-06) 16 commits
>> - refs: reuse iterators when determining refname availability
>> - refs/iterator: implement seeking for files iterators
>> - refs/iterator: implement seeking for packed-ref iterators
>> - refs/iterator: implement seeking for ref-cache iterators
>> - refs/iterator: implement seeking for reftable iterators
>> - refs/iterator: implement seeking for merged iterators
>> - refs/iterator: provide infrastructure to re-seek iterators
>> - refs/iterator: separate lifecycle from iteration
>> - refs: stop re-verifying common prefixes for availability
>> - refs/files: batch refname availability checks for initial transactions
>> - refs/files: batch refname availability checks for normal transactions
>> - refs/reftable: batch refname availability checks
>> - refs: introduce function to batch refname availability checks
>> - builtin/update-ref: skip ambiguity checks when parsing object IDs
>> - object-name: allow skipping ambiguity checks in `get_oid()` family
>> - object-name: introduce `repo_get_oid_with_flags()`
>> (this branch is used by kn/non-transactional-batch-updates.)
>>
>> The code paths to check whether a refname X is available (by seeing
>> if another ref X/Y exists, etc.) have been optimized.
>>
>> Needs review.
>> source: <20250306-pks-update-ref-optimization-v5-0-dcb2ee037e97@pks.im>
>
> I have reviewed some patches for the earlier version. This week, if I
> have bandwidth, I would review the whole patches again for this version.
Thanks. Any topic outside 'next' would not move until the final
release so it is not urgent (read: if you find a new regression
introduced to 'master' during this cycle and can work on fixing it,
that should take precedence), but if you do have bandwidth to do so
it would be great.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Mar 2025, #03; Wed, 12)
@ 2025-03-18 17:17 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-03-18 17:17 UTC (permalink / raw)
To: Karthik Nayak; +Cc: git
Karthik Nayak <karthik.188@gmail.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>
>> * kn/reflog-drop (2025-03-10) 1 commit
>> - reflog: implement subcommand to drop reflogs
>>
>> "git reflog" learns "drop" subcommand, that discards the entire
>> reflog data for a ref.
>>
>> Will merge to 'next'?
>> source: <20250310-493-add-command-to-purge-reflog-entries-v2-1-05caa92e0bfa@gmail.com>
>>
>
> I did a re-roll here, with some fixes based on Patrick's review. I will
> try and get another review before we move this forward. Thanks!
I have the v3 queued; haven't caught up with the reviews with
today's timestamp yet, though.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: ps/reftable-sans-compat-util, was Re: What's cooking in git.git (Feb 2025, #09; Fri, 28)
@ 2025-03-27 15:28 99% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2025-03-27 15:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Patrick Steinhardt, git
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Below patch addresses the issue.
>>
>> Patrick
>>
>> diff --git a/compat/posix.h b/compat/posix.h
>> index b484029f751..5ad3539d55b 100644
>> --- a/compat/posix.h
>> +++ b/compat/posix.h
>> @@ -176,6 +176,16 @@ typedef unsigned long uintptr_t;
>> #define _ALL_SOURCE 1
>> #endif
>>
>> +#ifdef USE_MIMALLOC
>> +#include "mimalloc.h"
>> +#define malloc mi_malloc
>> +#define calloc mi_calloc
>> +#define realloc mi_realloc
>> +#define free mi_free
>> +#define strdup mi_strdup
>> +#define strndup mi_strndup
>> +#endif
>> +
>> #ifdef MKDIR_WO_TRAILING_SLASH
>> #define mkdir(a,b) compat_mkdir_wo_trailing_slash((a),(b))
>> int compat_mkdir_wo_trailing_slash(const char*, mode_t);
>> diff --git a/git-compat-util.h b/git-compat-util.h
>> index 8d2acf86670..a102a365592 100644
>> --- a/git-compat-util.h
>> +++ b/git-compat-util.h
>> @@ -226,16 +226,6 @@ static inline const char *precompose_string_if_needed(const char *in)
>> # include <sys/sysinfo.h>
>> #endif
>>
>> -#ifdef USE_MIMALLOC
>> -#include "mimalloc.h"
>> -#define malloc mi_malloc
>> -#define calloc mi_calloc
>> -#define realloc mi_realloc
>> -#define free mi_free
>> -#define strdup mi_strdup
>> -#define strndup mi_strndup
>> -#endif
>> -
>> #ifndef PATH_SEP
>> #define PATH_SEP ':'
>> #endif
>
> I integrated this into Git for Windows' `shears/seen` branch (i.e. the
> continuously-rebased Git for Windows patches on top of the `seen` branch),
> and for the first time in weeks, it passed the CI build:
> https://github.com/git-for-windows/git/actions/runs/14087673643
Thanks.
So we'll see a final reroll with the above changes and the topic
will finally be moving? That's a great news.
^ permalink raw reply [relevance 99%]
* Re: ps/reftable-sans-compat-util, was Re: What's cooking in git.git (Feb 2025, #09; Fri, 28)
@ 2025-03-29 23:56 99% ` Junio C Hamano
1 sibling, 0 replies; 200+ results
From: Junio C Hamano @ 2025-03-29 23:56 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: Johannes Schindelin, git
Patrick Steinhardt <ps@pks.im> writes:
>> So we'll see a final reroll with the above changes and the topic
>> will finally be moving? That's a great news.
>
> The topic can be merged as-is. The relevant MIMALLOC code only exists
> downstream in Git for Windows, so there is nothing that I can do about
> it in this series.
>
> Thanks all!
Thanks, both, for productive discussions.
Let me mark the topic for 'next'.
^ permalink raw reply [relevance 99%]
* Re: ps/reftable-sans-compat-util, was Re: What's cooking in git.git (Feb 2025, #09; Fri, 28)
@ 2025-03-30 0:56 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-03-30 0:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Patrick Steinhardt, git
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> The topic can be merged as-is. The relevant MIMALLOC code only exists
>> downstream in Git for Windows, so there is nothing that I can do about
>> it in this series.
>
> Yes, and I already replied in the thread (which is admittedly challenging
> to keep track of, as it is not connected to these "What's cooking?" email
> in any way, or to the topic branch) in the affirmative that Patrick's
> suggestion worked around the CI failures I observed in Git for Windows.
>
> So yes, this can move forward.
Thanks for confirmation. The topic has been marked for 'next'.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Apr 2025, #01; Mon, 7)
@ 2025-04-08 14:50 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-04-08 14:50 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
Patrick Steinhardt <ps@pks.im> writes:
> On Mon, Apr 07, 2025 at 04:49:28PM +0000, Junio C Hamano wrote:
>> * pb/perf-test-fixes (2025-03-28) 2 commits
>> - p9210: fix 'scalar clone' when running from a detached HEAD
>> - p7821: fix test_perf invocation for prereqs
>>
>> "make perf" fixes.
>>
>> Will merge to 'next'?
>> cf. <Z-pD1puYT87YKAd4@pks.im>
>> source: <pull.1936.git.git.1743181669.gitgitgadget@gmail.com>
>
> I had one question around empty prereqs introduced by the patch that
> wasn't yet answered. Based on my testing empty prereqs do work just fine
> though and evaluate to true, so the patch series looks fine to me.
>
>> * ps/misc-build-fixes (2025-04-01) 5 commits
>> - ci: use Visual Studio for win+meson job on GitHub Workflows
>> - meson: distinguish build and target host binaries
>> - meson: respect 'tests' build option in contrib
>> - gitweb: fix generation of "gitweb.js"
>> - meson: fix handling of '-Dcurl=auto'
>>
>> Random build fixes.
>>
>> Will merge to 'next'?
>> cf. <CAOLa=ZQ8bTn-prAs2ycLdLLjVaLQL4GtLw_gFsvAcx_6j=MBjA@mail.gmail.com>
>> source: <20250331-b4-pks-collect-build-fixes-v2-0-6b06136808f3@pks.im>
>
> I think this one should be ready to be merged.
>
>> * ab/pathspec-sign-compare-workaround (2025-04-01) 1 commit
>> - pathspec: fix sign comparison warnings
>>
>> Some warnings from "-Wsign-compare" for pathspec.c have been
>> squelched.
>>
>> Will merge to 'next'?
>> source: <127c3010-4b23-436e-a07d-e6031e746113@gmail.com>
>
> I had another read just now, the patch looks good to me.
>
>> * jt/rev-list-z (2025-03-21) 5 commits
>> - rev-list: support NUL-delimited --missing option
>> - rev-list: support NUL-delimited --boundary option
>> - rev-list: support delimiting objects with NUL bytes
>> - rev-list: refactor early option parsing
>> - rev-list: inline `show_object_with_name()` in `show_object()`
>>
>> "git rev-list" learns machine-parsable output format that delimits
>> each field with NUL.
>>
>> Will merge to 'next'?
>> source: <20250319183410.1225428-1-jltobler@gmail.com>
>
> Same here, I did scan through the series again and didn't notice
> anything objectionable.
>
>> * sk/clar-trailer-urlmatch-norm-test (2025-03-04) 2 commits
>> - t/unit-tests: convert urlmatch-normalization test to clar
>> - t/unit-tests: convert trailer test to use clar
>>
>> A few traditional unit tests have been rewritten to use the clar
>> framework.
>>
>> Will merge to 'next'?
>> cf. <xmqqzfi0pthr.fsf@gitster.g>
>> source: <20250304113323.10564-1-kuforiji98@gmail.com>
>
> Yup. I didn't review this on-list, but already reviewed it internally
> before Seyi sent it to the mailing list.
>
> Patrick
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Mar 2025, #07; Wed, 26)
@ 2025-04-08 22:49 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-04-08 22:49 UTC (permalink / raw)
To: D. Ben Knoble; +Cc: Git
"D. Ben Knoble" <ben.knoble@gmail.com> writes:
> On Fri, Mar 28, 2025 at 8:34 PM D. Ben Knoble <ben.knoble@gmail.com> wrote:
>>
>> On Wed, Mar 26, 2025 at 8:46 AM Junio C Hamano <gitster@pobox.com> wrote:
>> > * ib/diff-S-G-with-longhand (2025-02-12) 10 commits
>> > - diff: docs: Use --patch-{grep,modifies} over -G/-S
>> > - diff: --pickaxe-{all,regex} help: Add --patch-{grep,modifies}
>> > - diff: test: Use --patch-{grep,modifies} over -G/-S
>> > - completion: Support --patch-{grep,modifies}
>> > - diff: --patch-{grep,modifies} arg names for -G and -S
>> > - docs: gitdiffcore: -G and -S: Use regex/string placeholders
>> > - diff: short help: Add -G and --pickaxe-grep
>> > - diff: short help: Correct -S description
>> > - diff: -G description: Correct copy/paste error
>> > - t/t4209-log-pickaxe: Naming typo: -G takes a regex
>> >
>> > The commands in the "diff" family learned longhands for "-S" and
>> > "-G" options.
>> >
>> > The core part looked mostly good.
>> > source: <20250212032657.1807939-1-illia.bobyr@gmail.com>
>>
>> I'd be interested in seeing this land. I think I can read through
>> review comments
>> and split the cleanups from the addition of long-form options (both of which I
>> think are generally improvements), but without signoffs in the original commits
>> I feel like I might be overstepping on the intellectual property---and I
>> certainly wouldn't want to cause licensing trouble for Git.
>>
>> What's the usual way to proceed in a case like this?
>>
>> PS enjoy the vacation Junio---I'm hoping someone else will reply so that you
>> don't need to :)
>>
>> Cheers,
>> Ben
>
> Looks like maybe my query got dropped during the vacation time: I saw
> the newest "What's cooking" said "Expecting a reroll"—did I miss an
> update in the original thread?
Yeah, unfortunately it wouldn't be good to add changes of dubious
origin that is not certified with DCO sign-off.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Apr 2025, #01; Mon, 7)
@ 2025-04-09 16:01 99% ` Junio C Hamano
2025-06-05 12:51 99% ` Junio C Hamano
1 sibling, 0 replies; 200+ results
From: Junio C Hamano @ 2025-04-09 16:01 UTC (permalink / raw)
To: Philippe Blain; +Cc: git
Philippe Blain <levraiphilippeblain@gmail.com> writes:
> Hi Junio,
>
> Le 2025-04-07 à 12:49, Junio C Hamano a écrit :
>
>> * pb/status-rebase-fixes (2025-03-28) 4 commits
>> - wt-status: suggest 'git rebase --continue' to conclude 'merge' instruction
>> - wt-status: also abbreviate 'merge' and 'fixup -C' lines during rebase
>> - SQUASH??? - <CAPig+cS92W_gYuNsaTvQxiP3xBK7Wpg0__uVkgAU1x0OFJUZgQ@mail.gmail.com>
>> - rebase -r: do create merge commit after empty resolution
>>
>> A few fixes around "git status" while "git rebase" is running.
>
> Note: the first commit is really a 'git rebase' fix, and does not concern
> 'git status' at all. I think this should be mentioned in the release notes,
> or if you prefer I could split it into a separate series.
Thanks.
... plus a corner case fix for "git rebase -r".
tucked at the end of the sentence would probably be good enough?
>> Comments? It probably deserves a clarifying reroll.
>> cf. <c2f93d99-2f4d-ee6d-7087-42320c6df0f2@gmx.de>
>> source: <pull.1897.git.1743181401.gitgitgadget@gmail.com>
>
> Yes, I will address the reviewer feedback and send a new version.
Thanks, again.
^ permalink raw reply [relevance 99%]
* Re: ds/path-walk-2 (was Re: What's cooking in git.git (Apr 2025, #03; Fri, 11))
@ 2025-04-14 12:34 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-04-14 12:34 UTC (permalink / raw)
To: Derrick Stolee; +Cc: git, Taylor Blau, Patrick Steinhardt
Derrick Stolee <stolee@gmail.com> writes:
> On 4/11/2025 6:58 PM, Junio C Hamano wrote:
>
>> * ds/path-walk-2 (2025-03-25) 13 commits
>> - pack-objects: allow --shallow and --path-walk
>> - path-walk: add new 'edge_aggressive' option
>> - pack-objects: thread the path-based compression
>> - pack-objects: refactor path-walk delta phase
>> - scalar: enable path-walk during push via config
>> - pack-objects: enable --path-walk via config
>> - repack: add --path-walk option
>> - t5538: add tests to confirm deltas in shallow pushes
>> - pack-objects: introduce GIT_TEST_PACK_PATH_WALK
>> - p5313: add performance tests for --path-walk
>> - pack-objects: update usage to match docs
>> - pack-objects: add --path-walk option
>> - pack-objects: extract should_attempt_deltas()
>>
>> "git pack-objects" learns to find delta bases from blobs at the
>> same path, using the --path-walk API.
>>
>> Comments?
>> source: <pull.1819.v2.git.1742829769.gitgitgadget@gmail.com>
> The current version (v2) has not received any comments yet. v1 had
> some, which I responded to, as well as some exploration of the use
> of --window by Taylor. I haven't heard anything since then.
Right. I do not recall seeing anybody doing a deep dive, which I
would prefer to see done in the code paths involved. At least I'd
want to see somebody (could be me) verify that the changes would not
break when the new option is not in effect before merging it.
> I continue to get user reports of folks using this feature in Git
> for Windows or microsoft/git, so I still think this would be a
> valuable improvement for the core project.
Oh, no quiestion about that part. Otherwise we wouldn't be listing
the topic in this list ;-). I just want to see support not just by
the end-users who do not know or care how the thing looks internally,
but also by the folks around here who do.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Apr 2025, #03; Fri, 11)
@ 2025-04-14 13:04 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-04-14 13:04 UTC (permalink / raw)
To: Philippe Blain; +Cc: git
Philippe Blain <levraiphilippeblain@gmail.com> writes:
> Hi Junio,
>
> Le 2025-04-11 à 18:58, Junio C Hamano a écrit :
>
>> * pb/perf-test-fixes (2025-03-28) 2 commits
>> (merged to 'next' on 2025-04-08 at a8aaeee41e)
>> + p9210: fix 'scalar clone' when running from a detached HEAD
>> + p7821: fix test_perf invocation for prereqs
>>
>> "make perf" fixes.
>>
>> Will merge to 'master'.
>> cf. <Z-pD1puYT87YKAd4@pks.im>
>> cf. <Z_TAtJ9LEeHo2AQN@pks.im>
>> source: <pull.1936.git.git.1743181669.gitgitgadget@gmail.com>
>
> I actually found a small error in the comment at the top of p7821,
> I'll send a new version with a 3rd commit on top.
Thanks!
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Apr 2025, #03; Fri, 11)
@ 2025-04-14 13:34 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-04-14 13:34 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
Patrick Steinhardt <ps@pks.im> writes:
> On Fri, Apr 11, 2025 at 03:58:33PM -0700, Junio C Hamano wrote:
>> * ps/object-file-cleanup (2025-04-11) 10 commits
>> - object-store: merge "object-store-ll.h" and "object-store.h"
>> - object-store: remove global array of cached objects
>> - object: split out functions relating to object store subsystem
>> - object-file: split out functions relating to index subsystem
>> - object-file: split up concerns of `HASH_*` flags
>> - object-file: split out functions relating to object store subsystem
>> - object-file: move `xmmap()` into "wrapper.c"
>> - object-file: move `git_open_cloexec()` to "compat/open.c"
>> - object-file: move `safe_create_leading_directories()` into "dir.c"
>> - Merge branch 'ps/object-wo-the-repository' into ps/object-file-cleanup
>> (this branch uses ps/object-wo-the-repository.)
>>
>> Code clean-up.
>>
>> Will merge to 'next'.
>> source: <20250411-pks-split-object-file-v2-0-2bea0c9033ae@pks.im>
>
> Let's wait a bit with this one. There's been a couple more review
> comments that I want to address before this is ready for next.
OK.
>> * rj/build-tweaks (2025-04-09) 13 commits
>> - config.mak.uname: set CSPRNG_METHOD to getrandom on Linux
>> - config.mak.uname: add arc4random to the cygwin build
>> - config.mak.uname: add sysinfo() configuration for cygwin
>> - builtin/gc.c: correct RAM calculation when using sysinfo
>> - config.mak.uname: add clock_gettime() to the cygwin build
>> - config.mak.uname: add HAVE_GETDELIM to the cygwin section
>> - config.mak.uname: only set NO_REGEX on cygwin for v1.7
>> - config.mak.uname: add a note about NO_STRLCPY for Linux
>> - Makefile: remove NEEDS_LIBRT build variable
>> - meson.build: set default help format to html on windows
>> - meson.build: only set build variables for non-default values
>> - Makefile: only set some BASIC_CFLAGS when RUNTIME_PREFIX is set
>> - meson.build: remove -DCURL_DISABLE_TYPECHECK
>>
>> Various build tweaks, including CSPRNG selection on some platforms.
>>
>> Comments?
>> source: <cover.1743859985.git.ramsay@ramsayjones.plus.com>
>
> I just reviewed this series. It looks mostly fine to me, but I do have
> one question regarding one of the Meson patches.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: aw/t9811-modernize, was Re: What's cooking in git.git (Apr 2025, #04; Tue, 15)
@ 2025-04-18 21:38 99% ` Junio C Hamano
2025-04-18 21:44 99% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2025-04-18 21:38 UTC (permalink / raw)
To: Jeff King; +Cc: Anthony Wang, git
Jeff King <peff@peff.net> writes:
> So I don't know if git-p4 got smarter, or what. But we should probably
> back out at least that part of the commit until we figure out what's
> going on (where "we" is somebody who cares a lot more about p4 than I
> do).
Yes, and there was another breakage in that 2-hunk patch in the
other hunk I sent out a fix for a few minutes ago.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: aw/t9811-modernize, was Re: What's cooking in git.git (Apr 2025, #04; Tue, 15)
2025-04-18 21:38 99% ` Junio C Hamano
@ 2025-04-18 21:44 99% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2025-04-18 21:44 UTC (permalink / raw)
To: Jeff King; +Cc: Anthony Wang, git
Junio C Hamano <gitster@pobox.com> writes:
> Jeff King <peff@peff.net> writes:
>
>> So I don't know if git-p4 got smarter, or what. But we should probably
>> back out at least that part of the commit until we figure out what's
>> going on (where "we" is somebody who cares a lot more about p4 than I
>> do).
>
> Yes, and there was another breakage in that 2-hunk patch in the
> other hunk I sent out a fix for a few minutes ago.
We seem to have quite a many ubuntu/linux test jobs, none of which
failed due to the obvious syntax error in t9811, which probalby
means we are not running p4 tests at all on any of our Linux jobs.
^ permalink raw reply [relevance 99%]
* Re: aw/t9811-modernize, was Re: What's cooking in git.git (Apr 2025, #04; Tue, 15)
@ 2025-04-22 14:50 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-04-22 14:50 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: Jeff King, Anthony Wang, git
Patrick Steinhardt <ps@pks.im> writes:
> I think the issue is where we put the resulting binaries: they get put
> into "$HOME/path", but the problem is that "$HOME" is different between
> "install-dependencies.sh" and "run-build-and-tests.sh" because the
> latter is executed as unprivileged user.
Yuck. Thanks for a clealy written explanation and the change.
Will queue.
>
> Something like the below (untested) patch should fix this.
>
> Patrick
>
> [1]: https://gitlab.com/gitlab-org/git/-/jobs/9760840184#L4002
> [2]: https://github.com/git/git/actions/runs/14526556290/job/40759119217#step:8:1814
> [3]: https://github.com/git/git/actions/runs/14526556290/job/40759119217#step:5:2190
>
> -- >8 --
>
> Subject: [PATCH] ci: fix p4d executable not being found on GitHub Actions
>
> Our tests for git-p4(1) depend on the p4d(1) and p4(1) executables to
> exist. As we require specific versions of those binaries which typically
> aren't available on common distributions, we install them manually via
> "ci/install-dependencies.sh".
>
> This script will put the binaries into "$CUSTOM_PATH", which gets
> defined by "ci/lib.sh" -- if not explicitly overridden, its value will
> be set to "$HOME/path". This causes issues though when running our tests
> as unprivileged user, as we do both in GitLab CI and GitHub Actions,
> because "$HOME" will be different when installing dependencies and when
> running the tests. Consequently, the downloaded binaries will not be
> found unless "$CUSTOM_PATH" is overridden to a common location.
>
> We already do this for GitLab CI, where it points to "/custom". Let's do
> the same for GitHub Actions so that Perforce-based tests are executed
> again.
>
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
> .github/workflows/main.yml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
> index 83ca8e4182b..412a9a5107b 100644
> --- a/.github/workflows/main.yml
> +++ b/.github/workflows/main.yml
> @@ -408,6 +408,7 @@ jobs:
> jobname: ${{matrix.vector.jobname}}
> CC: ${{matrix.vector.cc}}
> CI_JOB_IMAGE: ${{matrix.vector.image}}
> + CUSTOM_PATH: /custom
> runs-on: ubuntu-latest
> container: ${{matrix.vector.image}}
> steps:
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (May 2025, #03; Wed, 7)
@ 2025-05-08 13:28 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-05-08 13:28 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List, Moumita
Johannes Sixt <j6t@kdbg.org> writes:
> Am 08.05.25 um 03:26 schrieb Junio C Hamano:
>> * md/userdiff-bash-shell-function (2025-04-01) 1 commit
>> - userdiff: extend Bash pattern to cover more shell function forms
>>
>> The userdiff pattern for shell scripts has been updated to cope
>> with more bash-isms.
>>
>> Comments?
>> source: <20250330134018.9662-2-dhar61595@gmail.com>
>
> This round has room for improvement. I posted a review yesterday:
> https://lore.kernel.org/git/9d548d94-eed8-434a-a9ef-67df694c5c79@kdbg.org/
Yeah, I indeed saw your thoughtful review. Thanks for pointing this out.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (May 2025, #02; Mon, 5)
@ 2025-05-08 18:22 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-05-08 18:22 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: Eric Sunshine, Christian Couder, git
Patrick Steinhardt <ps@pks.im> writes:
> On Tue, May 06, 2025 at 01:50:09PM -0400, Eric Sunshine wrote:
>> On Tue, May 6, 2025 at 4:35 AM Christian Couder
>> >
>> > I am reviewing this series and it seems to me that it's possibly
>> > missing a fix for a leak that Eric Sunshine had found in a previous
>> > review round.
>>
>> In addition to the leak[1], I also have reservations[2] about the
>> "worktree: expose function to retrieve worktree names" patch.
>
> I've addressed both of these now in v5 of this patch series. Thanks!
I guess now all of the above is cleared in the updated iteration.
Thanks, all.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (May 2025, #06; Tue, 20)
@ 2025-05-21 14:55 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-05-21 14:55 UTC (permalink / raw)
To: Karthik Nayak; +Cc: git
Karthik Nayak <karthik.188@gmail.com> writes:
>> Will merge to 'next'?
>> source: <20250519-501-update-git-fetch-1-to-use-partial-transactions-v3-0-6cdfd4f769b9@gmail.com>
>
> Incase you missed the cover letter: I would say that while this can be
> merged to 'next', we should delay the merge to 'master' for after the
> 2.50 release since it can be disruptive. Mostly letting it bake for a
> longer time before hitting a major release.
What are the things you are so unsure about and guinea pigs who use
'next' as their daily driver should watch out for?
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (May 2025, #08; Tue, 27)
@ 2025-05-28 22:02 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-05-28 22:02 UTC (permalink / raw)
To: Jean-Noël AVILA; +Cc: git
Jean-Noël AVILA <jn.avila@free.fr> writes:
> Junio, I haven't seen your series about git-verify-* and others integrated.
> Are there any remaining points to be fixed?
Which ones? These ...
88ce8dfe29 git-daemon doc: update mark-up of synopsis option descriptions
914c549ac1 git-{var,write-tree} docs: update mark-up of synopsis option descriptions
7e7f47a488 git-verify-* doc: update mark-up of synopsis option descriptions
20e4e9ad0b git-var doc: fix usage of $ENV_VAR vs ENV_VAR
... are part of v2.50.0-rc0~9
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Apr 2025, #01; Mon, 7)
2025-04-09 16:01 99% ` Junio C Hamano
@ 2025-06-05 12:51 99% ` Junio C Hamano
1 sibling, 1 reply; 200+ results
From: Junio C Hamano @ 2025-06-05 12:51 UTC (permalink / raw)
To: Philippe Blain; +Cc: git
Philippe Blain <levraiphilippeblain@gmail.com> writes:
>> * pb/status-rebase-fixes (2025-03-28) 4 commits
> ...
> Yes, I will address the reviewer feedback and send a new version.
Perhaps you got busy after sending this, and I do not mean to rush
anybody (as we are now in pre-release freeze anyway). I'm in the
process of decluttering my tree, and I'll drop the topic soonish.
These topic lost for decluttering can come back by sending updated
iteration, of course ;-).
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Apr 2025, #01; Mon, 7)
@ 2025-06-05 18:29 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-06-05 18:29 UTC (permalink / raw)
To: Philippe Blain; +Cc: git
Philippe Blain <levraiphilippeblain@gmail.com> writes:
> Hi Junio,
>
> Yes, I got pretty busy (I’m on parental leave!)
>
> Feel free to drop it and I’ll resubmit a new version in the coming months.
>
> Philippe.
Thanks. Enjoy your time-off (and your new family member, of
course).
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jun 2025, #08; Mon, 23)
@ 2025-06-25 15:03 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-06-25 15:03 UTC (permalink / raw)
To: Karthik Nayak; +Cc: git
Karthik Nayak <karthik.188@gmail.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> * kn/fetch-push-bulk-ref-update (2025-05-19) 4 commits
>> - receive-pack: use batched reference updates
>> - send-pack: fix memory leak around duplicate refs
>> - fetch: use batched reference updates
>> - refs: add function to translate errors to strings
>> (this branch is used by kn/fetch-push-bulk-ref-update-fixup.)
>>
>> "git push" and "git fetch" are taught to update refs in batches to
>> gain performance.
>>
>> Tentatively kicked out of 'next' to give its fix-up topic a chance to reboot.
>> source: <20250519-501-update-git-fetch-1-to-use-partial-transactions-v3-0-6cdfd4f769b9@gmail.com>
>>
>>
>> * kn/fetch-push-bulk-ref-update-fixup (2025-06-20) 3 commits
>> - receive-pack: handle reference deletions separately
>> - refs/files: skip updates with errors in batched updates
>> - Merge branch 'kn/fetch-push-bulk-ref-update' into kn/fetch-push-bulk-ref-update-fixup
>> (this branch uses kn/fetch-push-bulk-ref-update.)
>>
>> Additional fixes to the base topic.
>>
>> Comments?
>> source: <20250620-6769-address-test-failures-in-the-next-branch-caused-by-batched-reference-updates-v5-0-f35ee6b59a82@gmail.com>
>>
>
> This was reviewed by Christian and you. The latest version addresses all
> the comments, do we need some more eyes here?
OK, then. Let's move the commits from the latter on top of the former
and mark the former for 'next'.
Thanks!
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jun 2025, #08; Mon, 23)
@ 2025-06-25 16:29 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-06-25 16:29 UTC (permalink / raw)
To: Phillip Wood; +Cc: git, Øystein Walle
Phillip Wood <phillip.wood123@gmail.com> writes:
> On 24/06/2025 01:57, Junio C Hamano wrote:
>> * ow/rebase-verify-insn-fmt-before-initializing-state (2025-06-09) 1
>> commit
>> - rebase: write script before initializing state
>> "git rebase -i" with bogus rebase.instructionFormat configuration
>> failed to produce the todo file after recording the state files,
>> leading to confused "git status"; this has been corrected.
>> Comments?
>> cf. <20250609221055.136074-1-oystwa@gmail.com>
>> source: <20250609221055.136074-1-oystwa@gmail.com>
>
> I think we're expecting a re-roll
> cf. <7e796844-97e2-4b45-a76e-4c1fcb1da3ae@gmail.com>
Yeah, what I wrote there is a nonsense, referring to the entire
thread (which already is available as "source"). Besides, the patch
didn't have a sign-off.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jul 2025, #02; Mon, 7)
@ 2025-07-09 15:37 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-07-09 15:37 UTC (permalink / raw)
To: René Scharfe; +Cc: git
René Scharfe <l.s.r@web.de> writes:
> On 7/8/25 2:11 AM, Junio C Hamano wrote:
>> * rs/parse-options-precision (2025-06-29) 6 commits
>> - parse-options: add precision handling for OPTION_COUNTUP
>> - parse-options: add precision handling for OPTION_BITOP
>> - parse-options: add precision handling for OPTION_NEGBIT
>> - parse-options: add precision handling for OPTION_BIT
>> - parse-options: add precision handling for OPTION_SET_INT
>> - parse-options: add precision handling for PARSE_OPT_CMDMODE
>>
>> Define .precision to more canned parse-options type to avoid bugs
>> coming from using a variable with a wrong type to capture the
>> parsed values.
>>
>> Will merge to 'next'?
>> source: <cf5cd57d-733f-4239-80f8-23bdc1523ab2@web.de>
> Will send v2 shortly.
Thanks for stopping me.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jul 2025, #02; Mon, 7)
@ 2025-07-09 16:26 99% ` Junio C Hamano
1 sibling, 0 replies; 200+ results
From: Junio C Hamano @ 2025-07-09 16:26 UTC (permalink / raw)
To: Carlo Marcelo Arenas Belón; +Cc: git, j6t, phillip.wood123
Carlo Marcelo Arenas Belón <carenas@gmail.com> writes:
> On Mon, Jul 07, 2025 at 05:11:12PM -0800, Junio C Hamano wrote:
>>
>> * cb/daemon-reap-children (2025-06-26) 4 commits
>> - daemon: explicitly allow EINTR during poll()
>> - daemon: use sigaction() to install child_handler()
>> - compat/mingw: allow sigaction(SIGCHLD)
>> - compat/posix.h: track SA_RESTART fallback
>>
>> Futz with SIGCHLD handling in "git daemon".
>>
>> Stalled?
>> cf. <dba9ae0d-1e43-4345-a7ec-b57a07d45a07@gmail.com>
>> source: <pull.2002.v3.git.git.1750927988.gitgitgadget@gmail.com>
>
> I don't think so, but definitely missing reviews (specially for patch 2)
That is what I called Stalled---stalling does not have to be due to
author's inaction.
> and slightly controversial.
> ...
> On the rationale on why this is independently useful, note that we are
> currently relying in at least 2 "unspecified" behaviours:
>
> 1) using signal() means that it is implementation defined if SA_RESTART
> will be enabled or not for that signal, and
> 2) if SA_RESTART is enabled, it is implementation defined if we might get
> interrupted in poll().
>
> both are resolved by using sigaction() instead, and it is up to us to
> decide if SA_RESTART is enabled or not (which might make patch 4 obsolete
> if we decide against).
>
> Carlo
>
> CC: Johannes Sixt on feedback for SIGCHLD in mingw which uses 17 instead
> of 22 (cygwin and others) and therefore seem to cause signal to err
> without setting errno as it should.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jul 2025, #02; Mon, 7)
@ 2025-07-10 0:01 99% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2025-07-10 0:01 UTC (permalink / raw)
To: Taylor Blau; +Cc: Jeff King, Elijah Newren, git
Taylor Blau <me@ttaylorr.com> writes:
>> * tb/midx-avoid-cruft-packs (2025-06-23) 9 commits
>> - repack: exclude cruft pack(s) from the MIDX where possible
>> - pack-objects: introduce '--stdin-packs=follow'
>> - pack-objects: swap 'show_{object,commit}_pack_hint'
>> - pack-objects: fix typo in 'show_object_pack_hint()'
>> - pack-objects: perform name-hash traversal for unpacked objects
>> - pack-objects: declare 'rev_info' for '--stdin-packs' earlier
>> - pack-objects: factor out handling '--stdin-packs'
>> - pack-objects: limit scope in 'add_object_entry_from_pack()'
>> - pack-objects: use standard option incompatibility functions
>>
>> "pack-objects" has been taught to avoid pointing into objects in
>> cruft packs from midx.
>>
>> Will merge to 'next'?
>> source: <cover.1750717921.git.me@ttaylorr.com>
>
> I think that this one is ready to go. Since Elijah and Peff last
> reviewed it, it hasn't changed substantially (other than a few
> bugfix-related changes that were discovered while rolling this out at
> GitHub).
>
> The series has been running on GitHub's production infrastructure for
> the last month or two without issue, so I think this is good from a
> stability perspective.
>
> I've CC'd Elijah and Peff here, since they were the last two to review
> the series, but I don't think that they have any objections to this
> moving along.
OK. As they both seem to be active, let me wait for a bit and then
mark it for 'next' unless we hear anything unexpected.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jul 2025, #02; Mon, 7)
@ 2025-07-10 4:24 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-07-10 4:24 UTC (permalink / raw)
To: brian m. carlson; +Cc: git
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
> On 2025-07-08 at 00:11:12, Junio C Hamano wrote:
>> * bc/use-sha256-by-default-in-3.0 (2025-07-01) 11 commits
>> - Enable SHA-256 by default in breaking changes mode
>> - help: add a build option for default hash
>> - t5300: choose the built-in hash outside of a repo
>> - t4042: choose the built-in hash outside of a repo
>> - t1007: choose the built-in hash outside of a repo
>> - t: default to compile-time default hash if not set
>> - setup: use the default algorithm to initialize repo format
>> - Use legacy hash for legacy formats
>> - builtin: use default hash when outside a repository
>> - hash: add a constant for the legacy hash algorithm
>> - hash: add a constant for the default hash algorithm
>>
>> Prepare to flip the default hash function to SHA-256.
>>
>> Will merge to 'next'?
>> source: <20250701212237.766774-1-sandals@crustytoothpaste.net>
>
> Patrick Steinhardt thought this looked fine and I didn't have any
> intentions for another round, so I suspect it's ready.
No worries. During today's integration cycle, I read them over once
again, moved it up in the merge order in preparation for marking it
for 'next' [*].
> Of course, if people disagree and would like more changes, please say
> so.
Surely.
Thanks.
[Footnote]
* The range master..seen is separated into two parts by a merge
commit called 'jch', which is usually the version I use for my
daily work, and I do not merge anything down to 'next' until the
topic has spent at least half a day in 'jch'.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jul 2025, #02; Mon, 7)
@ 2025-07-10 4:24 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-07-10 4:24 UTC (permalink / raw)
To: Elijah Newren; +Cc: Taylor Blau, Jeff King, git
Elijah Newren <newren@gmail.com> writes:
> On Wed, Jul 9, 2025 at 5:01 PM Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Taylor Blau <me@ttaylorr.com> writes:
>>
>> >> * tb/midx-avoid-cruft-packs (2025-06-23) 9 commits
>> >> - repack: exclude cruft pack(s) from the MIDX where possible
>> >> - pack-objects: introduce '--stdin-packs=follow'
>> >> - pack-objects: swap 'show_{object,commit}_pack_hint'
>> >> - pack-objects: fix typo in 'show_object_pack_hint()'
>> >> - pack-objects: perform name-hash traversal for unpacked objects
>> >> - pack-objects: declare 'rev_info' for '--stdin-packs' earlier
>> >> - pack-objects: factor out handling '--stdin-packs'
>> >> - pack-objects: limit scope in 'add_object_entry_from_pack()'
>> >> - pack-objects: use standard option incompatibility functions
>> >>
>> >> "pack-objects" has been taught to avoid pointing into objects in
>> >> cruft packs from midx.
>> >>
>> >> Will merge to 'next'?
>> >> source: <cover.1750717921.git.me@ttaylorr.com>
>> >
>> > I think that this one is ready to go. Since Elijah and Peff last
>> > reviewed it, it hasn't changed substantially (other than a few
>> > bugfix-related changes that were discovered while rolling this out at
>> > GitHub).
>> >
>> > The series has been running on GitHub's production infrastructure for
>> > the last month or two without issue, so I think this is good from a
>> > stability perspective.
>> >
>> > I've CC'd Elijah and Peff here, since they were the last two to review
>> > the series, but I don't think that they have any objections to this
>> > moving along.
>>
>> OK. As they both seem to be active, let me wait for a bit and then
>> mark it for 'next' unless we hear anything unexpected.
>>
>> Thanks.
>
> Yep, I think this version is good to merge to next; thanks.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jul 2025, #02; Mon, 7)
@ 2025-07-10 15:30 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-07-10 15:30 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Carlo Marcelo Arenas Belón, git, phillip.wood123
Johannes Sixt <j6t@kdbg.org> writes:
> Am 10.07.25 um 06:25 schrieb Carlo Marcelo Arenas Belón:
>> In d28250654f (Windows: Fix signal numbers, 2009-01-22), the value for
>> SIGCHLD was changed from 0 to 17 mentioning some sort of POSIX system.
>>
>> the relevance comes that if I build a program in Windows that calls
>> `signal(SIGCHLD)` using that number I get an error back, but nothing
>> on errno, but if the number would be instead 20, like in Cygwin/macOS
>> suddenly the behaviour changes and we get the expected EINVAL(20) in errno.
>
>> So do you have any objection on changing the value (which should be otherwise
>> unused, and irrelevanted as you pointed out) to 20 then?
>
> I do not object to change the number. Nevertheless, I would like to
> understand why it makes a difference.
Yeah, whoever writes the commit that changes the value needs to
explain why the change matters, and where the differences come from
in the proposed log message.
Thanks, all.
^ permalink raw reply [relevance 99%]
* Re: [-SPAM-] What's cooking in git.git (Jul 2025, #03; Wed, 9)
@ 2025-07-11 15:00 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-07-11 15:00 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: Ramsay Jones, git
Patrick Steinhardt <ps@pks.im> writes:
> I'm happy to just drop the patch and let you handle the regression.
>
> There aren't any dependencies between the patches in this series, so
> it's as easy as removing the patch. Junio, do you want me to resend the
> series with the patch dropped or will you drop the patch on your side?
Will do. As always, thanks for working well together.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jul 2025, #03; Wed, 9)
@ 2025-07-11 16:01 99% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2025-07-11 16:01 UTC (permalink / raw)
To: Ayush Chandekar; +Cc: git
Ayush Chandekar <ayu.chandekar@gmail.com> writes:
> Hi Junio,
>
> On Thu, Jul 10, 2025 at 1:36 PM Junio C Hamano <gitster@pobox.com> wrote:
> [snip]
>
>>
>> * ac/deglobal-sparse-variables (2025-06-30) 3 commits
>> - environment: remove the global variable 'sparse_expect_files_outside_of_patterns'
>> - environment: move access to "core.sparsecheckoutcone" into repo_settings
>> - environment: move access to "core.sparsecheckout" into repo_settings
>>
>> Two global variables related to sparse checkout have been moved to
>> the repository settings structure.
>>
>> Expecting a response.
>> cf. <17b7f51c-0c3d-4d63-a501-47ce829f7345@gmail.com>
>> cf. <xmqqbjpuqkrj.fsf@gitster.g>
>> source: <cover.1751309770.git.ayu.chandekar@gmail.com>
>>
>>
>
> I have responded to your message about keeping the topic in 'seen' or not: [1]
It is not an issue for which a response is being expected, though.
Has the issue Phillip pointed out been resolved in the discussion?
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jul 2025, #03; Wed, 9)
@ 2025-07-11 18:34 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-07-11 18:34 UTC (permalink / raw)
To: Ayush Chandekar; +Cc: git
Ayush Chandekar <ayu.chandekar@gmail.com> writes:
>> >> Expecting a response.
>> >> cf. <17b7f51c-0c3d-4d63-a501-47ce829f7345@gmail.com>
>> >> cf. <xmqqbjpuqkrj.fsf@gitster.g>
>> >> source: <cover.1751309770.git.ayu.chandekar@gmail.com>
>> >>
>> >>
>> >
>> > I have responded to your message about keeping the topic in 'seen' or not: [1]
>>
>> It is not an issue for which a response is being expected, though.
>> Has the issue Phillip pointed out been resolved in the discussion?
>
> Really sorry about that, I will address to his issue.
Heh, don't be sorry. Miscommunication happens.
And thanks for working on this topic.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jul 2025, #04; Mon, 14)
@ 2025-07-15 17:39 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-07-15 17:39 UTC (permalink / raw)
To: Karthik Nayak; +Cc: git
Karthik Nayak <karthik.188@gmail.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> * kn/for-each-ref-skip (2025-07-11) 4 commits
>> - for-each-ref: introduce a '--start-after' option
>> - refs: selectively set prefix in the seek functions
>> - ref-cache: remove unused function 'find_ref_entry()'
>> - refs: expose `ref_iterator` via 'refs.h'
>>
>> "git for-each-ref" learns "--skip-until" option to help
>> applications that want to page its output.
>>
>> Will merge to 'next'.
>> cf. <CAP8UFD06KKF0A0WjBSw77A7fKp_pGJGVyw-OPd8-X92h=RSF+w@mail.gmail.com>
>> source: <20250711-306-git-for-each-ref-pagination-v4-0-ed3303ad5b89@gmail.com>
>>
>
> Christian left some comments, so I've pushed a new version here.
Thanks, will take a look.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jul 2025, #04; Mon, 14)
@ 2025-07-15 17:43 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-07-15 17:43 UTC (permalink / raw)
To: Carlo Marcelo Arenas Belón; +Cc: git
Carlo Marcelo Arenas Belón <carenas@gmail.com> writes:
> On Mon, Jul 14, 2025 at 01:53:36PM -0800, Junio C Hamano wrote:
>>
>> * bs/config-mak-freebsd (2025-07-02) 2 commits
>> (merged to 'next' on 2025-07-07 at d6761aa225)
>> + build: retire NO_UINTMAX_T
>> + config.mak.uname: set NO_MEMMEM only for functional version
>>
>> Drop FreeBSD 4 support and assume we are at least at FreeBSD 6 with
>> memmem() supported.
>>
>> source: <20250702093736.36074-1-carenas@gmail.com>
>
> Apologies for not mentioning earlier, but the minimum version of
> FreeBSD supported with memmem() by this patch is 12, not 6.
Thanks, I realized the same and updated the draft release notes with
that ;-)
>> * cb/meson-avoid-broken-macos-pcre2 (2025-07-13) 1 commit
>> - meson: disable PCRE2 dependency by default in macOS
>>
>> Build fix for macOS.
>>
>> Will merge to 'next'.
>> source: <20250713174807.32444-1-carenas@gmail.com>
>
> Better hold, as there is a better option posted with a v4 in
> 20250715114407.37955-1-carenas@gmail.com but more importantly
> the discussion is still open and might require further changes.
Again, thanks. I saw the exchange and your latest round with Eli's
input is what I'll be queuing for today's integration cycle, without
merging it down to 'next' just yet.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jul 2025, #06; Tue, 22)
@ 2025-07-23 15:48 99% ` Junio C Hamano
1 sibling, 0 replies; 200+ results
From: Junio C Hamano @ 2025-07-23 15:48 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
Patrick Steinhardt <ps@pks.im> writes:
> I think the only commit that really needs review is the last one that
> fixes the sign comparison warnings. As long as people are fine with that
> commit I'm happy to have it merged.
Heh, it is very interesting that just 10 hours after you said "only
this step, I find it fishy", you'd actually have to send out a new
iteration ;-)
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jul 2025, #06; Tue, 22)
@ 2025-07-23 16:46 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-07-23 16:46 UTC (permalink / raw)
To: Eric Sunshine; +Cc: git
Eric Sunshine <sunshine@sunshineco.com> writes:
> On Tue, Jul 22, 2025 at 8:11 PM Junio C Hamano <gitster@pobox.com> wrote:
>> * hl/test-helper-fd-close (2025-07-22) 2 commits
>> - t/helper/test-delta: fix possible resource leak and ensure safe cleanup
>> - t/helper/test-truncate: close file descriptor after truncation
>>
>> A few file descriptors left unclosed upon program completion in a
>> few test helper programs are now closed.
>>
>> Comments?
>> source: <20250722174102.1876197-1-lhywkd22@gmail.com>
>
> I left comments[*] on patch [2/2]. Although the intention of the
> change seems reasonable (patching holes in the existing "cleanup" of
> `fd`), I have concerns that the commit message is misleading, and
> (more importantly) that the patch itself is flawed. As such, I think a
> reroll is warranted.
>
> [*]: https://lore.kernel.org/git/CAPig+cR-r=CeEaSTeWsX00MLCSRJUUVXMUWS6Ui-HQcR_qMGJA@mail.gmail.com/
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jul 2025, #06; Tue, 22)
@ 2025-07-23 17:17 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-07-23 17:17 UTC (permalink / raw)
To: Phillip Wood; +Cc: Patrick Steinhardt, git
Phillip Wood <phillip.wood123@gmail.com> writes:
>> I think the only commit that really needs review is the last one
>> that
>> fixes the sign comparison warnings. As long as people are fine with that
>> commit I'm happy to have it merged.
>
> I think that commit needs a re-roll
> c.f. <2b914b60-3417-4a49-b545-3109c9a05257@gmail.com>. I haven't
> looked at the rest of the patches but I like the general idea behind
> this series.
Thanks. I looked at the rest before marking it with the "next?" label
and they looked OK.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jul 2025, #07; Thu, 24)
@ 2025-07-26 17:45 99% ` Junio C Hamano
1 sibling, 0 replies; 200+ results
From: Junio C Hamano @ 2025-07-26 17:45 UTC (permalink / raw)
To: Usman Akinyemi; +Cc: git
Usman Akinyemi <usmanakinyemi202@gmail.com> writes:
> On Thu, Jul 24, 2025 at 10:48 PM Junio C Hamano <gitster@pobox.com> wrote:
>>
>...
Administrivia. NEVER QUOTE SO MANY LINES from the original if your
response has nothing to say about them. Remove the part you are not
commenting on and leave only the relevant parts that you are about
to respond, and then say your thing.
>> * ua/t1517-short-help-tests (2025-07-21) 2 commits
>> . t5200: move `update-server-info -h` test from t1517
>> . t/t1517: automate `git subcmd -h` tests outside a repository
>>
>> Test shuffling.
>>
>> Seems to introduce a few "todo passed" when merged to 'seen'.
> Hi Junio,
>
> Is there something that needs to be done here ?
>
> Also, some tests still have both the `git subcmd -h` test outside and
> inside together
> and the first patch of this series already tests for all the outside repo.
>
> Should I send them as an update version with this patch or wait till
> this gets integrated ?
As I wrote, with this merged to 'seen', we see "todo passed" in the
test result. You'd want to dig to the root cause of the issue and
update the patches if needed.
> Thank you
>
>> source: <20250721115519.140361-1-usmanakinyemi202@gmail.com>
>>
>>
Also do not leave the original that you are not going to refer to
after you finish saying what you wanted to say.
>> * kn/for-each-ref-skip (2025-07-23) 6 commits
>> - ref-iterator-seek: correctly initialize the prefix_state for a new level
>>...
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jul 2025, #07; Thu, 24)
@ 2025-07-27 0:00 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-07-27 0:00 UTC (permalink / raw)
To: D. Ben Knoble; +Cc: Usman Akinyemi, git
"D. Ben Knoble" <ben.knoble@gmail.com> writes:
>> Is there something that needs to be done here ?
>
> I would interpret "introduce a few 'todo passed' when merged to
> 'seen'" to mean that a few test_expect_failure's are now passing and
> need updating.
Thanks for helping.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jul 2025, #08; Mon, 28)
@ 2025-07-29 2:05 99% ` Junio C Hamano
1 sibling, 0 replies; 200+ results
From: Junio C Hamano @ 2025-07-29 2:05 UTC (permalink / raw)
To: git
Junio C Hamano <gitster@pobox.com> writes:
> * lo/repo-info (2025-07-21) 5 commits
> . repo: add the --format flag
> . repo: add field layout.shallow
> . repo: add field layout.bare
> . repo: add the field references.format
> . repo: declare the repo command
>
> A new subcommand "git repo" gives users a way to grab various
> repository characteristics.
>
> Expecting a reroll.
> Ejected as it seems to break CI when merged to 'seen'.
> source: <20250722002835.33428-1-lucasseikioshiro@gmail.com>
Sorry for a false alarm.
cf. https://github.com/git/git/actions/runs/16584268807
All topics in flight including this one, when excluding the
tc/last-modified topic, seems to be fine in 'seen'.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jul 2025, #08; Mon, 28)
@ 2025-07-29 15:30 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-07-29 15:30 UTC (permalink / raw)
To: Toon Claes; +Cc: git
Toon Claes <toon@iotcl.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> * ps/object-file-wo-the-repository (2025-07-16) 17 commits
>> - object-file: get rid of `the_repository` in index-related functions
>> - object-file: get rid of `the_repository` in `force_object_loose()`
>> - object-file: get rid of `the_repository` in `read_loose_object()`
>> - object-file: get rid of `the_repository` in loose object iterators
>> - object-file: remove declaration for `for_each_file_in_obj_subdir()`
>> - object-file: inline `for_each_loose_file_in_objdir_buf()`
>> - object-file: get rid of `the_repository` when writing objects
>> - odb: introduce `odb_write_object()`
>> - loose: write loose objects map via their source
>> - object-file: get rid of `the_repository` in `finalize_object_file()`
>> - object-file: get rid of `the_repository` in `loose_object_info()`
>> - object-file: get rid of `the_repository` when freshening objects
>> - object-file: inline `check_and_freshen()` functions
>> - object-file: get rid of `the_repository` in `has_loose_object()`
>> - object-file: stop using `the_hash_algo`
>> - object-file: fix -Wsign-compare warnings
>> - Merge branch 'ps/object-store' into ps/object-file-wo-the-repository
>>
>> Reduce implicit assumption and dependence on the_repository in the
>> object-file subsystem.
>>
>> Comments?
>> source: <20250717-pks-object-file-wo-the-repository-v2-0-36d2cd6c700e@pks.im>
>
> I did do a thorough review on v1 in the past and did a little less
> thorough review on v2, but the range-diff is tiny anyway.
>
> Version two removes the controversial commits around global config. With
> this, this patch series is not able to drop USE_THE_REPOSITORY_VARIABLE
> from the object-file.c yet. Nevertheless, the whole series is still
> worthwhile to me.
Thanks, I do recall reading your earlier reviews and they looked
sensible.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Aug 2025, #01; Sun, 3)
@ 2025-08-04 14:29 99% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2025-08-04 14:29 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Jeff King
Patrick Steinhardt <ps@pks.im> writes:
> On Mon, Aug 04, 2025 at 01:23:40AM -0700, Junio C Hamano wrote:
>> * ps/remote-rename-fix (2025-07-31) 7 commits
>> - builtin/remote: only iterate through refs that are to be renamed
>> - builtin/remote: rework how remote refs get renamed
>> - builtin/remote: determine whether refs need renaming early on
>> - builtin/remote: fix sign comparison warnings
>> - refs: simplify logic when migrating reflog entries
>> - refs: pass refname when invoking reflog entry callback
>> - Merge branch 'ps/reflog-migrate-fixes' into ps/remote-rename-fix
>> (this branch uses ps/reflog-migrate-fixes.)
>>
>> "git remote rename origin upstream" failed to move origin/HEAD to
>> upstream/HEAD when origin/HEAD is unborn and performed other
>> renames extremely inefficiently, which has been corrected.
>>
>> Will merge to 'next'?
>> source: <20250731-pks-remote-rename-improvements-v2-0-dda6f083674d@pks.im>
>
> I've sent one more version of this patch series for a couple of final
> finishing touches. If Peff is happy with that version I'm happy to see
> it merged.
Hmph, you have?
>
>> * ps/reflog-migrate-fixes (2025-07-29) 9 commits
>> - refs: fix invalid old object IDs when migrating reflogs
>> - refs: stop unsetting REF_HAVE_OLD for log-only updates
>> - refs/files: detect race when generating reflog entry for HEAD
>> - refs: fix identity for migrated reflogs
>> - ident: fix type of string length parameter
>> - builtin/reflog: implement subcommand to write new entries
>> - refs: export `ref_transaction_update_reflog()`
>> - builtin/reflog: improve grouping of subcommands
>> - Documentation/git-reflog: convert to use synopsis type
>> (this branch is used by ps/remote-rename-fix.)
>>
>> "git refs migrate" to migrate the reflog entries from a refs
>> backend to another had a handful of bugs squashed.
>>
>> Will merge to 'next'?
>> source: <20250729-pks-reflog-append-v3-0-9614d310f073@pks.im>
>
> I'm happy with this version, so if the above goes in I think this one
> here can also be merged.
You have an update for this one. Perhaps your comments are swapped
between these two topics?
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Aug 2025, #01; Sun, 3)
@ 2025-08-05 0:34 99% ` Junio C Hamano
0 siblings, 2 replies; 200+ results
From: Junio C Hamano @ 2025-08-05 0:34 UTC (permalink / raw)
To: Jeff King; +Cc: Patrick Steinhardt, git
Jeff King <peff@peff.net> writes:
> I just left a rather lengthy review of the split-HEAD patch in v4. I
> think hit has a few bugs that we need to address.
>
> I'm not sure if the right answer is to just go back to the v3 version
> that simply rejected the racy HEAD update (since that's more or less
> what happens now and nobody complains).
>
> If we do want to stick with the "silently skip the racy HEAD update"
> strategy from v4, I left some fixes there. But I'd worry more about
> maintainability and regressions in the future. I'm not sure if my hacky
> "pretend the HEAD is this for splitting" patch is something we'd want to
> carry or not. But if so, I think we could at least get a little coverage
> in the test suite.
Between the "honestry admit we failed and reject" and "silently
pretend nothing bad happened", I'd have to say that the former may
be more preferrable, and I hope people would agree.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Aug 2025, #01; Sun, 3)
@ 2025-08-05 10:24 99% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2025-08-05 10:24 UTC (permalink / raw)
To: D. Ben Knoble; +Cc: git
"D. Ben Knoble" <ben.knoble@gmail.com> writes:
> .... This is true whether I use
> my copy of the topic or the one you publish (4c8db1e55c (builtin: also
> setup gently for --help-all, 2025-08-03)).
I think the breakage I saw was while testing the 'seen' branch as a
whole, so there may be some interactions with other topics. IIRC,
it was running "git repo --help-all" when I saw the complaints.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Aug 2025, #01; Sun, 3)
@ 2025-08-05 17:08 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-08-05 17:08 UTC (permalink / raw)
To: Jeff King; +Cc: Patrick Steinhardt, git
Jeff King <peff@peff.net> writes:
> I think I don't think it's pretending that nothing bad happened, though.
> The user did not ask us to update HEAD, and we are able to fill their
> original request completely. So there really was nothing bad that
> happened.
>
> To me the options are "try to do the best thing in a racy situation,
> even though it almost never happens and will be complex and somewhat
> untested" vs "do the simple and stupid thing that does not happen enough
> for anyone to care too much".
OK. I still prefer the latter ;-)
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Aug 2025, #01; Sun, 3)
@ 2025-08-05 17:10 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-08-05 17:10 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: Jeff King, git
Patrick Steinhardt <ps@pks.im> writes:
> So with that knowledge I'd rather do the safe thing and abort the
> transaction. It requires less hard-to-test logic and feels safer
> overall.
>
> If we agree on that I can send a final reroll that reverts back to the
> logic we had in v3, which did abort the transaction.
I guess both you and Peff also prefer code that is more maintainable
and easier to reason about, and I am with you two, so let's go back
to the approach of v3.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Aug 2025, #02; Mon, 4)
@ 2025-08-05 18:03 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-08-05 18:03 UTC (permalink / raw)
To: Toon Claes; +Cc: git, Justin Tobler
Toon Claes <toon@iotcl.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> * jt/archive-zip-deflate-fix (2025-08-02) 1 commit
>> (merged to 'next' on 2025-08-04 at 4444b611dc)
>> + archive: flush deflate stream until Z_STREAM_END
>>
>> The deflate codepath in "git archive --format=zip" had a
>> longstanding bug coming from misuse of zlib API, which has been
>> corrected.
>>
>> Will merge to 'master'.
>> source: <20250802220803.95137-1-jltobler@gmail.com>
>
> I see this was merged into 'next' with 4444b611dc (Merge branch
> 'jt/archive-zip-deflate-fix' into next, 2025-08-04), but was reverted
> again in 5297b08916 (Revert "Merge branch 'jt/archive-zip-deflate-fix'
> into next", 2025-08-04)
>
> The fix in this patch definitely was the correct way forward, and it
> fixed the issue at hand. So I don't think it should have been reverted.
>
> I've sent a review and some patches in response, suggesting for an
> alternative fix. I'm not claiming my fix is better, and it might
> introduce other bug. I don't even know if the changes are even required.
The intention on my part was that the merge was premature before
other people expressed their thoughts. Perhaps the list may decide
that "we must loop around git_deflate() until we see STREAM_END" is
sufficient, in which case I'll merge it back again.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Aug 2025, #01; Sun, 3)
@ 2025-08-05 19:06 99% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2025-08-05 19:06 UTC (permalink / raw)
To: D. Ben Knoble; +Cc: git, Lucas Seiki Oshiro
"D. Ben Knoble" <ben.knoble@gmail.com> writes:
> With apologies for the mail noise, but I can't seem to reproduce any
> failures here on 371c45b569 (Merge branch 'dk/help-all' into seen,
> 2025-08-04), which is the latest seen I can find.
When I report a public CI failure, I'd try to give an exact URL, but
otherwise the failure would have been seen in my local environment,
and because I tend to refrain from pushing out a know-to-be-broken
tree, it is unsurprising if 371c45b569 did not fail.
That commit does not have lo/repo-info, I suspect. I didn't know
exactly which topic was causing, but the error was observed when
"repo --help-all" was given, so perhaps some interactions between
these two topics.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Aug 2025, #01; Sun, 3)
@ 2025-08-06 18:34 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-08-06 18:34 UTC (permalink / raw)
To: Lucas Seiki Oshiro; +Cc: D. Ben Knoble, git
Lucas Seiki Oshiro <lucasseikioshiro@gmail.com> writes:
>>
>> When I report a public CI failure, I'd try to give an exact URL, but
>> otherwise the failure would have been seen in my local environment,
>> and because I tend to refrain from pushing out a know-to-be-broken
>> tree, it is unsurprising if 371c45b569 did not fail.
>>
>> That commit does not have lo/repo-info, I suspect. I didn't know
>> exactly which topic was causing
>
> Yeah, I forgot to check the CI before I sent the last version. My bad,
> I'm sorry for this. I'll be more careful next time.
>
>> but the error was observed when
>> "repo --help-all" was given, so perhaps some interactions between
>> these two topics.
>
> However, after merging my local repo-info-v7 onto 371c45b569 in my local
> environment, I can execute `git repo --help-all` without any errors.
The breakage reported was about some leaks, and not about "does the
end-user observe any error when the command runs?".
> I
> also pushed this merge to GitHub [1], the only fails were directly related
> to my branch (some tests that I wrote and some leaks).
And it is not surprising, when these two were merged to 'seen',
leaks in your topic were triggering failures.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Aug 2025, #02; Mon, 4)
@ 2025-08-06 21:18 99% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2025-08-06 21:18 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: git, Patrick Steinhardt
SZEDER Gábor <szeder.dev@gmail.com> writes:
> Before merging please make sure that the topic can be built on its
> own. Currently all of its commits, including the merge commit the
> topic is based on, fail to build because:
>
> $ git log --oneline -1
> fc33fe7eff (HEAD) Merge branch 'ps/reflog-migrate-fixes' into ps/remote-rename-fix
> $ make
> CC builtin/reflog.o
> builtin/reflog.c:7:10: fatal error: object-store.h: No such file or directory
> 7 | #include "object-store.h"
> | ^~~~~~~~~~~~~~~~
> compilation terminated.
> make: *** [Makefile:2817: builtin/reflog.o] Error 1
The joy of having too many moving parts X-<.
Thanks for catching.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Aug 2025, #02; Mon, 4)
@ 2025-08-07 15:22 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-08-07 15:22 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: SZEDER Gábor, git
Patrick Steinhardt <ps@pks.im> writes:
> On Wed, Aug 06, 2025 at 02:18:34PM -0700, Junio C Hamano wrote:
>> SZEDER Gábor <szeder.dev@gmail.com> writes:
>>
>> > Before merging please make sure that the topic can be built on its
>> > own. Currently all of its commits, including the merge commit the
>> > topic is based on, fail to build because:
>> >
>> > $ git log --oneline -1
>> > fc33fe7eff (HEAD) Merge branch 'ps/reflog-migrate-fixes' into ps/remote-rename-fix
>> > $ make
>> > CC builtin/reflog.o
>> > builtin/reflog.c:7:10: fatal error: object-store.h: No such file or directory
>> > 7 | #include "object-store.h"
>> > | ^~~~~~~~~~~~~~~~
>> > compilation terminated.
>> > make: *** [Makefile:2817: builtin/reflog.o] Error 1
>>
>> The joy of having too many moving parts X-<.
>>
>> Thanks for catching.
>
> I guess what I learned is that I'll refrain from building on top of a
> topic that hasn't hit "next" yet from now on. I knew it was a going to
> become a bit painful, but I guess it's even more so than I expected.
As long as the base topic is reasonably stable, having to recreate
the base merge(s---there have been cases where a topic depended on
multiple in-flight topics) and rebasing the existing dependign topic
on top of the updated base was not _too_ painful. In addition to
rerere, I use machinery to remember and reuse necessary semantic
conflict resolution that was done once (which is used to rebuild
'seen' on top of 'master' a few times every day).
In this particular case, it was me being absent-minded without
realizing the base merge may need merge fixes until SZEDER pointed
out.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Aug 2025, #03; Fri, 8)
@ 2025-08-11 15:41 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-08-11 15:41 UTC (permalink / raw)
To: Eric Sunshine; +Cc: git
Eric Sunshine <sunshine@sunshineco.com> writes:
> On Fri, Aug 8, 2025 at 11:28 PM Junio C Hamano <gitster@pobox.com> wrote:
>> * lo/repo-info (2025-08-07) 5 commits
>> - repo: add the --format flag
>> - repo: add the field layout.shallow
>> - repo: add the field layout.bare
>> - repo: add the field references.format
>> - repo: declare the repo command
>>
>> A new subcommand "git repo" gives users a way to grab various
>> repository characteristics.
>>
>> Will merge to 'next'.
>> source: <20250807150239.6987-1-lucasseikioshiro@gmail.com>
>
> I think this topic may deserve one more reroll before being merged to
> 'next' since two or three comments from my previous review were not
> fully addressed[*]. (I also identified several nits in the latest
> version but they need not hold up the topic.)
Thanks for stopping me.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Aug 2025, #05; Mon, 11)
@ 2025-08-12 14:46 99% ` Junio C Hamano
1 sibling, 0 replies; 200+ results
From: Junio C Hamano @ 2025-08-12 14:46 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
Patrick Steinhardt <ps@pks.im> writes:
> On Tue, Aug 12, 2025 at 01:29:45AM -0700, Junio C Hamano wrote:
>> * ms/refs-list (2025-08-05) 6 commits
>> - t: add test for git refs list subcommand
>> - t6300: refactor tests to be shareable
>> - builtin/refs: add list subcommand
>> - builtin/for-each-ref: factor out core logic into a helper
>> - builtin/for-each-ref: align usage string with the man page
>> - doc: factor out common option
>>
>> The "list" subcommand of "git refs" acts as a front-end for
>> "git for-each-ref".
>>
>> Comments?
>> source: <20250805092758.5321-1-meetsoni3017@gmail.com>
>
> I've reviewed this version and am happy with the result. From my point
> of view it's ready to cook in 'next'.
I've looked at it, too. Thanks for a review.
>> * ps/commit-graph-wo-globals (2025-08-07) 10 commits
>> - commit-graph: stop passing in redundant repository
>> - commit-graph: stop using `the_repository`
>> - commit-graph: stop using `the_hash_algo`
>> - commit-graph: refactor `parse_commit_graph()` to take a repository
>> - commit-graph: store the hash algorithm instead of its length
>> - commit-graph: stop using `the_hash_algo` via macros
>> - commit-graph: fix sign comparison warnings
>> - commit-graph: fix type for some write options
>> - commit-graph: stop using signed integers to count Bloom filters
>> - trace2: introduce function to trace unsigned integers
>>
>> Remove dependency on the_repository and other globals from the
>> commit-graph code, and other changes unrelated to de-globaling.
>>
>> Will merge to 'next'?
>> source: <20250807-b4-pks-commit-graph-wo-the-repository-v3-0-82edef830a1e@pks.im>
>
> I don't intend to reroll this series for now. As long as you are happy
> with the signedness-related patches I think this should be ready.
Heh, I am not obviously happy. I don't have time to go in myself
and fix them, though.
>> * tc/t0450-harden (2025-08-08) 2 commits
>> . t0450: add allowlist for builtins with missing .adoc
>> . t0450: fix test for out-of-tree builds
>>
>> Test updates.
>>
>> Expecting a reroll?
>> cf. <xmqq7bzdfoxe.fsf@gitster.g>
>> source: <20250808095943.3312265-1-toon@iotcl.com>
>
> Toon is currently out of office, so this'll take a while to be rerolled.
> I'll have a look at whether I can reconstruct the seemingly-missing
> file.
I saw your patch. I'll queue it separately on top. As we won't be
moving new things beyond 'seen' for at least another week anyway, we
are not in a hurry ;-)
>> * en/ort-rename-fixes (2025-08-06) 7 commits
>> - merge-ort: fix directory rename on top of source of other rename/delete
>> - merge-ort: fix incorrect file handling
>> - merge-ort: clarify the interning of strings in opt->priv->path
>> - t6423: fix missed staging of file in testcases 12i,12j,12k
>> - t6423: document two bugs with rename-to-self testcases
>> - merge-ort: drop unnecessary temporary in check_for_directory_rename()
>> - merge-ort: update comments to modern testfile location
>>
>> Various bugs about rename handling in "ort" merge strategy have
>> been fixed.
>>
>> Will merge to 'next'?
>> source: <pull.1943.v3.git.1754522122.gitgitgadget@gmail.com>
>
> The patch series looks reasonable to me, but that's basically just going
> by the commit messages. I wouldn't claim to really understand our merge
> machinery, so my opinion is only of limited use.
Thanks. These looked OK to me, too.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Aug 2025, #05; Mon, 11)
@ 2025-08-12 16:02 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-08-12 16:02 UTC (permalink / raw)
To: Jean-Noël AVILA; +Cc: git
Jean-Noël AVILA <jn.avila@free.fr> writes:
> These patches are designed to not raise false positives, trading it for
> letting true positives pass through. For instance, the "synopsis" patch cannot
> catch keywords which are just one word.
>
> If possible, I'd like to see how they behave against upcoming documentation
> changes described in this "cooking". This is in order to not have to revert
> them at some point.
The topic being in 'seen' would test other topics in-flight
concurrently with this topic; avoiding false positives while trying
to minimize false negatives is very much appreciated.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Aug 2025, #05; Mon, 11)
@ 2025-08-13 14:55 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-08-13 14:55 UTC (permalink / raw)
To: Taylor Blau; +Cc: Patrick Steinhardt, git
Taylor Blau <me@ttaylorr.com> writes:
> On Wed, Aug 13, 2025 at 09:06:33AM +0200, Patrick Steinhardt wrote:
>> Fair. I don't want to spend too much time on this signedness topic,
>> either. So I'd go with either:
>>
>> - Taking the signedness patches as-is. They don't regress the status
>> quo and allow us to warn about future unintentional signedness bugs,
>> even though the fixes are mostly of theoretical value.
>>
>> - I drop the signedness-conversion patches altogether.
>>
>> The more important part for me is to get the second half of patches
>> merged anyway. So while I think that the first half of patches are nice
>> to have, I can live with dropping them.
>
> I'd personally lean towards the latter, and drop those patches for now.
> I think practically speaking that equates to taking patches in the range
> [5, 10].
Yeah, that is much simpler. That way, we do not add more commits in
"git log" that people may find later and mistakenly think that the
project had consensus to encourage the use of unsigned when signed
and narrower integer would do fine, and we won't have to see
misguided false positives from -Wsign-compare. We are better off
without these changes.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Aug 2025, #10; Fri, 22)
@ 2025-08-26 16:06 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-08-26 16:06 UTC (permalink / raw)
To: Elijah Newren; +Cc: Derrick Stolee, git
Elijah Newren <newren@gmail.com> writes:
>> Needs to wait for the base topic to solidify.
>> source: <pull.1941.v2.git.1752716054.gitgitgadget@gmail.com>
>
> Maybe also mark as expecting a reroll? (cf.
> CABPp-BFzMLGJwz4QqYtvw3zRYgmC=Mb8T8GCOsrLZqT2z+8H7A@mail.gmail.com and
> CABPp-BHLcy-A4yLR8gP1Sjt_EKQ4K08kPyb7G6yifdZj+0MJNg@mail.gmail.com)
Good idea.
As these are primarily to remind me, I'd prefer to point at articles
from the topic author that said "in the next reroll I'll do this"
rather than articles from reviewers when leaving a note to explain
why I do *not* want to merge it yet. But this second round does
look like it needs responses to reviews.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Aug 2025, #09; Wed, 20)
@ 2025-08-28 23:14 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-08-28 23:14 UTC (permalink / raw)
To: Derrick Stolee; +Cc: git, Patrick Steinhardt
Patrick Steinhardt <ps@pks.im> writes:
>> * ps/object-store-midx-dedup-info (2025-08-11) 11 commits
>> - midx: compute paths via their source
>> - midx: stop duplicating info redundant with its owning source
>> - midx: write multi-pack indices via their source
>> - midx: load multi-pack indices via their source
>> - midx: drop redundant `struct repository` parameter
>> - odb: simplify calling `link_alt_odb_entry()`
>> - odb: return newly created in-memory sources
>> - odb: consistently use "dir" to refer to alternate's directory
>> - odb: allow `odb_find_source()` to fail
>> - odb: store locality in object database sources
>> - Merge branch 'ps/object-store-midx' into ps/object-store-midx-dedup-info
>>
>> Further code clean-up for multi-pack-index code paths.
>>
>> Will merge to 'next'?
>> source: <20250811-b4-pks-midx-deduplicate-source-info-v3-0-e442bdf2b4ad@pks.im>
>
> There's still an outstanding question for Stolee [1] regarding the
> `--object-dir` option of git-multi-pack-index(1). It would be nice to
> give him a copule of days more to chime in. I've Cc'd him now.
>
> [1]: <aJUn0qeliNQ/nnWr@nand.local>
Then let me give a gentle ping here...
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Sep 2025, #01; Tue, 2)
@ 2025-09-02 17:50 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-09-02 17:50 UTC (permalink / raw)
To: rsbecker; +Cc: git
<rsbecker@nexbridge.com> writes:
> On September 2, 2025 12:58 PM, Junio C Hamano wrote:
>...
Please please do trim your quotes. You are asking your readers that
many many lines you left here are relevant and need to be read
before they respond to you, and I saw no relevance to topics you
interjected something, like ...
>>* lc/rebase-trailer (2025-08-03) 2 commits
>> - rebase: support --trailer
>> - trailer: append trailers in-process and drop the fork to
> `interpret-trailers`
... this. Unfortunately I am not sure what you wanted to say by
saying `interpret-trailers` here. Are you pointing out a typo and
giving a typofix or something?
>>* ag/send-email-imap-sent (2025-08-11) 2 commits
>> - send-email: enable copying emails to an IMAP folder without actually
> sending
>>them
Ditto.
>> - Merge branch 'ac/deglobal-sparse-variables' into
> ds/sparse-checkout-clean
Ditto.
I'll stop here.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Sep 2025, #02; Wed, 3)
@ 2025-09-04 16:21 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-09-04 16:21 UTC (permalink / raw)
To: Kristoffer Haugsbakk; +Cc: git
"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:
> • Incorporate Peff’s patch[2] if I’m up to the task
> • Then mention on the whatchanged *hint* that they can make an alias to
> shadow it
Hmph, I am not sure if training users that they can always alias
anything away in order to keep deprecated names forever is a good
idea overall. That way, we will ensure that newer users when
watching over shoulders of more old timers will have more chance to
get confused by unusual synonyms old timers would use without any
advantage over the more modern ways they have learned at school,
other than the "mustle memory" of old timers.
But if nobody is disturbed by that idea, then the above two would be
a reasonable way forward.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Sep 2025, #02; Wed, 3)
@ 2025-09-04 16:21 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-09-04 16:21 UTC (permalink / raw)
To: Lucas Seiki Oshiro; +Cc: git
Lucas Seiki Oshiro <lucasseikioshiro@gmail.com> writes:
>> * lo/repo-info-step-2 (2025-09-01) 3 commits
>> - repo: add the field objects.format
>> - repo: add the flag -z as an alias for --format=nul
>> - Merge branch 'lo/repo-info' into lo/repo-info-step-2
>>
>> "repo info" learns a short-hand option "-z" that is the same as
>> "--format=nul", and learns to report the objects format used in the
>> repository.
>>
>> Will merge to 'next'?
>> source: <20250901172732.98845-1-lucasseikioshiro@gmail.com>
>
> I found a codestyle problem in it, I'll send an v3 fixing that.
OK. Will mark it as expecting an update.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Sep 2025, #02; Wed, 3)
@ 2025-09-04 16:23 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-09-04 16:23 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
Patrick Steinhardt <ps@pks.im> writes:
> On Wed, Sep 03, 2025 at 10:07:49PM -0700, Junio C Hamano wrote:
>> * jt/de-global-bulk-checkin (2025-08-22) 4 commits
>> - bulk-checkin: use repository variable from transaction
>> - bulk-checkin: require transaction for index_blob_bulk_checkin()
>> - bulk-checkin: remove global transaction state
>> - bulk-checkin: introduce object database transaction structure
>>
>> The bulk-checkin code used to depend on a file-scope static
>> singleton variable, which has been updated to pass an instance
>> throughout the callchain.
>>
>> Will merge to 'next'?
>> source: <20250822213500.1488064-1-jltobler@gmail.com>
>
> The series looks good to me, so I think it should be ready for prime
> time.
Yup, I am fairly familiar with the area, and I didn't see anything
questionable in the updates. Let's move it forward.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Sep 2025, #03; Mon, 8)
@ 2025-09-09 21:20 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-09-09 21:20 UTC (permalink / raw)
To: Derrick Stolee; +Cc: Elijah Newren, git
Derrick Stolee <stolee@gmail.com> writes:
> On 9/9/2025 2:58 AM, Elijah Newren wrote:
>> On Mon, Sep 8, 2025 at 6:38 PM Junio C Hamano <gitster@pobox.com> wrote:
>>
>>> * ds/sparse-checkout-clean (2025-07-16) 7 commits
>>> - sparse-checkout: make 'clean' clear more files
>>> - t: expand tests around sparse merges and clean
>>> - sparse-index: point users to new 'clean' action
>>> - sparse-checkout: add --verbose option to 'clean'
>>> - dir: add generic "walk all files" helper
>>> - sparse-checkout: match some 'clean' behavior
>>> - sparse-checkout: add basics of 'clean' command
>>>
>>> "git sparse-checkout" subcommand learned a new "clean" action to
>>> prune otherwise unused working-tree files that are outside the
>>> areas of interest.
>>>
>>> Rebased not to depend on ac/deglobal-sparse-variables
>>> Will merge to 'next'?
>>> source: <pull.1941.v2.git.1752716054.gitgitgadget@gmail.com>
>>
>> No, please. Responses to review comments are still needed, as noted
>> over at https://lore.kernel.org/git/c3c0fbef-f395-4972-8352-dd89af6799d5@gmail.com/
>
> Indeed, I am delinquent with responses to those review
> comments. I hope to have a v3 this week.
Thanks, both, for helping the maintainer who often fails to keep
track of things X-<. Very much appreciated.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Sep 2025, #03; Mon, 8)
@ 2025-09-10 21:37 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-09-10 21:37 UTC (permalink / raw)
To: Kristoffer Haugsbakk; +Cc: git
"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:
> On Tue, Sep 9, 2025, at 03:37, Junio C Hamano wrote:
>> * kh/doc-fast-import-markup-fix (2025-09-08) 1 commit
>> - doc: fast-import: replace literal block with paragraph
>>
>> Doc mark-up fix.
>>
>> Will merge to 'next'.
>> source:
>> <09aaad696895c18c6d4dda7d6a2f4b77f84f39ba.1757363213.git.code@khaugsbakk.name>
>
> Nit: The ref still points to v1. Although v2 just has the Ack:
>
> <724b975078daf11e17f26472c0da5638a5d1ca86.1757366352.git.code@khaugsbakk.name>
It is not just the ref. The updated version has not been picked up
at all. Thanks for letting me know.
Is it just Peff's Ack, or any other changes added to the patch?
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Sep 2025, #03; Mon, 8)
@ 2025-09-10 21:38 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-09-10 21:38 UTC (permalink / raw)
To: Phillip Wood; +Cc: git
Phillip Wood <phillip.wood123@gmail.com> writes:
> On 09/09/2025 02:37, Junio C Hamano wrote:
>> * pw/3.0-default-initial-branch-to-main (2025-09-04) 4 commits
>> - t0613: stop setting default initial branch
>> - t9902: switch default branch name to main
>> - t4013: switch default branch name to main
>> - breaking-changes: switch default branch to main
>> Declare that "git init" that is not otherwise configured uses
>> 'main' as the initial branch, not 'master', starting Git 3.0.
>> Will merge to 'next'?
>> source: <cover.1756992089.git.phillip.wood@dunelm.org.uk>
>
> I've just sent V3 with some small changes in response to the feedback
> on V2. c.f. <cover.1757518141.git.phillip.wood@dunelm.org.uk>
>
> Thanks
>
> Phillip
Thanks. Took a look and replaced.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Sep 2025, #03; Mon, 8)
@ 2025-09-10 21:42 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-09-10 21:42 UTC (permalink / raw)
To: Jeff King; +Cc: git
Jeff King <peff@peff.net> writes:
> On Mon, Sep 08, 2025 at 06:37:49PM -0700, Junio C Hamano wrote:
>
>> * jk/curl-global-trace-components (2025-08-27) 1 commit
>> - curl: add support for curl_global_trace() components
>>
>> Adjust to the way newer versions of cURL selectivel enables tracing
>> options, so that our tests can continue to work.
>>
>> Will merge to 'next'?
>> source: <20250827080702.GA3572995@coredump.intra.peff.net>
>
> It doesn't seem to have gotten a lot of interest. But we have to do
> _something_ if we want tests to keep passing with the new version of
> curl. The other obvious alternatives is to try to modify the tests so
> that we don't have to modify the code to support the extra debugging
> knob. But I suspect that debugging knob may come in handy at some point
> in the future, and is worth having.
>
> -Peff
Thanks for pinging. I was hoping that other people, not you, to say
the above, but perhaps our developer population is too small for
that?
Let's merge it to 'next'.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Sep 2025, #04; Wed, 10)
@ 2025-09-10 21:45 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-09-10 21:45 UTC (permalink / raw)
To: Kristoffer Haugsbakk; +Cc: git
"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:
> On Wed, Sep 10, 2025, at 23:03, Junio C Hamano wrote:
>> * kh/you-still-use-whatchanged-fix (2025-09-09) 7 commits
>> - BreakingChanges: remove claim about whatchanged reports
>> - whatchanged: remove not-even-shorter clause
>> - whatchanged: tell users the git-log(1) equivalent
>> - you-still-use-that??: help the user help themselves
>> - t0014: test shadowing of aliases for a sample of builtins
>> - git: allow alias-shadowing deprecated builtins
>> - git: add `deprecated` category to --list-cmds
>>
>> Update "do you still use it?" message given by a command that is
>> deeply deprecated and allow us to suggest alternatives.
>>
>> Will merge to 'next'?
>> source: <cover.1757446619.git.code@khaugsbakk.name>
>
> I need to follow up on the leak that Peff found.
Thanks, both. Will hold.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Sep 2025, #06; Mon, 15)
@ 2025-09-16 17:19 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-09-16 17:19 UTC (permalink / raw)
To: Jeff King; +Cc: Patrick Steinhardt, git
Jeff King <peff@peff.net> writes:
> That said, it is not really that big an issue and I am fine with any
> fix. If you want to document how the history unfolded, then I think an
> evil merge shows that (neither topic had a problem on its own, but when
> merged we needed to adjust the result). And it is probably the least
> amount of work. ;)
That's also fine, too. Let me try that ;-)
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Sep 2025, #09; Mon, 22)
@ 2025-09-23 14:14 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-09-23 14:14 UTC (permalink / raw)
To: Jeff King; +Cc: git
Jeff King <peff@peff.net> writes:
> On Mon, Sep 22, 2025 at 04:01:01PM -0700, Junio C Hamano wrote:
>
>> * jk/setup-revisions-freefix (2025-09-19) 6 commits
>> (merged to 'next' on 2025-09-22 at b178f27e6d)
>> + revision: retain argv NULL invariant in setup_revisions()
>> + treewide: pass strvecs around for setup_revisions_from_strvec()
>> + treewide: use setup_revisions_from_strvec() when we have a strvec
>> + revision: add wrapper to setup_revisions() from a strvec
>> + revision: manage memory ownership of argv in setup_revisions()
>> + stash: tell setup_revisions() to free our allocated strings
>>
>> There are double frees and leaks around setup_revisions() API used
>> in "git stash show", which has been fixed, and setup_revisions()
>> API gained a wrapper to make it more ergonomic when using it with
>> strvec-manged argc/argv pairs.
>>
>> Expecting a reroll to fix t3903
>> cf. <xmqq1pnywkwv.fsf@gitster.g>
>> source: <20250919223351.GA3906184@coredump.intra.peff.net>
>
> Hmm, I was surprised to see this merged to next, especially with the
> comment at the bottom here.
Yeah, I am surprised too ;-) Will fix.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Sep 2025, #09; Mon, 22)
@ 2025-09-23 14:34 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-09-23 14:34 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
Patrick Steinhardt <ps@pks.im> writes:
> On Mon, Sep 22, 2025 at 04:01:01PM -0700, Junio C Hamano wrote:
>> * ps/odb-clean-stale-wrappers (2025-09-10) 1 commit
>> - odb: drop deprecated wrapper functions
>>
>> Code clean-up.
>>
>> Breaks build when merged to 'seen'.
>> cf. <20250910153759.GA562601@coredump.intra.peff.net>
>> source: <20250910-b4-pks-odb-drop-wrappers-v1-1-6ed660cb1eec@pks.im>
>
> With the evil merge this that adds the missing "repository.h" header
> this status is now out-of-date, right? Is there anything else I can do
> to get the topic rolling again?
Yeah, my mistake. Let's mark it for 'next'.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Sep 2025, #09; Mon, 22)
@ 2025-09-24 19:01 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-09-24 19:01 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: git
SZEDER Gábor <szeder.dev@gmail.com> writes:
>> * jt/odb-transaction (2025-09-16) 7 commits
>> - odb: add transaction interface
>> - object-file: update naming from bulk-checkin
>> - object-file: relocate ODB transaction code
>> - bulk-checkin: drop flush_odb_transaction()
>> - builtin/update-index: end ODB transaction when --verbose is specified
>> - bulk-checkin: remove ODB transaction nesting
>> - Merge branch 'jt/de-global-bulk-checkin' into jt/odb-transaction
>>
>> Continue the work to build on the bulk-checkin infrastructure to
>> create many objects at once in a transaction and abstract it into
>> the generic object layer.
>>
>> Will merge to 'next'.
>> source: <20250916182938.2193476-1-jltobler@gmail.com>
>
> The merge of this topic into 'jch' modifies 'object-file.c' by
> replacing a call to reprepare_packed_git() with odb_reprepare(), but
> at that point the latter function doesn't exists yet, as it will only
> be introduced in 'ps/packfile-store', which is merged later.
Thanks. This is because there was a merge-fix defined for this
topic that was written back when this topic were less ready than the
other one. I'd need to move that merge-fix to the other topic to
correct it.
Thanks for catching while this topic was still outside 'next'.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Sep 2025, #11; Mon, 29)
@ 2025-09-30 14:43 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-09-30 14:43 UTC (permalink / raw)
To: brian m. carlson; +Cc: git
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
> On 2025-09-29 at 22:19:25, Junio C Hamano wrote:
>> * ps/rust-balloon (2025-09-24) 9 commits
>> - ci: enable Rust for breaking-changes jobs
>> - ci: convert "pedantic" job into full build with breaking changes
>> - BreakingChanges: announce Rust becoming mandatory
>> - varint: reimplement as test balloon for Rust
>> - varint: use explicit width for integers
>> - help: report on whether or not Rust is enabled
>> - Makefile: introduce infrastructure to build internal Rust library
>> - Makefile: reorder sources after includes
>> - meson: add infrastructure to build internal Rust library
>>
>> Dip our toes a bit to (optionally) use Rust implemented helper
>> called from our C code.
>>
>> Comments?
>
> This looks fine to me and addressed all of my previous feedback. The
> cover letter incorrectly says that it's only wiring up Meson (which is
> no longer true), but we're not including that in the series, so we don't
> need to fix it.
>
> I confirmed that my branch using Rust builds fine on top of that version
> as well.
Thanks!
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Oct 2025, #02; Mon, 6)
@ 2025-10-07 14:24 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-10-07 14:24 UTC (permalink / raw)
To: Jeff King; +Cc: Jean-Noël Avila, git
Jeff King <peff@peff.net> writes:
> Subject: [PATCH] doc: fix indentation of refStorage item in git-config(1)
>
> Commit 5a12fd2a8c (doc: change the markup of paragraphs following a
> nested list item, 2025-09-27) converted the list of items in
> config/extensions.adoc into a definition list. This caused a small
> regression in the indentation of one item, but only when built with
> AsciiDoctor. You can see the problem with:
>
> $ ./doc-diff --asciidoctor 5a12fd2a8c^ 5a12fd2a8c
> --- a/c44beea485f0f2feaf460e2ac87fdd5608d63cf0-asciidoctor/home/peff/share/man/man1/git-config.1
> +++ b/5a12fd2a8c850df311aa149c9bad87b7cb002abb-asciidoctor/home/peff/share/man/man1/git-config.1
> @@ -3128,9 +3128,9 @@ CONFIGURATION FILE
> • reftable for the reftable format. This format is
> experimental and its internals are subject to change.
>
> - Note that this setting should only be set by git-init(1) or git-
> - clone(1). Trying to change it after initialization will not work
> - and will produce hard-to-diagnose issues.
> + Note that this setting should only be set by git-init(1) or git-
> + clone(1). Trying to change it after initialization will not work and
> + will produce hard-to-diagnose issues.
>
> relativeWorktrees
> If enabled, indicates at least one worktree has been linked with
>
> (along with many other changes which are correctly fixing what
> 5a12fd2a8c intended to fix). The "Note" paragraph should remain aligned
> with the bullet points, as they are left-aligned with the rest of the
> definition text.
>
> The confusion comes from a paragraph following a list item (ironically,
> the same case that 5a12fd2a8c was solving!). We can solve it by adding
> "--" block markers around the nested list. We couldn't have done that
> before 5a12fd2a8c because before then our list was nested inside another
> set of block markers, something that AsciiDoctor has trouble with. But
> now that we are a top-level definition list, it is OK to do so (and in
> fact, you can see that commit already made a similar adjustment for the
> worktreeConfig entry).
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> Documentation/config/extensions.adoc | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/config/extensions.adoc b/Documentation/config/extensions.adoc
> index 49a7598ca5..aaea8c107f 100644
> --- a/Documentation/config/extensions.adoc
> +++ b/Documentation/config/extensions.adoc
> @@ -55,8 +55,9 @@ For historical reasons, this extension is respected regardless of the
> refStorage:::
> Specify the ref storage format to use. The acceptable values are:
> +
> +--
> include::../ref-storage-format.adoc[]
> -
> +--
> +
> Note that this setting should only be set by linkgit:git-init[1] or
> linkgit:git-clone[1]. Trying to change it after initialization will not
Thanks. Will queue.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Oct 2025, #02; Mon, 6)
@ 2025-10-08 16:41 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-10-08 16:41 UTC (permalink / raw)
To: Elijah Newren; +Cc: git
Elijah Newren <newren@gmail.com> writes:
>> * rj/doc-technical-fixes (2025-10-02) 3 commits
>> - doc: commit-graph.adoc: fix up some formatting
>> - doc: sparse-checkout.adoc: fix asciidoc warnings
>> - doc: remembering-renames.adoc: fix asciidoc warnings
>> (this branch uses rj/doc-missing-technical-docs.)
>>
>> Documenation mark-up fixes.
>>
>> Comments?
>> source: <20251002221233.541844-1-ramsay@ramsayjones.plus.com>
>
> Documenation -> Documentation
>
> Ramsay commented that he had a small fixup to send after waiting for
> more feedback (https://lore.kernel.org/git/436fb507-6764-46f4-abb1-34c82e27b808@ramsayjones.plus.com/),
> so maybe mark as waiting for a re-roll?
I missed this one. Very much appreciated.
> The series looked fine to me, I just feel bad for causing so much work
> for him. Are the things in Documentation/technical/ meant to be
> pretty-formatted and distributed anywhere? I assumed the audience was
> fellow git developers and the original .txt file (that someone else
> renamed to .adoc) was the preferred viewing format.
My assumpstion has been the same as yours. I was surprised already
when some folks started to subject things in Documentation/howto/ to
AsciiDoc long ago, so I am no longer surprised by this, though ;-)
>> * kh/doc-patch-id-markup-fix (2025-09-29) 1 commit
>> - doc: patch-id: fix accidental literal blocks
>>
>> Documenaotin mark-up fix.
>>
>> Will merge to 'next'?
>> source: <v2-e5ad12cc3b3.1759178715.git.code@khaugsbakk.name>
>
> I think Documentation is determined to be misspelled in your release
> notes, in various exciting ways. :-)
Thanks. Fixed.
I blame a new keyboard at work. If somebody measures my typo-rate
and finds it higher than other days on Tuesdays thru Thursdays, then
that is it ;-)
All others points in your list were very helpful. Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Oct 2025, #04; Fri, 10)
@ 2025-10-11 17:14 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-10-11 17:14 UTC (permalink / raw)
To: D. Ben Knoble; +Cc: git, Phillip Wood, Kristoffer Haugsbakk
"D. Ben Knoble" <ben.knoble@gmail.com> writes:
> On Fri, Oct 10, 2025 at 8:00 PM Junio C Hamano <gitster@pobox.com> wrote:
>> --------------------------------------------------
>> [New Topics]
>>
>> * dk/stash-apply-index (2025-10-06) 1 commit
>> - doc: explain the impact of stash.index on --autostash options
>>
>> Doc update.
>>
>> Will merge to 'next'.
>> source: <d4a277b6b0695d86636562f4c07efae17f9249f9.1759755379.git.ben.knoble+github@gmail.com>
>
> I think Kristoffer had some feedback about the message—if changes need
> made, my understanding is that happens prior to "next" ?
>
> I'll send a reply there shortly, at any rate.
OK, will wait (I am not sure what needs updated, though).
>> * jc/optional-path (2025-09-28) 4 commits
>> (merged to 'next' on 2025-10-08 at a1e8af9952)
>> + parseopt: values of pathname type can be prefixed with :(optional)
>> + config: values of pathname type can be prefixed with :(optional)
>> + t7500: fix GIT_EDITOR shell snippet
>> + t7500: make each piece more independent
>>
>> Configuration variables that take a pathname as a value
>> (e.g. blame.ignorerevsfile) can be marked as optional by prefixing
>> ":(optoinal)" before its value.
>>
>> Will merge to 'master'.
>> source: <cover.1759094936.git.ben.knoble+github@gmail.com>
>
> As I mentioned in <1D9EE7CD-800B-4B70-8D98-79B0C2FB8DBA@gmail.com>, I
> think we might want a slight reroll for some tests and to use the
> correct functions in a few places.
If you want to change anything, can you do it with incremental
patches on top? Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Oct 2025, #04; Fri, 10)
@ 2025-10-13 14:07 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-10-13 14:07 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
Patrick Steinhardt <ps@pks.im> writes:
> On Fri, Oct 10, 2025 at 05:00:43PM -0700, Junio C Hamano wrote:
>> * ps/ci-rust (2025-10-07) 8 commits
>> - rust: support for Windows
>> - ci: verify minimum supported Rust version
>>...
>> - Merge branch 'ps/rust-balloon' into ps/ci-rust
>>
>> CI improvements to handle the recent Rust integration better.
>>
>> Expecting an update.
>> cf. <aOdIRnB-SGQwj935@pks.im>
>> source: <20251008-b4-pks-ci-rust-v2-0-d556ee83c381@pks.im>
>
> I think this status is stale, right? v2 didn't have review feedback that
> would require changes as far as I can see.
Indeed it is.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Oct 2025, #04; Fri, 10)
@ 2025-10-13 15:28 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-10-13 15:28 UTC (permalink / raw)
To: Eric Sunshine; +Cc: git
Eric Sunshine <sunshine@sunshineco.com> writes:
> On Fri, Oct 10, 2025 at 8:00 PM Junio C Hamano <gitster@pobox.com> wrote:
>> * ms/doc-worktree-side-by-side (2025-10-10) 2 commits
>> - doc: git-worktree: Add side by side branch checkout example
>> - doc: git-worktree: Link to examples
>>
>> Document "git worktree add" and use of out-of-tree worktrees with
>> examples.
>>
>> Will merge to 'next'?
>> source: <a203b35538847f3c9358a5ae26fb4ebea5734cfc.1759420102.git.msuchanek@suse.de>
>
> I'd prefer that this not be merged to 'next' in its present form since
> I think the first patch either needs significantly more justification
> or ought to be dropped altogether[1], and because the second patch
> still needs a good deal of work[2].
>
> [1]: https://lore.kernel.org/git/CAPig+cQRHp7A=gtSkrVS4_EvZ9PyqBOdGGHcEajfLPE=qU4uDQ@mail.gmail.com/
> [2]: https://lore.kernel.org/git/CAPig+cSNesf0UwS4=Bxe-Qn+G9y3YYPyOK+7y3q8QJk+o7jaVg@mail.gmail.com/
Let me watch from the sidelines how the discussion goes.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Oct 2025, #06; Fri, 17)
@ 2025-10-21 21:48 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-10-21 21:48 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
Patrick Steinhardt <ps@pks.im> writes:
> On Mon, Oct 20, 2025 at 02:02:52PM -0700, Junio C Hamano wrote:
>> * ar/run-command-hook (2025-10-17) 10 commits
>> ...
>> Comments?
>> source: <20251017141544.1538542-1-adrian.ratiu@collabora.com>
>
> I'll make sure tho give the current iteration another review today.
Thanks, very much appreciated.
>> * cc/fast-import-strip-signed-tags (2025-10-13) 5 commits
>> ...
>> Will merge to 'next'?
>> source: <20251013084857.1646783-1-christian.couder@gmail.com>
>
> Should be ready from my point of view. v2 already addressed all of
> my comments, and v3 clarified the documentation in one more case. So I'm
> happy with this version.
Yup, matches my feeling.
>> * ps/ci-rust (2025-10-14) 8 commits
>> ...
>> Will merge to 'next'?
>> source: <20251015-b4-pks-ci-rust-v3-0-13810af33bd5@pks.im>
>
> I think it should be ready. The 3rd version only saw a single minor
> fixup relative to the 2nd one.
OK. CI changes are easy to handle as we would know breakage fairly
soon ;-)
>> * ps/remove-packfile-store-get-packs (2025-10-09) 7 commits
>> ...
>> Comments?
>> source: <20251009-pks-packfiles-convert-get-all-v2-0-0d73b87ce711@pks.im>
>
> I think this series should be ready once the below series is merged
> down. v2 addressed all of Taylor's feedback and saw another positive
> review by Justin.
Yeah, relying on an in-flight topic has to block the topic until
the base solidifies, which I do not particularly like (as I can
easily screw up by merging the dependent and drag the base into
'next' before it is ready). As the other one does look ready, it
should be OK as well.
>> * tb/incremental-midx-part-3.1 (2025-10-15) 50 commits
>> ...
>> (this branch is used by ps/remove-packfile-store-get-packs.)
>>
>> Clean-up "git repack" machinery to prepare for incremental update
>> of midx files.
>>
>> Will merge to 'next'?
>> source: <cover.1760567210.git.me@ttaylorr.com>
>
> Yeah, I think this one is ready to go.
Thanks, concurred.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Oct 2025, #08; Thu, 23)
@ 2025-10-24 16:06 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-10-24 16:06 UTC (permalink / raw)
To: Jeff King; +Cc: git
Jeff King <peff@peff.net> writes:
> On Thu, Oct 23, 2025 at 04:36:01PM -0700, Junio C Hamano wrote:
>
>> * jc/diff-from-contents-fix (2025-10-22) 1 commit
>> (merged to 'next' on 2025-10-23 at fae07d2113)
>> + diff: make sure the other caller of diff_flush_patch_quietly() is silent
>> (this branch is used by ly/diff-name-only-with-diff-from-content; uses jk/diff-from-contents-fix.)
>>
>> The code to squelch output from "git diff -w --name-status"
>> etc. for paths that "git diff -w -p" would have stayed silent
>> leaked output from dry-run patch generation, which has been
>> corrected.
>>
>> Will merge to 'master'.
>> source: <xmqqy0p4wcac.fsf@gitster.g>
>
> OK, looks like you picked up the fix from the last round of discussion.
> Good. Is this destined for 'maint'? My patch fixed the regression from
> v2.51.1 with "--quiet", but I think there is still one for "-w --raw",
> etc.
The plan is to merge "j?/diff-from-contents-fix" down to 'maint';
any other changes that tweak dry-run are to be done 'next' down to
'master' but not to 'maint' as a longer term "true fix".
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Oct 2025, #12; Thu, 30)
2025-11-03 17:57 99% ` Junio C Hamano
@ 2025-10-31 15:51 99% ` Junio C Hamano
1 sibling, 0 replies; 200+ results
From: Junio C Hamano @ 2025-10-31 15:51 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
Patrick Steinhardt <ps@pks.im> writes:
>> * je/doc-data-model (2025-10-27) 1 commit
>> - doc: add an explanation of Git's data model
>>
>> Add a new manual that describes the data model.
>>
>> Comments?
>> source: <pull.1981.v4.git.1761593537924.gitgitgadget@gmail.com>
>
> Will have another look at v5 of this series. I think it's nearing a
> state where it's good enough to be merged down.
I share that assessment.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Oct 2025, #11; Tue, 28)
@ 2025-10-31 21:33 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-10-31 21:33 UTC (permalink / raw)
To: Toon Claes; +Cc: git
Toon Claes <toon@iotcl.com> writes:
> Hi Junio,
>
> I don't see the patch I've submitted to speed up git-last-modified in
> this report? As a follow-up to your response on v2, I did submit v3[1]
> which resolves the -Wsign-compare issues, but I forgot to Cc you. This
> version was acked by Taylor[2].
>
> King regards,
> Toon
>
> [1]: <20251023-b4-toon-last-modified-faster-v3-1-40a4ddbbadec@iotcl.com>
> [2]: <aPrCaSOA/dclWye5@nand.local>
Unfortunately, the topic breaks make coccicheck.
https://github.com/git/git/actions/runs/18981332553/job/54214401412
We'd need at least something like the attached squashed in.
builtin/last-modified.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/last-modified.c b/builtin/last-modified.c
index c271d9585b..b0ecbdc540 100644
--- a/builtin/last-modified.c
+++ b/builtin/last-modified.c
@@ -493,7 +493,7 @@ static int last_modified_init(struct last_modified *lm, struct repository *r,
if (populate_paths_from_revs(lm) < 0)
return error(_("unable to setup last-modified"));
- lm->all_paths = xcalloc(hashmap_get_size(&lm->paths), sizeof(const char *));
+ CALLOC_ARRAY(lm->all_paths, hashmap_get_size(&lm->paths));
lm->all_paths_nr = 0;
hashmap_for_each_entry(&lm->paths, &iter, ent, hashent) {
ent->diff_idx = lm->all_paths_nr++;
--
2.51.2-719-gbbf487eab4
^ permalink raw reply related [relevance 99%]
* Re: What's cooking in git.git (Oct 2025, #12; Thu, 30)
@ 2025-11-03 17:57 99% ` Junio C Hamano
2025-11-03 18:43 99% ` Junio C Hamano
2025-10-31 15:51 99% ` Junio C Hamano
1 sibling, 1 reply; 200+ results
From: Junio C Hamano @ 2025-11-03 17:57 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
Patrick Steinhardt <ps@pks.im> writes:
>> * ps/ref-peeled-tags (2025-10-23) 16 commits
>> - ref-filter: parse objects on demand
>> ...
>> - Merge branch 'jt/repo-structure' into ps/ref-peeled-tags
>> - Merge branch 'tb/incremental-midx-part-3.1' into ps/ref-peeled-tags
>> (this branch is used by kn/refs-optim-cleanup; uses jt/repo-structure.)
>>
>> Some ref backend storage can hold not just the object name of an
>> annotated tag, but the object name of the object the tag points at.
>> The code to handle this information has been streamlined.
>>
>> Will merge to 'next' after base topics are merged.
>> source: <20251023-b4-pks-ref-filter-skip-parsing-objects-v4-0-2be68ce82c9a@pks.im>
>
> Both dependencies have landed, so this should be ready to be merged now.
The tip of 'next' as of today after merging this topic, it seems.
$ git tag --list --sort=version:tag 'v*.0'
no longer works correctly and shows ascii sort.
v1.0.0
v1.1.0
...
v2.0.0
v2.1.0
v2.10.0
v2.11.0
...
v2.19.0
v2.2.0
v2.20.0
v2.21.0
...
v2.49.0
v2.5.0
v2.50.0
v2.51.0
v2.6.0
v2.7.0
v2.8.0
v2.9.0
The merge on 'next' immediately before this topic got merged, i.e.,
9ab444ed (Merge branch 'tc/last-modified-active-paths-optimization'
into next, 2025-11-03), is the last commit on the 'next'
first-parent chain with which the above command works correctly.
I haven't dug it further yet.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Oct 2025, #12; Thu, 30)
2025-11-03 17:57 99% ` Junio C Hamano
@ 2025-11-03 18:43 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-11-03 18:43 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
Junio C Hamano <gitster@pobox.com> writes:
> The tip of 'next' as of today after merging this topic, it seems.
>
> $ git tag --list --sort=version:tag 'v*.0'
>
> no longer works correctly and shows ascii sort.
>
> v1.0.0
> v1.1.0
> ...
> v2.0.0
> v2.1.0
> v2.10.0
> v2.11.0
> ...
> v2.19.0
> v2.2.0
> v2.20.0
> v2.21.0
> ...
> v2.49.0
> v2.5.0
> v2.50.0
> v2.51.0
> v2.6.0
> v2.7.0
> v2.8.0
> v2.9.0
>
> The merge on 'next' immediately before this topic got merged, i.e.,
> 9ab444ed (Merge branch 'tc/last-modified-active-paths-optimization'
> into next, 2025-11-03), is the last commit on the 'next'
> first-parent chain with which the above command works correctly.
>
> I haven't dug it further yet.
Bisect points at 054f5f45 (ref-filter: parse objects on demand,
2025-10-23), which is unfortunate, as that is the motivating step of
the whole topic.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Nov 2025, #03; Fri, 7)
@ 2025-11-12 16:13 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-11-12 16:13 UTC (permalink / raw)
To: Toon Claes; +Cc: git, Taylor Blau
Toon Claes <toon@iotcl.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> * tc/last-modified-active-paths-optimization (2025-10-23) 1 commit
>> (merged to 'next' on 2025-11-03 at 9ab444edfb)
>> + last-modified: implement faster algorithm
>>
>> "git last-modified" was optimized by narrowing the set of paths to
>> follow as it dug deeper in the history.
>>
>> Will cook in 'next'.
>> source: <20251023-b4-toon-last-modified-faster-v3-1-40a4ddbbadec@iotcl.com>
>
> Do you plan to include these changes in the upcoming v2.52 release? I
> would like to argue to include them.
I plan to exclude, especially if it was not merged to 'next' before
2025-10-30, which is one calendar week before -rc1, to give the
topic the usual cooking period.
> Maybe it wasn't very clear how I phrased it in the v4 cover letter[1],
> but without this patch, some results are wrong:
Indeed it was unclear. With respect to the output, the only thing I
recalled was (I just went back to the thread)
One thing to note though, the results might be outputted in a different
order than before. This is not considerd to be an issue because nowhere
is documented the order is guaranteed.
and the patch came with a single test that gives a much later than
before in check_last_modified output, which does not clearly
demonstrate how the old results were wrong and the new results
correct them.
>> As an added benefit, results are more consistent now. For example
>> implementation in 'master' gives:
>>
>> $ git log --max-count=1 --format=%H -- pkt-line.h
>> 15df15fe07ef66b51302bb77e393f3c5502629de
>>
>> $ git last-modified -- pkt-line.h
>> 15df15fe07ef66b51302bb77e393f3c5502629de pkt-line.h
>>
>> $ git last-modified | grep pkt-line.h
>> 5b49c1af03e600c286f63d9d9c9fb01403230b9f pkt-line.h
>>
>> With the changes in this patch the results of git-last-modified(1)
>> always match those of `git log --max-count=1`.
>
> So this patch speeds up git-last-modified(1), but it also fixes some
> buggy results. That's why I consider this a bug fix and worthy to make
> it into the upcoming release. (which is by the way also the first
> release that includes this subcommand)
>
> [1]: https://lore.kernel.org/git/20251103154726.26592-1-toon@iotcl.com/
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Nov 2025, #04; Fri, 14)
@ 2025-11-17 22:48 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-11-17 22:48 UTC (permalink / raw)
To: Phillip Wood; +Cc: D. Ben Knoble, git
Phillip Wood <phillip.wood123@gmail.com> writes:
> On 15/11/2025 16:51, D. Ben Knoble wrote:
>> On Fri, Nov 14, 2025 at 5:27 PM Junio C Hamano <gitster@pobox.com> wrote:
>>>
>>> * ps/history (2025-10-27) 12 commits
>>> - builtin/history: implement "split" subcommand
>>> - cache-tree: allow writing in-memory index as tree
>>> - add-patch: add support for in-memory index patching
>>> - add-patch: remove dependency on "add-interactive" subsystem
>>> - add-patch: split out `struct interactive_options`
>>> - add-patch: split out header from "add-interactive.h"
>>> - builtin/history: implement "reword" subcommand
>>> - builtin: add new "history" command
>>> - replay: stop using `the_repository`
>>> - replay: extract logic to pick commits
>>> - wt-status: provide function to expose status for trees
>>> - Merge branch 'sa/replay-atomic-ref-updates' into ps/history
>>> (this branch uses sa/replay-atomic-ref-updates.)
>>>
>>> "git history" history rewriting UI.
>>>
>>> Comments?
>>> source: <20251027-b4-pks-history-builtin-v6-0-407dd3f57ad3@pks.im>
>>
>> But otherwise I generally am in favor of the idea and find it useful.
>
> I agree with this and I'm pleased it is reusing some of the internals of
> "git replay" now. I've just reviewed the first half, I'll try and do the
> rest sometime this week.
Thanks!
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Nov 2025, #07; Sun, 23)
@ 2025-11-24 18:26 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-11-24 18:26 UTC (permalink / raw)
To: D. Ben Knoble; +Cc: git
"D. Ben Knoble" <ben.knoble@gmail.com> writes:
> On Sun, Nov 23, 2025 at 11:59 PM Junio C Hamano <gitster@pobox.com> wrote:
>
>> --------------------------------------------------
>> [New Topics]
>>
>> * jc/optional-path (2025-11-20) 3 commits
>> - config: really treat missing optional path as not configured
>> - config: really pretend missing :(optional) value is not there
>> - config: mark otherwise unused function as file-scope static
>>
>> "git config get --path" segfaulted on an ":(optional)path" that
>> does not exist, which has been corrected.
>>
>> Will merge to 'next'?
>> source: <xmqqikf47ajk.fsf@gitster.g>
>
> Any interest in also marking this for 2.52.1? It's unlikely to be used
> much yet, but since the segfault affects several invocations (git
> blame, etc.) it will be irritating to folks who try the recently
> released version.
Yes, this is a clear regression-fix material. The branch you are
commenting on is designed to be merge-able anywhere the original
topic that had the segfault can be (or has been) merged, by building
directly on top of ccfcaf39 (parseopt: values of pathname type can
be prefixed with :(optional), 2025-09-28), which was the tip of the
original topic.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Nov 2025, #07; Sun, 23)
@ 2025-11-25 17:19 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-11-25 17:19 UTC (permalink / raw)
To: Toon Claes; +Cc: git
Toon Claes <toon@iotcl.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> * ps/object-source-management (2025-11-18) 14 commits
>> - odb: handle recreation of quarantine directories
>> - odb: handle changing a repository's commondir
>> - chdir-notify: add function to unregister listeners
>> - odb: handle initialization of sources in `odb_new()`
>> - http-push: stop setting up `the_repository` for each reference
>> - t/helper: stop setting up `the_repository` repeatedly
>> - builtin/index-pack: fix deferred fsck outside repos
>> - oidset: introduce `oidset_equal()`
>> - odb: move logic to disable ref updates into repo
>> - odb: refactor `odb_clear()` to `odb_free()`
>> - odb: adopt logic to close object databases
>> - setup: convert `set_git_dir()` to have file scope
>> - path: move `enter_repo()` into "setup.c"
>> - Merge branch 'ps/object-source-loose' into ps/object-source-management
>> (this branch uses ps/object-source-loose.)
>>
>> Code refactoring around object database sources.
>>
>> Comments?
>> source: <20251119-b4-pks-odb-creation-v1-0-2b2ed2612cb6@pks.im>
>
> I've read through the patches, and I've got no comments to add.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Nov 2025, #08; Tue, 25)
@ 2025-11-26 14:36 99% ` Junio C Hamano
2025-11-26 17:04 99% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2025-11-26 14:36 UTC (permalink / raw)
To: Christian Couder; +Cc: git
Christian Couder <christian.couder@gmail.com> writes:
> Not sure why but you seem to be the author of the "fast-import: add
> 'strip-if-invalid' mode to --signed-commits=<mode>" commit now:
Most likely "commit --fixup amend:$THAT" followed by
"rebase --autosquash $THAT~1", which is the only major thing I
started using recently, that went bad.
Thanks for noticing.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Nov 2025, #08; Tue, 25)
2025-11-26 14:36 99% ` Junio C Hamano
@ 2025-11-26 17:04 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-11-26 17:04 UTC (permalink / raw)
To: Christian Couder; +Cc: git
Junio C Hamano <gitster@pobox.com> writes:
> Christian Couder <christian.couder@gmail.com> writes:
>
>> Not sure why but you seem to be the author of the "fast-import: add
>> 'strip-if-invalid' mode to --signed-commits=<mode>" commit now:
>
> Most likely "commit --fixup amend:$THAT" followed by
> "rebase --autosquash $THAT~1", which is the only major thing I
> started using recently, that went bad.
>
> Thanks for noticing.
Corrected. I do not think this was "--fixup amend:$THAT"; rather
the application of the patch heavily conflicted and I had to
recreate a clean patch myself to apply, and at that point I probably
forgot to double check the author identity of the resulting commit.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Nov 2025, #10; Sun, 30)
@ 2025-12-07 0:43 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-12-07 0:43 UTC (permalink / raw)
To: Karthik Nayak; +Cc: git
Karthik Nayak <karthik.188@gmail.com> writes:
>> * kn/fix-fetch-backfill-tag-with-batched-ref-updates (2025-11-21) 3 commits
>> - fetch: fix failed batched updates skipping operations
>> - fetch: fix non-conflicting tags not being committed
>> - fetch: extract out reference committing logic
>>
>> "git fetch" that involves fetching tags, when a tag being fetched
>> needs to overwrite existing one, failed to fetch other tags, which
>> has been corrected.
>>
>> Will merge to 'next'?
>> source: <20251121-fix-tags-not-fetching-v8-0-23b53a8a8334@gmail.com>
>>
>>
>
> This should be ready for merge, it has been reviewed over multiple
> versions.
Other than the "eventhough" typo mentioned in
https://lore.kernel.org/git/CAOLa=ZQ-O7V9qHbgeuQ78R1bHGDmGEM6fP5Kr9aC0AfvSF8MZA@mail.gmail.com/
this topic should be ready, I tend to agree.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Dec 2025, #02)
@ 2025-12-09 23:10 99% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2025-12-09 23:10 UTC (permalink / raw)
To: Karthik Nayak; +Cc: git
Karthik Nayak <karthik.188@gmail.com> writes:
>> * kn/ref-location (2025-12-01) 2 commits
>> - refs: add GIT_REF_URI to specify reference backend and directory
>> - refs: support obtaining ref_store for given dir
>>
>> A mechanism to specify what reference backend to use and store
>> references in which directory is introduced, which would likely to
>> be useful during ref migration.
>>
>> Comments?
>> source: <20251201-kn-alternate-ref-dir-v3-0-c11b946bc2fa@gmail.com>
>
> I'm currently on leave. While I do plan to work on this, my next version
> which is based on Patricks recent review will be a bit delayed.
Understood. Thanks for a note.
>> * kn/fix-fetch-backfill-tag-with-batched-ref-updates (2025-11-21) 3 commits
>> - fetch: fix failed batched updates skipping operations
>> - fetch: fix non-conflicting tags not being committed
>> - fetch: extract out reference committing logic
>>
>> "git fetch" that involves fetching tags, when a tag being fetched
>> needs to overwrite existing one, failed to fetch other tags, which
>> has been corrected.
>>
>> Expecting a (hopefully small and final) reroll.
>> cf. <CAOLa=ZQ-O7V9qHbgeuQ78R1bHGDmGEM6fP5Kr9aC0AfvSF8MZA@mail.gmail.com>
>> source: <20251121-fix-tags-not-fetching-v8-0-23b53a8a8334@gmail.com>
>
> The only change needed from the last review was a typo. I think we should be
> good as is.
Meaning that we prefer to leave the typo in, or just we won't die
with a known typo?
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Dec 2025, #02)
@ 2025-12-10 9:20 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-12-10 9:20 UTC (permalink / raw)
To: Kristoffer Haugsbakk; +Cc: git, Phillip Wood
"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:
> On Tue, Dec 9, 2025, at 22:08, Junio C Hamano wrote:
>> * kh/doc-replay-updates (2025-12-07) 3 commits
>> - doc: replay: link section using markup
>> - doc: replay: document --contained
>> - doc: replay: mention no output on conflicts
>>
>> "git replay" documentation updates.
>>
>> Will merge to 'next'.
>> source: <CV_replay_conflict.101@msgid.xyz>
>
> This needs a new version to at the least incorporate the “Requires
> --onto” on `--contained` suggestion from Phillip.
Ah, very true. Thanks for correcting me.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Dec 2025, #02)
@ 2025-12-10 12:00 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-12-10 12:00 UTC (permalink / raw)
To: Karthik Nayak; +Cc: git
Karthik Nayak <karthik.188@gmail.com> writes:
>>>> Expecting a (hopefully small and final) reroll.
>>>> cf. <CAOLa=ZQ-O7V9qHbgeuQ78R1bHGDmGEM6fP5Kr9aC0AfvSF8MZA@mail.gmail.com>
>>>> source: <20251121-fix-tags-not-fetching-v8-0-23b53a8a8334@gmail.com>
>>>
>>> The only change needed from the last review was a typo. I think we should be
>>> good as is.
>>
>> Meaning that we prefer to leave the typo in, or just we won't die
>> with a known typo?
>
> The typo was in a comment in the tests, so I thought it wasn't worth
> re-rolling, but happy to do so.
I went back to the discussion to find that single typo and tweaked
it myself in my tree, so no need to resend.
Thanks.
diff --git c/t/t5510-fetch.sh w/t/t5510-fetch.sh
index a1ca4e1ac7..ce1c23684e 100755
--- c/t/t5510-fetch.sh
+++ w/t/t5510-fetch.sh
@@ -1628,7 +1628,7 @@ test_expect_success "backfill tags when providing a refspec" '
test_commit fetch-me
) &&
- # The "history" tag is backfilled eventhough we requested
+ # The "history" tag is backfilled even though we requested
# to only fetch HEAD
git -C target fetch origin HEAD:branch &&
git -C target tag -l >actual &&
^ permalink raw reply related [relevance 99%]
* Re: What's cooking in git.git (Dec 2025, #03)
@ 2025-12-17 5:04 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-12-17 5:04 UTC (permalink / raw)
To: Emily Shaffer
Cc: Adrian Ratiu, Patrick Steinhardt, git, Rodrigo Damazio Bovendorp,
Josh Steadmon, Ben Knoble, Phillip Wood, Kristoffer Haugsbakk
Emily Shaffer <nasamuffin@google.com> writes:
> FWIW, I also expect Josh Steadmon to find time to take a look at this
> series soon, but he has been busy with personal side of things for the
> last few days. It's not that there's disinterest from our side, more
> that there is a lot going on :)
Thanks, and thanks Josh for further inputs.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Dec 2025, #03)
@ 2025-12-17 13:46 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2025-12-17 13:46 UTC (permalink / raw)
To: Aaron Plattner; +Cc: git, Jeff King
Aaron Plattner <aplattner@nvidia.com> writes:
>> Let's mark the topic for 'next', then. Thanks.
>
> Thank you, I appreciate it!
;-)
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2026, #03)
@ 2026-01-09 14:01 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-01-09 14:01 UTC (permalink / raw)
To: Kristoffer Haugsbakk; +Cc: git
"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:
>> * kh/replay-invalid-onto-advance (2026-01-05) 6 commits
>> (merged to 'next' on 2026-01-08 at 1024748f91)
>> + t3650: add more regression tests for failure conditions
>> + replay: die if we cannot parse object
>> + replay: improve code comment and die message
>> + replay: die descriptively when invalid commit-ish is given
>> + replay: find *onto only after testing for ref name
>> + replay: remove dead code and rearrange
>> (this branch is used by ps/history and pw/replay-drop-empty.)
>>
>> Test coverage of "git replay" has been improved.
>
> I still disagree with this summary. ;)
>
> <460f1f96-4236-4d19-bdfa-6c86bad811c5@app.fastmail.com>
Thanks for reminding. Yes, I too disagree with it. I knew the main
change between the original two patches will need to be updated when
I first wrote it to queue the initial version, but it certainly is
not true with the main change (split across 5 patches now).
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2026, #04)
@ 2026-01-14 0:27 99% ` Junio C Hamano
1 sibling, 0 replies; 200+ results
From: Junio C Hamano @ 2026-01-14 0:27 UTC (permalink / raw)
To: git
The following topics have been merged to 'next'.
> * ps/ref-consistency-checks (2026-01-12) 17 commits
>
> Update code paths that check data integrity around refs subsystem.
>
> Will merge to 'next".
> cf. <CAOLa=ZShPP3BPXa=YnC-vuX4zF=pUTFdUidZwOdna8bfVTNM9w@mail.gmail.com>
> source: <20260112-pks-refs-verify-fixes-v2-0-2e9e453bd6c3@pks.im>
> * cs/rebased-subtree-split (2026-01-09) 1 commit
>
> The split command in "git subtree" (in contrib/) has been taught to
> deal better with rebased history.
>
> Will merge to 'next'.
> source: <20260110011811.788219-1-ask+git@howdoi.land>
> * kt/http-backend-errors (2026-01-11) 1 commit
>
> Some error messages from the http transport layer lacked the
> terminating newline, which has been corrected.
>
> Will merge to 'next'.
> source: <20260112014508.17248-1-kj@kjtsanaktsidis.id.au>
> * ps/t1410-cleanup (2026-01-11) 1 commit
>
> Test clean-up.
>
> Will merge to 'next'.
> source: <20260111191525.17087-1-pushkarkumarsingh1970@gmail.com>
> * tb/macos-iconv-workarounds (2026-01-11) 2 commits
>
> The iconv library on macOS fails to correctly handle stateful
> ISO/IEC 2022 encoded strings. Work it around instead of replacing
> it wholesale from homebrew.
>
> Will merge to 'next'.
> source: <20260111195151.716191-1-tboegi@web.de>
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2026, #04)
@ 2026-01-14 14:26 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-01-14 14:26 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
Patrick Steinhardt <ps@pks.im> writes:
> On Tue, Jan 13, 2026 at 12:10:13PM -0800, Junio C Hamano wrote:
>> * ps/read-object-info-improvements (2026-01-12) 8 commits
>> - packfile: drop repository parameter from `packed_object_info()`
>> - packfile: skip unpacking object header for disk size requests
>> - packfile: disentangle return value of `packed_object_info()`
>> - packfile: always populate pack-specific info when reading object info
>> - packfile: extend `is_delta` field to allow for "unknown" state
>> - packfile: always declare object info to be OI_PACKED
>> - object-file: always set OI_LOOSE when reading object info
>> - Merge branch 'jc/object-read-stream-fix' into ps/read-object-info-improvements
>>
>> The object-info API has been cleaned up.
>>
>> Comments?
>> source: <20260112-b4-pks-odb-read-object-info-improvements-v5-0-9a6124e95bf2@pks.im>
>
> I think this topic should be ready by now. The last iteration only added
> another test that catches a bug we recently started to hit in production
> systems, and the previous iterations all received reviews.
>
> I can try to loop in another set of reviewers though if you prefer.
For a topic like this with multiple iterations, I always revisit the
thread overview
https://lore.kernel.org/git/20260112-b4-pks-odb-read-object-info-improvements-v5-0-9a6124e95bf2@pks.im/
at lore, but it is hard to judge quickly if we have reached the
point of diminishing returns when the last few rounds got almost no
responses.
> I also noticed that the patch series at [1] is not in "seen" yet. Is
> that intentional or merely an oversight?
>
> Thanks!
>
> Patrick
>
> [1]: <20260105-pks-geometric-repack-with-promisors-v1-0-c4660573437e@pks.im>
It was more like "this topic saw a few responses, one saying the
thing is confusing, another saying the series is good up to one
point without mentioning anything about the later steps. perhaps it
is time to see an updated series, in which case my time is better
spent on other topics first".
Will take a look at them later today. Thanks for pinging.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2026, #05)
@ 2026-01-16 15:23 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-01-16 15:23 UTC (permalink / raw)
To: Elijah Newren; +Cc: git
Elijah Newren <newren@gmail.com> writes:
> On Thu, Jan 15, 2026 at 10:59 AM Junio C Hamano <gitster@pobox.com> wrote:
>
>> * ac/sparse-checkout-string-list-cleanup (2026-01-15) 1 commit
>> - sparse-checkout: optimize string_list construction
>>
>> Code clean-up.
>>
>> Will merge to 'next'.
>> ...
>
> Shouldn't it restore the string_list_remove_duplicates() calls first?
> (See 20260115200903.GB1053259@coredump.intra.peff.net and
> fc14e0e5-93bc-4805-a20d-d2aa4eb87ddb@web.de )
Yes, my mistake. The draft for the next issue of "What's cooking"
report has it corrected, almost immediately after I sent out the one
you are responding to. Thanks for confirming.
>> * pw/replay-drop-empty (2025-12-18) 2 commits
>> - replay: drop commits that become empty
>> - Merge branch 'ps/history' into pw/replay-drop-empty
>> (this branch uses ps/history.)
>>
>> "git replay" is taught to drop commits that become empty (not the
>> ones that are empty in the original).
>>
>> On hold, until the base topic gains consensus and stabilizes.
>> source: <375adc4e941f3bb22a2b12ee26a083951ed724dd.1766076625.git.phillip.wood@dunelm.org.uk>
>
> I think the base topic has done so now (as I'll note below), so this
> should be ready to advance.
THis has been blocked by ps/history for way too long. I think we
can finally move them now, which means they are good topics for the
next cycle.
>> * ps/history (2026-01-13) 9 commits
>> - builtin/history: implement "reword" subcommand
>> - builtin: add new "history" command
>> - wt-status: provide function to expose status for trees
>> - replay: support updating detached HEAD
>> - replay: support empty commit ranges
>> - replay: small set of cleanups
>> - builtin/replay: move core logic into "libgit.a"
>> - builtin/replay: extract core logic to replay revisions
>> - Merge branch 'kh/replay-invalid-onto-advance' into ps/history
>> (this branch is used by pw/replay-drop-empty.)
>>
>> "git history" history rewriting UI.
>>
>> Will merge to 'next'?
>> source: <20260113-b4-pks-history-builtin-v11-0-e74ebfa2652d@pks.im>
>
> Yes, I think it's ready.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2026, #06)
@ 2026-01-20 16:30 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-01-20 16:30 UTC (permalink / raw)
To: Shreyansh Paliwal; +Cc: git
Shreyansh Paliwal <shreyanshpaliwalcmsmn@gmail.com> writes:
> While going through, I noticed that patch [1] related to
> t5500-fetch-pack.sh doesn't appear in the seen branch yet.
>
> I just wanted to ask whether that got left unintentionally,
> or if it might still be pending any updates or changes.
When I saw it I thought "gee, the implementation and the explanation
have changed so much, this needs a full review", then I got
distracted X-<.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2026, #06)
2026-01-21 15:26 99% ` Junio C Hamano
@ 2026-01-21 16:20 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-01-21 16:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Ben Knoble, Johannes Sixt
Junio C Hamano <gitster@pobox.com> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>>> ...
>>> - Merge branch 'js/prep-symlink-windows' into js/symlink-windows
>>> (this branch uses js/prep-symlink-windows.)
>>>
>>> Upstream symbolic link support on Windows from Git-for-Windows.
>>>
>>> Expecting a reroll.
>>> cf. <5fe64b77-d10b-b66e-8622-14bec1e96f4a@gmx.de>
>>> cf. <14388349-d1b5-fc8f-b6c7-4a7b43e64494@gmx.de>
>>> cf. <704e952d-7924-00ce-b8b0-ad355e659335@gmx.de>
>>> source: <pull.2018.v2.git.1767989115.gitgitgadget@gmail.com>
>>
>> I do not quite understand.
>>
>> v2 was sent out on Jan 9. The three replies you are referring to as
>> blockers were all sent out on the same day, as replies to the respective
>> reviewer comments in v1. Naturally, whan I did sent out those replies
>> acknowleding problems whose fixes I promised, I did not then go on and
>> omit the fixes from v2!
>
> Sorry, my mistake. It is very possible that the references may be
> stale for this topic, as I can forget update them when I queue a
> newer iteration.
>
> Will take a look later today. Thanks.
I think I understood what happened. You send those referenced
messages to v1 review comments at the same time or after you sent
v2, and said "I'll drop this" or "I'll do that" in them, which
confused me into thinking "oh, after sending the v2 Dscho realized
there were still some things to be addressed and responded to v1
reviews?", hence these references. Sorry about the confusion.
Let's mark it for 'next'. As the "prep" topic will be part of -rc1,
I really didn't want just half the topic in the upcoming release
while leaving out the other half out of it. Thanks for pinging.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2026, #06)
@ 2026-01-21 15:26 99% ` Junio C Hamano
2026-01-21 16:20 99% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2026-01-21 15:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> ...
>> - Merge branch 'js/prep-symlink-windows' into js/symlink-windows
>> (this branch uses js/prep-symlink-windows.)
>>
>> Upstream symbolic link support on Windows from Git-for-Windows.
>>
>> Expecting a reroll.
>> cf. <5fe64b77-d10b-b66e-8622-14bec1e96f4a@gmx.de>
>> cf. <14388349-d1b5-fc8f-b6c7-4a7b43e64494@gmx.de>
>> cf. <704e952d-7924-00ce-b8b0-ad355e659335@gmx.de>
>> source: <pull.2018.v2.git.1767989115.gitgitgadget@gmail.com>
>
> I do not quite understand.
>
> v2 was sent out on Jan 9. The three replies you are referring to as
> blockers were all sent out on the same day, as replies to the respective
> reviewer comments in v1. Naturally, whan I did sent out those replies
> acknowleding problems whose fixes I promised, I did not then go on and
> omit the fixes from v2!
Sorry, my mistake. It is very possible that the references may be
stale for this topic, as I can forget update them when I queue a
newer iteration.
Will take a look later today. Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2026, #07)
@ 2026-01-21 21:08 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-01-21 21:08 UTC (permalink / raw)
To: Lucas Seiki Oshiro; +Cc: git
Lucas Seiki Oshiro <lucasseikioshiro@gmail.com> writes:
> Hi, Junio
>
>> "git repo info" learns "--keys" action to list known keys.
>>
>> Will merge to 'next'?
>> source: <20260119210932.68893-1-lucasseikioshiro@gmail.com>
>
> Not yet. The last review by Patrick made me rethink the entire
> series and I still need to iterate a little more on it.
Yup, I already marked the topic to be expecting a (major) reroll.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2026, #08)
@ 2026-01-23 17:22 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-01-23 17:22 UTC (permalink / raw)
To: Toon Claes; +Cc: git
Toon Claes <toon@iotcl.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> * tc/last-modified-not-a-tree (2026-01-16) 4 commits
>> - last-modified: verify revision argument is a commit-ish
>> - last-modified: remove double error message
>> - last-modified: fix memory leak when more than one revision is given
>> - last-modified: rewrite error message when more than one revision given
>>
>> Giving "git last-modified" a tree (not a commit-ish) died an
>> uncontrolled death, which has been corrected.
>>
>> Will merge to 'next'.
>> source: <20260116-toon-last-modified-tree-v3-0-e6ade4dc35ab@iotcl.com>
>
> Sorry for the late response, I decided to reroll this after all. Changes
> are small though.
Thanks, I just took a look and had a few comments on the first one.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2026, #10)
@ 2026-01-30 5:43 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-01-30 5:43 UTC (permalink / raw)
To: Eric Sunshine; +Cc: git, Sam Bostock
Eric Sunshine <sunshine@sunshineco.com> writes:
> On Thu, Jan 29, 2026 at 6:52 PM Junio C Hamano <gitster@pobox.com> wrote:
>> * sb/doc-worktree-prune-expire-improvement (2026-01-27) 1 commit
>> - worktree: clarify that --expire only affects missing worktrees
>>
>> The help text and the documentation for the "--expire" option of
>> "git worktree [list|prune]" have been improved.
>>
>> Will merge to 'next'?
>> source: <pull.2135.v3.git.git.1769578785381.gitgitgadget@gmail.com>
>
> Yes, I believe that the recently-posted v3 addresses all the points
> covered by the two reviewers (Eric & Junio) who commented on the
> submission.
Yup, the latest round looked good. Thanks, both of you.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2026, #10)
@ 2026-01-30 16:50 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-01-30 16:50 UTC (permalink / raw)
To: Pushkar Singh; +Cc: git
Pushkar Singh <pushkarkumarsingh1970@gmail.com> writes:
> On Thu, Jan 15, 2026 at 12:26 PM Junio C Hamano wrote:
>> * ps/validate-prefix-in-subtree-split (2026-01-15) 1 commit
>> - subtree: validate --prefix against commit in split
>>
>> "git subtree split --prefix=P <commit>" now checks the prefix P
>> against the tree of the (potentially quite different from the
>> current working tree) given commit.
>>
>> Expecting a reroll?
>> source: <20260115122652.18673-2-pushkarkumarsingh1970@gmail.com>
>
> Hi Junio,
>
> Thanks for the update.
Sorry for the non-update ;-) The expectation was against v2 of this
patch, which was met with v3.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Feb 2026, #02)
@ 2026-02-06 19:37 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-02-06 19:37 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
Patrick Steinhardt <ps@pks.im> writes:
>> * ps/commit-list-functions-renamed (2026-01-15) 3 commits
>> - commit: rename `free_commit_list()` to conform to coding guidelines
>> - commit: rename `reverse_commit_list()` to conform to coding guidelines
>> - commit: rename `copy_commit_list()` to conform to coding guidelines
>>
>> Rename three functions around the commit_list data structure.
>>
>> Will merge to 'next'?
>> source: <20260115-pks-commit-list-coding-guidelines-v1-0-c58868dbf412@pks.im>
>
> I guess this one depends on the outcome of the discussion we had about
> renaming stuff. I think it's worth the churn, and don't expect to do
> another reroll. Otherwise I guess the series can be discarded.
After having it in 'seen' for half a month, we haven't seen any new
users to conflict with it, so I am inclined to say we go ahead and
merge it down.
>> * ps/odb-for-each-object (2026-01-26) 16 commits
>> - odb: drop unused `for_each_{loose,packed}_object()` functions
>> - reachable: convert to use `odb_for_each_object()`
>> - builtin/pack-objects: use `packfile_store_for_each_object()`
>> - odb: introduce mtime fields for object info requests
>> - treewide: drop uses of `for_each_{loose,packed}_object()`
>> - treewide: enumerate promisor objects via `odb_for_each_object()`
>> - builtin/fsck: refactor to use `odb_for_each_object()`
>> - odb: introduce `odb_for_each_object()`
>> - packfile: introduce function to iterate through objects
>> - packfile: extract function to iterate through objects of a store
>> - object-file: introduce function to iterate through objects
>> - object-file: extract function to read object info from path
>> - odb: fix flags parameter to be unsigned
>> - odb: rename `FOR_EACH_OBJECT_*` flags
>> - Merge branch 'ps/packfile-store-in-odb-source' into ps/odb-for-each-object
>> - Merge branch 'ps/read-object-info-improvements' into ps/odb-for-each-object
>>
>> Revamp object enumeration API around odb.
>>
>> Will merge to 'next'?
>> cf. <aXk2FjTUMMThs5Kp@nand.local>
>> source: <20260126-pks-odb-for-each-object-v4-0-5a64a038c791@pks.im>
>
> There's been some discussions around the mtime handling, but I think
> I've addressed the concerns both with documentation in v4 and with the
> plans I've layed out in <aXcrftLpfcG4S5AX@pks.im> and subsequent
> messages.
Let me ping the thread. Taylor asked a bit more time to discuss
mtime related changes a week ago and I do not recall seeing a
further discussion.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jan 2026, #09)
@ 2026-02-06 19:39 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-02-06 19:39 UTC (permalink / raw)
To: Taylor Blau; +Cc: Junio C Hamano, git
Taylor Blau <me@ttaylorr.com> writes:
> On Tue, Jan 27, 2026 at 09:42:00AM -0800, Junio C Hamano wrote:
>> * ps/odb-for-each-object (2026-01-26) 16 commits
>> - odb: drop unused `for_each_{loose,packed}_object()` functions
>> - reachable: convert to use `odb_for_each_object()`
>> - builtin/pack-objects: use `packfile_store_for_each_object()`
>> - odb: introduce mtime fields for object info requests
>> - treewide: drop uses of `for_each_{loose,packed}_object()`
>> - treewide: enumerate promisor objects via `odb_for_each_object()`
>> - builtin/fsck: refactor to use `odb_for_each_object()`
>> - odb: introduce `odb_for_each_object()`
>> - packfile: introduce function to iterate through objects
>> - packfile: extract function to iterate through objects of a store
>> - object-file: introduce function to iterate through objects
>> - object-file: extract function to read object info from path
>> - odb: fix flags parameter to be unsigned
>> - odb: rename `FOR_EACH_OBJECT_*` flags
>> - Merge branch 'ps/packfile-store-in-odb-source' into ps/odb-for-each-object
>> - Merge branch 'ps/read-object-info-improvements' into ps/odb-for-each-object
>>
>> Revamp object enumeration API around odb.
>>
>> Will merge to 'next'?
>> source: <20260126-pks-odb-for-each-object-v4-0-5a64a038c791@pks.im>
>
> I have some lingering questions about the mtime-related changes. I am
> not opposed to the series in general, but I think some more time to
> continue the discussion in that thread would be beneficial before
> starting to merge it down.
Has any further discussions took place outside the original thread
https://lore.kernel.org/git/20260126-pks-odb-for-each-object-v4-0-5a64a038c791@pks.im/
or are we pretty much done with this iteration and polish
incrementally if necessary?
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Feb 2026, #03)
@ 2026-02-09 16:37 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-02-09 16:37 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
Patrick Steinhardt <ps@pks.im> writes:
>> * yt/merge-file-outside-a-repository (2026-02-05) 1 commit
> This patch looks good to me.
Likewise.
>> * ps/meson-gitk-git-gui (2026-02-04) 1 commit
> Probably makes more sense to say that this is waiting on a pull request
> of gitk, as the patch series itself doesn't need to change.
Thanks for a reminder. Updated.
>> * jc/checkout-switch-restore (2026-01-29) 2 commits
> I think this is a good change, and I'm happy with the current layout. I
> had the tiniest nit on the first patch, but really don't think the
> series needs a reroll because of it.
Thanks again. Updated.
>> * ps/for-each-ref-in-fixes (2026-02-05) 4 commits
> I expect it's ready, but I'd like to wait for Taylor to have a final
> look before we merge it down.
Noted.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Feb 2026, #04)
@ 2026-02-11 20:46 99% ` Junio C Hamano
1 sibling, 0 replies; 200+ results
From: Junio C Hamano @ 2026-02-11 20:46 UTC (permalink / raw)
To: git; +Cc: Patrick Steinhardt, Abraham Samuel Adekunle
Junio C Hamano <gitster@pobox.com> writes:
Sorry, but I need to fix a few obvious "oops, that's embarrassing"
mistakes.
> * aa/add-p-no-auto-advance (2026-02-06) 3 commits
> - add-patch: Allow proper 'git apply' when using the --rework-with-file flag
> - add-patch: Allow interfile navigation when selecting hunks
> - interactive -p: add new `--rework-with-file` flag to interactive machinery
>
> "git add -p" learned a new mode that allows the user to revisit a
> file that was already dealt with.
>
> Expecting a gitk update.
> source: <cover.1770390576.git.abrahamadekunle50@gmail.com>
No, this is not about "gitk" at all. It is expecting a hopefully
small and final reroll.
> * ps/meson-gitk-git-gui (2026-02-04) 1 commit
> - meson: wire up gitk and git-gui
>
> Plumb gitk/git-gui build and install procedure in meson based
> builds.
>
> Expecting a reroll.
> source: <20260204-b4-pks-meson-tcl-tk-v2-1-5bc3ccf3a8ce@pks.im>
This is the one that waits updated "gitk".
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Feb 2026, #04)
@ 2026-02-12 16:38 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-02-12 16:38 UTC (permalink / raw)
To: Phillip Wood; +Cc: git
Phillip Wood <phillip.wood123@gmail.com> writes:
> On 10/02/2026 22:21, Junio C Hamano wrote:
>>
>> * pw/commit-msg-sample-hook (2026-02-07) 3 commits
>> - templates: detect messages that contain a separator line
>> - templates: detect commit messages containing diffs
>> - templates: add .gitattributes entry for sample hooks
>>
>> Update sample commit-msg hook to complain when a log message has
>> material mailinfo considers the end of log message in the middle.
>>
>> Will merge to 'next'?
>> source: <cover.1770476279.git.phillip.wood@dunelm.org.uk>
>
> I'm planning a re-roll to handle subject lines that start with "diff -"
> after using this hook while preparing
> <2a8cc2d6c37f25a58823b501500165d597321749.1770911599.git.phillip.wood@dunelm.org.uk>.
> Such subject lines are safe because "git format-patch" prefixes them
> with [PATCH]. I think I'll probably drop the last patch as well.
OK. Even though the "[PATCH] " prefix is optional in format-patch
output, it will be on the line that begins with "Subject:", so it
should be safe, so you can safely exclude the lines in the first
paragraph of a commit message from the check.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: ds/revision-maximal-only (was Re: What's cooking in git.git (Feb 2026, #05))
@ 2026-02-17 16:33 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-02-17 16:33 UTC (permalink / raw)
To: Derrick Stolee; +Cc: git
Derrick Stolee <stolee@gmail.com> writes:
> On 2/13/26 9:01 PM, Junio C Hamano wrote:
>
>> * ds/revision-maximal-only (2026-01-22) 1 commit
>> - revision: add --maximal-only option
>>
>> "git rev-list" and friends learn "--maximal-only" to show only the
>> commits that are not reachable by other commits.
>>
>> Will merge to 'next'?
>> source: <pull.2032.v2.git.1769097958549.gitgitgadget@gmail.com>
>
> This has been stable for a few weeks, so I think it's ready for
> 'next'.
I am not 100% sure if "stable" is the most appropriate word to
describe the topic, or if it is "dormant". Let's merge it down.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Feb 2026, #08)
@ 2026-02-23 21:45 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-02-23 21:45 UTC (permalink / raw)
To: Kristoffer Haugsbakk; +Cc: git, Jeff King
"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:
> On Mon, Feb 23, 2026, at 16:13, Junio C Hamano wrote:
>> * kh/format-patch-noprefix-is-boolean (2026-02-18) 2 commits
>> - doc: diff-options.adoc: show format.noprefix for format-patch
>> - format-patch: make format.noprefix a boolean
>>
>> The configuration variable format.noprefix did not behave as a
>> proper boolean variable, which has now been fixed and documented.
>>
>> Will merge to 'next'?
>> cf. <xmqqy0ko626g.fsf@gitster.g>
>> source: <CV_format.noprefix_boolean.39c@msgid.xyz>
>
> I’ll make a new version.
Noted. Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Feb 2026, #11)
@ 2026-03-02 19:07 99% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2026-03-02 19:07 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Adrian Ratiu
Patrick Steinhardt <ps@pks.im> writes:
> On Fri, Feb 27, 2026 at 05:02:12PM -0800, Junio C Hamano wrote:
>> * ar/run-command-hook-take-2 (2026-01-28) 12 commits
>> (merged to 'next' on 2026-02-22 at 4aa543f115)
>> + receive-pack: convert receive hooks to hook API
>> + receive-pack: convert update hooks to new API
>> + run-command: poll child input in addition to output
>> + hook: add jobs option
>> + reference-transaction: use hook API instead of run-command
>> + transport: convert pre-push to hook API
>> + hook: allow separate std[out|err] streams
>> + hook: convert 'post-rewrite' hook in sequencer.c to hook API
>> + hook: provide stdin via callback
>> + run-command: add stdin callback for parallelization
>> + run-command: add helper for pp child states
>> + t1800: add hook output stream tests
>> (this branch is used by ar/config-hooks and ar/parallel-hooks.)
>>
>> Use the hook API to replace ad-hoc invocation of hook scripts via
>> the run_command() API.
>>
>> Will merge to 'master'.
>> source: <20260128213927.3026875-1-adrian.ratiu@collabora.com>
>
> It would be great if you could hold off merging this patch series for
> now. There's a rather steep performance regression in the "update" hook
> caused by this series, see also [1].
Thanks. I'll be expecting an incremental update for this.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Feb 2026, #11)
@ 2026-03-02 21:41 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-03-02 21:41 UTC (permalink / raw)
To: Adrian Ratiu; +Cc: Patrick Steinhardt, git
Adrian Ratiu <adrian.ratiu@collabora.com> writes:
>>> It would be great if you could hold off merging this patch series for
>>> now. There's a rather steep performance regression in the "update" hook
>>> caused by this series, see also [1].
>>
>> Thanks. I'll be expecting an incremental update for this.
>
> Fix posted:
>
> https://lore.kernel.org/git/20260302191704.1814567-1-adrian.ratiu@collabora.com/T/#t
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Mar 2026, #01)
@ 2026-03-03 18:43 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-03-03 18:43 UTC (permalink / raw)
To: Derrick Stolee; +Cc: git
Derrick Stolee <stolee@gmail.com> writes:
> On 3/2/2026 10:15 PM, Junio C Hamano wrote:
>
>> * ds/for-each-repo-w-worktree (2026-03-02) 4 commits
>> - for-each-repo: simplify passing of parameters
>> - for-each-repo: work correctly in a worktree
>> - run-command: extract clear_local_repo_env helper
>> - for-each-repo: test outside of repo context
>>
>> "git for-each-repo" started from a secondary worktree did not work
>> as expected, which has been corrected.
>>
>> Will merge to 'next'?
>> source: <pull.2056.v3.git.1772465805.gitgitgadget@gmail.com>
>
> I just posted v4 with some final polish [1].
Yup, I saw it and it made sense (including the chocie of where 'int
i' is removed). Queued.
'
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Mar 2026, #03)
@ 2026-03-07 6:47 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-03-07 6:47 UTC (permalink / raw)
To: Eric Sunshine; +Cc: git
Eric Sunshine <sunshine@sunshineco.com> writes:
> On Fri, Mar 6, 2026 at 9:23 PM Junio C Hamano <gitster@pobox.com> wrote:
>> * fp/t3310-unhide-git-failures (2026-03-05) 1 commit
>> - t3310: avoid hiding failures from rev-parse in command substitutions
>>
>> The construct 'test "$(command)" = expectation' loses the exit
>> status from the command, which has been fixed by breaking up the
>> statement into pieces.
>>
>> Will merge to 'next'.
>> source: <20260305225128.54283-1-francescopaparatto@gmail.com>
>
> Perhaps one more reroll of this topic is in order[*]?
>
> [*]: https://lore.kernel.org/git/CAPig+cQWCK48GJEnGX7bP6exu847WR8HU3Y8sna525w6NEhmmw@mail.gmail.com/
Perhaps. Thanks for a prompt review.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Mar 2026, #05)
@ 2026-03-13 4:24 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-03-13 4:24 UTC (permalink / raw)
To: Jeff King; +Cc: git
Jeff King <peff@peff.net> writes:
> On Thu, Mar 12, 2026 at 05:10:31PM -0700, Junio C Hamano wrote:
>
>> * mf/apply-p-no-atoi (2026-03-09) 1 commit
>> - apply.c: fix -p argument parsing
>>
>> "git apply -p<n>" parses <n> more carefully now.
>>
>> Will merge to 'next'.
>> source: <20260310050621.3849719-1-mroik@delayed.space>
>
> I think this is responsible for test failures on Windows in jch/seen,
> but I'm stumped as to why. You might want to hold off until we figure
> it out.
>
> From the output I doubt the code change is responsible, but failing
> tests in 'next' is annoying.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Mar 2026, #05)
@ 2026-03-18 16:36 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-03-18 16:36 UTC (permalink / raw)
To: Jeff King; +Cc: Taylor Blau, git
Jeff King <peff@peff.net> writes:
> On Mon, Mar 16, 2026 at 06:07:41PM -0400, Taylor Blau wrote:
>
>> On Thu, Mar 12, 2026 at 05:10:31PM -0700, Junio C Hamano wrote:
>> > * tb/incremental-midx-part-3.2 (2026-02-24) 17 commits
>> > - midx: enable reachability bitmaps during MIDX compaction
>> > - midx: implement MIDX compaction
>> ...
>> > Further work on incremental repacking using MIDX/bitmap
>> >
>> > Will merge to 'next'?
>> > source: <cover.1771959555.git.me@ttaylorr.com>
>>
>> I think that this one is ready to go. There was a relatively small
>> range-diff between v2 and v3 based on Peff's review of the earlier
>> round.
>>
>> That review[1] said that:
>>
>> There were a couple minor issues brought up in review, like
>> out-dated comments and the u32_add interface. So I think we might
>> need a v3 with a few touch-ups, but that's it.
>>
>> , so I think with the latest round we should be OK to start merging this
>> one down.
>
> Yeah, I looked over the range-diff for v3 and didn't have anything
> further to add.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Mar 2026, #08)
@ 2026-03-22 17:50 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-03-22 17:50 UTC (permalink / raw)
To: René Scharfe; +Cc: git, Johannes Schindelin
René Scharfe <l.s.r@web.de> writes:
> On 3/22/26 7:46 AM, Junio C Hamano wrote:
>> * js/macos-homebrew-forgets-reg-enhanced (2026-03-20) 1 commit
>> - osx-clang: work around Homebrew's clang lacking REG_ENHANCED
>>
>> The build on macOS with Clang is fixed to work around a Homebrew change
>> that exposed an issue with missing REG_ENHANCED.
>>
>> Will merge to 'next'?
>> source: <d340af9e-334c-4e81-e58a-fc3dea73ebdd@gmx.de>
> This seems to no longer be necessary -- the latest workflow run on
> master succeeded (https://github.com/git/git/actions/runs/23392330338).
Yeah, I saw that too and was wondering if the glitch was reverted or
something at the platform side.
> Did some kind soul fix the runners?
If so, thanks. It certainly was not me ;-)
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Mar 2026, #08)
@ 2026-03-22 17:53 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-03-22 17:53 UTC (permalink / raw)
To: Shreyansh Paliwal; +Cc: git
Shreyansh Paliwal <shreyanshpaliwalcmsmn@gmail.com> writes:
> Though you fixed the conflicts while merging the old version, commit is not
> yet replaced <20260318090546.1213077-1-shreyanshpaliwalcmsmn@gmail.com>.
The end result would be better with the initial one after all, as it
could be merged down without somebody else's patch you do not need
to depend on, so let's keep it as-is. I'll need to replace the
status comment, as this has been reviewed and looks good, and it
also seems nobody complains about what the patch does.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Mar 2026, #10)
@ 2026-03-25 19:50 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-03-25 19:50 UTC (permalink / raw)
To: Shreyansh Paliwal; +Cc: git
Shreyansh Paliwal <shreyanshpaliwalcmsmn@gmail.com> writes:
>> * sp/add-patch-with-fewer-the-repository (2026-03-17) 1 commit
>> - add-patch: use repository instance from add_i_state instead of the_repository
>>
>> Reduce dependency on `the_repository` in add-patch.c file.
>>
>> Needs review.
>> source: <20260317155230.619378-1-shreyanshpaliwalcmsmn@gmail.com>
>
> I think this was considered ready in the previous 'What's cooking in git.git',
> so the status can be changed now.
This was listed in the new topics section in issue #07 (Mar 19) but
I do not recall updating its status in any later issue. The only
change was in issue #08 (Mar 21) in which the topic was moved from
new to cooking without changing any status.
The only comment the patch got was from me about interaction with
other topics in flight, and there was no discussion or comments on
what the patch wants to do makes sense, or if the way how the patch
does so is correct, which should be the real review.
And I do not consider my single reading alone a sufficient review
most of the time.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Mar 2026, #11)
@ 2026-03-27 16:08 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-03-27 16:08 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
Patrick Steinhardt <ps@pks.im> writes:
>> * ps/commit-graph-overflow-fix (2026-03-23) 1 commit
>> - commit-graph: fix writing generations with dates exceeding 34 bits
>> ...
>> Waiting for review response.
>> cf. <xmqq1ph92pzs.fsf@gitster.g>
>> source: <20260324-pks-commit-graph-overflow-v2-1-843568cf8780@pks.im>
>
> Hm, I think this status is probably stale, as I've sent out that
> response already
Indeed. I am not convinced by the argument "64-bit compilers would
not care if 32-bit part of the live code that it will optimize away
is not -Werror clean", but we can merge it as-is and then deal with
any fallout later, as it should be trivial to switch to conditional
compilation (the triviality is why I suggested making the change now
in the first place anyway).
>> * ar/config-hook-cleanups (2026-03-25) 13 commits
>> ...
>> Code clean-up around the recent "hooks defined in config" topic.
>>
>> Will merge to 'next'?
>> source: <20260325195503.1139418-1-adrian.ratiu@collabora.com>
>
> I'll have a look at v3 of this series series today.
Thanks.
>> * ar/parallel-hooks (2026-03-26) 13 commits
>> ...
>
> Likewise, will try to find the time to do this today.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Mar 2026, #11)
@ 2026-03-27 16:13 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-03-27 16:13 UTC (permalink / raw)
To: Christian Couder; +Cc: git, Toon Claes, Phillip Wood
Christian Couder <christian.couder@gmail.com> writes:
> On Fri, Mar 27, 2026 at 12:17 AM Junio C Hamano <gitster@pobox.com> wrote:
>
>> * tc/replay-down-to-root (2026-03-24) 1 commit
>> - replay: support replaying down from root commit
>>
>> git replay now supports replaying down to the root commit.
>>
>> Will merge to 'next'?
>> source: <20260324-toon-replay-down-to-root-v2-1-34e723489f6e@iotcl.com>
>
> As Toon said that the silent failure in case of "topic" instead of
> "main..topic" will be addressed in a separate series, I am fine with
> merging as is.
I'll have to go back to list to find the original discussion to
refresh my memory to know what "main..topic" vs "topic" is about,
though X-<.
>> * sa/replay-revert (2026-03-25) 2 commits
>> - replay: add --revert mode to reverse commit changes
>> - sequencer: extract revert message formatting into shared function
>> (this branch is used by tc/replay-ref.)
>>
>> "git replay" (experimental) learns, in addition to "pick" and
>> "replay", a new operating mode "revert".
>>
>> Will merge to 'next'?
>> source: <20260325202354.10628-1-siddharthasthana31@gmail.com>
>
> It looks good to me, and I think the v6 properly addresses the latest
> few small issues that were found. Previously Phillip also seemed OK
> with merging except for the issues that are now fixed.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Mar 2026, #12)
@ 2026-03-31 15:15 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-03-31 15:15 UTC (permalink / raw)
To: Mirko Faina; +Cc: git
Mirko Faina <mroik@delayed.space> writes:
> On Mon, Mar 30, 2026 at 05:10:42PM -0700, Junio C Hamano wrote:
>> * mf/format-patch-commit-list-format-doc (2026-03-27) 3 commits
>> - format-patch: removing unconditional wrapping
>> - docs: fix --commit-list-format related entries
>> - Merge branch 'mf/format-patch-commit-list-format' into mf/format-patch-commit-list-format-doc
>> (this branch uses mf/format-patch-commit-list-format and mf/format-patch-cover-letter-format.)
>>
>> Doc updates.
>>
>> Will merge to 'next'.
>> source: <cover.1774640789.git.mroik@delayed.space>
Yeah, you're right. The other two should wait for this one to avoid
disruption.
Thanks for noticing.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Mar 2026, #12)
@ 2026-03-31 15:27 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-03-31 15:27 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
Patrick Steinhardt <ps@pks.im> writes:
> On Mon, Mar 30, 2026 at 05:10:42PM -0700, Junio C Hamano wrote:
>> * ps/commit-graph-overflow-fix (2026-03-23) 1 commit
>> - commit-graph: fix writing generations with dates exceeding 34 bits
>>
>> Fix a regression in writing the commit-graph where commits with dates
>> exceeding 34 bits (beyond year 2514) could cause an underflow and
>> crash Git during the generation data overflow chunk writing.
>>
>> Waiting for review response.
>> cf. <xmqq1ph92pzs.fsf@gitster.g>
>> source: <20260324-pks-commit-graph-overflow-v2-1-843568cf8780@pks.im>
>
> Shall this also be marked as "Will merge to next" based on our last
> discussion at [1]? I mostly want to ensure this is part of rc0 so that
> the regression isn't part of any tagged release, even if it's just a
> release candidate.
Even though I still feel uncomfortable hurrying to merge down an
obviously UB code, instead of an uglier but far safer conditional
compilation, patching it on top is trivial, so let's mark it for
'next'. Thanks for spotting.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Apr 2026, #01)
@ 2026-04-09 20:09 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-04-09 20:09 UTC (permalink / raw)
To: René Scharfe; +Cc: git
René Scharfe <l.s.r@web.de> writes:
> On 4/2/26 1:42 AM, Junio C Hamano wrote:
>> * rs/use-strvec-pushv (2026-03-24) 2 commits
>> (merged to 'next' on 2026-03-24 at 7c6487dcaf)
>> + use strvec_pushv() to add another strvec
>> + Merge branch 'ps/build-tweaks' into rs/use-strvec-pushv
>>
>> Code paths that loop over another array to push each element into a
>> strvec have been rewritten to use strvec_pushv() instead.
>> source: <084f3b43-91ac-4553-8305-03944e97eaa6@web.de>
>
> Curious:
>
> commit 250e977a2b0aa8cc1c8063c64c44597a166e79f5
> Author: Junio C Hamano <gitster@pobox.com>
> Date: Tue Mar 24 12:26:58 2026 -0700
>
> use strvec_pushv() to add another strvec
>
> Add and apply a semantic patch that simplifies the code by letting
> strvec_pushv() append the items of a second strvec instead of pushing
> them one by one.
>
> Suggested-by: Junio C Hamano <gitster@pobox.com>
> Signed-off-by: René Scharfe <l.s.r@web.de>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>
> I guess you became the author when you resolved the merge conflict
> caused by moving contrib/coccinelle/ to tools/?
>
> René
Curious indeed, thanks for noticing, and sorry for the mistake.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (May 2026, #03)
@ 2026-05-13 16:06 99% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2026-05-13 16:06 UTC (permalink / raw)
To: Pushkar Singh; +Cc: git
Pushkar Singh <pushkarkumarsingh1970@gmail.com> writes:
> I noticed my stash test patch did not appear in the list, so I just
> wanted to gently follow up in case it got missed.
>
> Patch Link: https://lore.kernel.org/git/20260505103332.43702-2-pushkarkumarsingh1970@gmail.com/T/#u
When somebody else discussed on the topic or if I find the topic may
be interesting, I often pick up such patches to keep in 'seen'.
I am not sure if it qualifies as "got missed", but it seems nobody
discussed the topic, and I wasn't sure what the point was myself.
Surely we can pile on tests that demonstrates a command works in a
certain way, but is this particular test demonstrate something we
are likely to break, or something?
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (May 2026, #03)
@ 2026-05-15 1:46 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-05-15 1:46 UTC (permalink / raw)
To: Pushkar Singh; +Cc: git
Pushkar Singh <pushkarkumarsingh1970@gmail.com> writes:
> My thinking was mainly that git stash show normally omits untracked
> changes, while --include-untracked consults the additional untracked
> parent of the stash commit.
>
> I did not see existing coverage specifically checking that behavior,
Ah, OK. Please more explicitly state that it is filling a gap in
test coverage in the proposed log message; it would have helped to
sell the patch better. Adding even more when we already have
adequate coverage is one thing, covering the cases we had no
coverage is totally different matter.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (May 2026, #03)
@ 2026-05-15 17:06 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-05-15 17:06 UTC (permalink / raw)
To: Karthik Nayak; +Cc: git
Karthik Nayak <karthik.188@gmail.com> writes:
> Hello Junio,
>
> I've not been active on the list past few weeks, did we reach a
> consensus about
> 20260420-refs-fsck-skip-lock-files-v1-1-c2595e206a76@gmail.com ? Or was
> it missed, I thought it was in a ready state, but happy to reiterate as
> needed.
>
> Lore: https://lore.kernel.org/git/20260420-refs-fsck-skip-lock-files-v1-1-c2595e206a76@gmail.com/#t
I've not been active on the list past few weeks, either, so please
don't expect me to know anything that happened during my 3-week
absense ;-)
My understanding of the status of that thread is that after
https://lore.kernel.org/git/CAOLa=ZT1zE+MLeaYE_5jWmNzSvtTTBw3ZAopai+2Ei27kmYm2g@mail.gmail.com/
that said you "Will add ... locally", we are all waiting for you to
say either "after waiting for sufficient amount of time, there
wasn't any other major change necessary, so I won't add it locally
after all" or "we have waited for sufficient amount of time, so here
is the hopefully final edition that includes what I added locally
following Patrick's review".
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (May 2026, #04)
@ 2026-05-20 2:35 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-05-20 2:35 UTC (permalink / raw)
To: Jeff King; +Cc: Taylor Blau, git
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 [relevance 99%]
* Re: What's cooking in git.git (May 2026, #04)
@ 2026-05-20 2:37 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-05-20 2:37 UTC (permalink / raw)
To: Justin Tobler; +Cc: git
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 [relevance 99%]
* Re: What's cooking in git.git (May 2026, #05)
@ 2026-05-20 6:38 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-05-20 6:38 UTC (permalink / raw)
To: Jeff King; +Cc: git
Jeff King <peff@peff.net> writes:
> On Wed, May 20, 2026 at 02:19:24PM +0900, Junio C Hamano wrote:
>
>> * jk/commit-graph-lazy-load-fallback (2026-05-18) 1 commit
>> - commit: fall back to full read when maybe_tree is NULL
>>
>> The logic to lazy-load trees from the commit-graph has been made
>> more robust by falling back to reading the commit object when
>> the commit-graph is no longer available.
>>
>> Will merge to 'next'?
>> source: <20260519050513.GA1635924@coredump.intra.peff.net>
>
> I posted an updated patch in response to your suggestion to use
> parse_oid_hex_algop(), but it looks like the topic in your repo has the
> original.
Indeed, with sufficient amount of front matter before the scissors
line, I missed the patch X-<.
Applied. Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jun 2026, #03)
@ 2026-06-11 16:10 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-06-11 16:10 UTC (permalink / raw)
To: Phillip Wood; +Cc: git
Phillip Wood <phillip.wood123@gmail.com> writes:
> Hi Junio
>
> On 09/06/2026 01:56, Junio C Hamano wrote:
>>
>> * 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>
>
> I replied to that message with
> <4fafee2c-4151-45f4-a842-17d6b77d951c@gmail.com> I'm waiting to hear
> whether you agree that the unambiguous label case is unlikely enough to
> happen that we can ignore it.
Thanks.
I forgot to send the response to the message, so I just have done
so.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jun 2026, #04)
@ 2026-06-11 18:55 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-06-11 18:55 UTC (permalink / raw)
To: Mirko Faina; +Cc: git
Mirko Faina <mroik@delayed.space> writes:
> On Thu, Jun 11, 2026 at 09:08:25AM -0700, Junio C Hamano wrote:
>> * mf/revision-max-count-oldest (2026-05-18) 1 commit
>> (merged to 'next' on 2026-06-09 at 076600fa21)
>> + 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 'master'.
>> source: <xmqq4ijm3p2x.fsf@gitster.g>
>
> Might want to wait and merge it in with [1].
>
> [1] https://lore.kernel.org/git/a804828a046d8f12ef0d03eaf014807b079bb707.1781102091.git.mroik@delayed.space/
Thanks for reminding me. Will do.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jun 2026, #07)
@ 2026-06-22 12:50 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-06-22 12:50 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
Patrick Steinhardt <ps@pks.im> writes:
> On Fri, Jun 19, 2026 at 06:33:33PM -0700, Junio C Hamano wrote:
>> * ps/gitlab-ci-windows (2026-06-15) 1 commit
>> - gitlab-ci: migrate Windows builds away from Chocolatey
>> ...
> Might even be a candidate to also merge to `master` before the release,
> if you feel comfortable with that.
Yeah, exactly my thought. I've carelessly merged some stuff that
had wider implications (I do not think they are buggy after reading
the patches, though) than the topic name suggested near the tip of
'master' recently, but compared to them the potential blast radius
of this topic is certainly much smaller ;-)
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jun 2026, #10)
@ 2026-06-30 19:27 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-06-30 19:27 UTC (permalink / raw)
To: Toon Claes; +Cc: git
Toon Claes <toon@iotcl.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> * ps/odb-generalize-prepare (2026-06-22) 3 commits
>> - odb: introduce `odb_prepare()`
>> - odb/source: generalize `reprepare()` callback
>> - Merge branch 'ps/odb-source-packed' into ps/odb-generalize-prepare
>> (this branch uses ps/odb-source-packed.)
>>
>> The `reprepare()` callback for object database sources has been
>> generalized into a `prepare()` callback with an optional flush cache
>> flag, and a new `odb_prepare()` wrapper has been introduced to
>> allow pre-opening object database sources.
>>
>> Needs review.
>> source: <20260622-b4-pks-odb-generalize-prepare-v1-0-d2a5c5d13144@pks.im>
>
> I did have some questions/remarks, but Patrick answered them, and with
> those answers I'm happy about this series.
Yeah, I am also happy with these patches.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jul 2026, #01)
@ 2026-07-03 20:39 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-07-03 20:39 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
Patrick Steinhardt <ps@pks.im> writes:
> On Wed, Jul 01, 2026 at 04:40:16PM -0700, Junio C Hamano wrote:
>> * ps/odb-drop-whence (2026-06-24) 7 commits
> I'll send a small reroll to rename `sourcep` to `source_infop` based on
> Justin's feedback.
>
>> * ps/odb-generalize-prepare (2026-06-22) 3 commits
> This one should be ready.
>
>> * ps/refs-writing-subcommands (2026-06-30) 5 commits
> Likewise.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jul 2026, #03)
@ 2026-07-08 16:14 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-07-08 16:14 UTC (permalink / raw)
To: Kristofer Karlsson; +Cc: git
Kristofer Karlsson <krka@spotify.com> writes:
> I tried building v6 of kk/merge-base-exhaustion on top of
> kk/commit-reach-find-all-fix but since that one is based
> on kk/paint-down-to-common-optim it does not include
> the changes from kk/commit-reach-optim which I also depend
> on.
>
> I thus think the status of kk/merge-base-exhaustion should
> instead be:
> "On hold, waiting for kk/commit-reach-find-all-fix to land first."
>
> Alternatively you could rebase kk/commit-reach-find-all-fix
> on master (triggers a small conflict though) and that would
> also unblock a reroll (but I don't want to generate more work for you).
When topic A depends on topic B and topic C, rather than rebasing A
on 'next' (if B and C are in 'next'), I would often do
$ git checkout -b A master
$ git merge --no-ff B
$ git merge --no-ff C
these days to prepare the "base" to apply patches that belong to A.
Many contributors mimic this and state in their cover letter that
the patches in the series are to be applied on top of master at
commit X with branches Y and Z merged, or something to that effect.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jul 2026, #09)
@ 2026-07-22 18:27 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-07-22 18:27 UTC (permalink / raw)
To: Christian Couder; +Cc: git
Christian Couder <christian.couder@gmail.com> writes:
>> * cc/fast-import-usage (2026-07-16) 7 commits
>> - fast-import: use struct option for usage string
>> - fast-import: move command state globals into 'struct fast_import_state'
>> - fast-import: introduce 'struct fast_import_state'
>> - fast-import: localize 'i' into the 'for' loops using it
>> - api-parse-options.adoc: document hidden and OPT_*_F option macros
>> - api-parse-options.adoc: document per-option flags
>> - parse-options: introduce OPT_HIDDEN_GROUP
>>
>> The usage string of 'git fast-import' has been updated to use the
>> 'parse_options' API for displaying help, and its SYNOPSIS in the
>> documentation has been standardized to match.
>>
>> Waiting for response.
>> cf. <xmqq4ihyehyb.fsf@gitster.g>
>> source: <20260716165517.433849-1-christian.couder@gmail.com>
>
> I am having a vacation, so I will likely not be able to reply soon.
> Feel free to discard in the meantime.
I'll leave it as-is (unless somebody else comes in and crashes with
the changes in the topic badly, in which case I may eject one or the
other from my tree). Enjoy your vacation.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jul 2026, #10)
@ 2026-07-24 0:33 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-07-24 0:33 UTC (permalink / raw)
To: Pablo Sabater; +Cc: git
"Pablo Sabater" <pabloosabaterr@gmail.com> writes:
> On Thu Jul 23, 2026 at 4:38 AM CEST, Junio C Hamano wrote:
>>
>> * ps/cat-file-remote-object-info (2026-07-18) 13 commits
>> - cat-file: make remote-object-info allow-list adapt to the server
>> - cat-file: add remote-object-info to batch-command
>> - transport: add client support for object-info
>> - serve: advertise object-info feature
>> - protocol-caps: check object existence regardless of the attributes requested
>> - fetch-pack: move fetch initialization
>> - connect: make write_fetch_command_and_capabilities() more generic
>> - fetch-pack: move write_fetch_command_and_capabilities() to connect.c
>> - fetch-pack: use unsigned int for hash_algo variable
>> - fetch-pack: drop the static advertise_sid variable
>> - t1006: extract helper functions into new 'lib-cat-file.sh'
>> - cat-file: declare loop counter inside for()
>> - transport-helper: fix memory leak of helper on disconnect
>>
>> The 'remote-object-info' command has been added to 'git cat-file
>> --batch-command', allowing clients to request object metadata
>> (currently size) from a remote server via protocol v2 without
>> downloading the entire object. Format placeholders are dynamically
>> filtered on the client based on server-advertised capabilities,
>> returning empty strings for inapplicable or unsupported fields.
>>
>> Needs review.
>> source: <20260718-ps-eric-work-rebase-v20-0-0c13962ac532@gmail.com>
>>
>
> Hi,
>
> Karthik reviewed it a few days ago [1] and it looked good to him. Two tiny
> nits came up, which don't seem worth a reroll on their own.
>
> I think the series is good unless further issues come up.
>
> [1]: https://lore.kernel.org/git/CAOLa=ZS8J4t12ab1=3-LRYNuZOwqSHG861iYm97JjF3mGprvJA@mail.gmail.com/
I was silently hoping that you would fix these two nits, saying that
one of the alone might not warrant reroll but if we have multiple,
we would better get them right for the final version, or something
;-)
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jul 2026, #12)
@ 2026-07-29 15:52 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-07-29 15:52 UTC (permalink / raw)
To: Phillip Wood; +Cc: git
Phillip Wood <phillip.wood123@gmail.com> writes:
> On 27/07/2026 04:09, Junio C Hamano wrote:
>>
>> * hn/branch-delete-merged (2026-07-25) 7 commits
>> - branch: add --dry-run for --delete-merged
>> - branch: add branch.<name>.deleteMerged opt-out
>> - branch: add --delete-merged <branch>
>> - branch: prepare delete_branches for a bulk caller
>> - branch: let delete_branches skip unmerged branches on bulk refusal
>> - branch: convert delete_branches() to a flags argument
>> - branch: add --forked filter for --list mode
>>
>> The 'git branch' command has been taught the '--delete-merged' option
>> to remove local branches that are already merged into their tracked
>> remote-tracking branches.
>>
>> Will merge to 'next'?
>> cf. <xmqqy0ez14s9.fsf@gitster.g>
>> source: <pull.2285.v23.git.git.1784979136.gitgitgadget@gmail.com>
>
> I've just left some comments on this. It is almost there, but the way it
> checks if pushing a branch updates its upstream looks dodgy to me. The
> behavior wrt branches that are merged but are upstreams of other
> branches has changed so that the entire hierarchy is now preseved. I
> preferred it when we only kept the branch that was the upstream of the
> unmerged branch and deleted everything underneath but I'm happy enough
> if others prefer this new behavior.
I don't particularly favor the behavior in the latest round myself,
but I doubt I am the primary target audience, so I'll let the list
figure out how much we collectively care ;-).
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jul 2026, #12)
@ 2026-07-29 17:48 99% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2026-07-29 17:48 UTC (permalink / raw)
To: Phillip Wood; +Cc: git, Harald Nordgren
Phillip Wood <phillip.wood123@gmail.com> writes:
>> Perhaps I should re-evaluate the "What's Cooking" report and eject
>> other topics from 'next' as well. There are indeed topics I did not
>> personally read, relying instead on impressions from busy exchanges
>> (including earlier iterations read by others X-<).
>>
>> Are there other topics in 'next' that do not deserve to be there
>> yet?
>
> There aren't any others that I'm aware of, but I've not looked at most
> of them so that probably does not mean much.
>
>> I cannot, of course, afford to be the sole serious reviewer and
>> merge only those I have carefully read through, given that there are
>> only 24 hours in a day and I have other obligations. So either our
>> quality criteria must suffer, like this episode showed us, or more
>> topics must be ignored.
>
> Yes, we could really do with more reviewers
Perhaps the sensible thing for me to do is to stop taking any new
topics into 'seen', even if I've spotted them, until I see somebody
give them a real review.
Otherwise, it becomes too tempting for me to jump in, give them a
superficial read after seeing them linger in the "What's Cooking"
draft in the "Needs review" state for too long, and, believing I've
seen enough, mark them for 'next'. If I don't queue a patch that
nobody seems to have read carefully, I won't succumb to such
temptation.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jul 2026, #12)
@ 2026-07-31 15:36 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-07-31 15:36 UTC (permalink / raw)
To: Matt Hunter; +Cc: Phillip Wood, git, Harald Nordgren
"Matt Hunter" <m@lfurio.us> writes:
> Sorry for any hassle - though I don't expect you "blame" reviewers for
> this sort of thing. It's a lot harder to demonstrate correctness than
> point out some potential problem.
Yes, I agree that giving positive reviews is a lot harder to do.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jul 2026, #12)
@ 2026-08-03 16:02 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-08-03 16:02 UTC (permalink / raw)
To: Phillip Wood; +Cc: Matt Hunter, Harald Nordgren, phillip.wood, git
Phillip Wood <phillip.wood123@gmail.com> writes:
> If you raise a point and it is dismissed without a convincing
> explanation then its fine to raise it again asking for more details so
> that you can understand the reason behind the decision. That often leads
> to a productive discussion and an improved design.
True. But because "convincing" is not black and white, we need to
be careful a bit.
> That precedent is unfortunate, "--reedit-message" makes sense for the
> "fixup" subcommand because we are reediting an existing message but
> that's not the case with the "squash" subcommand where we're
> constructing a new message from several commits. Given how new the
> "fixup" subcommand is I'm tempted to add an "--edit" option and
> deprecate "--reedit-message".
As "git history" is marked experimental, we can afford to tweak the
UI for the better ;-).
> Having thought about it a bit over the weekend I wonder if the best
> solution when squashing is to default to looking at the commits being
> squashed before deciding whether to open the editor or not and allow the
> user to override that on the commandline like "git commit". If we're
> squashing a bunch of "fixup!" and/or "amend!" commits into a single
> target then I'm not sure its worth opening the editor...
Hmph, a base commit with an "amend!" (tells the machinery to use the
message from the "amend!" commit only, discarding the existing one)
is clear to me that there is no need for further editing, but if
there is any "fixup!" (code change, for which need for associating
log message change is unknown) or if there are multiple "amend!", I
am not so sure. It does make it confusing, I suspect.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Jul 2026, #12)
@ 2026-08-05 17:03 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-08-05 17:03 UTC (permalink / raw)
To: Phillip Wood; +Cc: git, Harald Nordgren
Phillip Wood <phillip.wood123@gmail.com> writes:
> Hi Junio
>
> On 29/07/2026 18:48, Junio C Hamano wrote:
>>
>> Perhaps the sensible thing for me to do is to stop taking any new
>> topics into 'seen', even if I've spotted them, until I see somebody
>> give them a real review.
>>
>> Otherwise, it becomes too tempting for me to jump in, give them a
>> superficial read after seeing them linger in the "What's Cooking"
>> draft in the "Needs review" state for too long, and, believing I've
>> seen enough, mark them for 'next'. If I don't queue a patch that
>> nobody seems to have read carefully, I won't succumb to such
>> temptation.
>
> Maybe, though I do find having the patches in seen makes it easier to do
> an in-depth review as it means I don't have to apply them myself.
Yes, that is a very good point. And if the authors are paying
attention, it would hopefully also help them how well their changes
play with others' changes.
OK, then I will keep picking them up, but under these conditions:
(1) They will not leave 'seen' without anyone commenting on them;
(2) They will automatically be discarded after four weeks without
positive feedback; and
(3) I will not feel obligated to review them even if no one steps up.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Aug 2026, #03)
@ 2026-08-08 5:50 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-08-08 5:50 UTC (permalink / raw)
To: git
Junio C Hamano <gitster@pobox.com> writes:
> Here are the topics that have been cooking in my tree. Commits
> ...
Sorry but this part is stale.
> The 11th batch of topics have now graduated to the 'master' branch.
> We have 401 non-merge commits in 'master' since Git 2.55. There
> are 55 non-merge commits cooking in 'next' (note that some have
> been reverted), and 235 non-merge commits, including those in and
> out of 'next', in 'seen' as of this writing.
We are now at 12th batch, with 409 non-merge commits in 'master', 48
non-merge commits in 'next' (went down as topics have graduated, but
there are reverted ones that will never graduate), and 261 commits
outside 'next' but in 'seen'.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Aug 2026, #05)
@ 2026-08-13 17:36 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-08-13 17:36 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
Patrick Steinhardt <ps@pks.im> writes:
>> * tb/send-pack-no-ref-delta (2026-07-12) 4 commits
>> - send-pack: honor `no-ref-delta` capability
>> - pack-objects: support reuse with `--no-ref-delta`
>> - pack-objects: introduce `--no-ref-delta`
>> - t/helper: teach pack-deltas to list delta entries
>>
>> 'git send-pack' has been taught to refrain from sending 'REF_DELTA'
>> encoded packfiles when the other side asks it to.
>>
>> Needs review.
>> source: <alQ7WKITYDXfiVn9@com-79390>
>
> In <an0EkMZGEbg6LERc@com-79390> we've agreed that this series can be
> evicted for now in favor of
> <20260807-b4-pks-odb-generate-pack-v1-0-7dec431ae7cd@pks.im>, as Taylor
> still needs some more time to rethink the approach in there.
>
>> * tb/midx-incremental-custom-base (2026-06-12) 3 commits
>> - midx-write: include packs above custom incremental base
>> - midx: pass custom '--base' through incremental writes
>> - t5334: expose shared `nth_line()` helper
>>
>> The 'git multi-pack-index write --incremental' command has been
>> corrected to properly honor the '--base' option. Previously, the
>> custom base was ignored by the normal write path; packs from layers
>> above the selected base were incorrectly skipped by the pack exclusion
>> logic, and reachability closure for bitmaps was broken.
>>
>> Needs review.
>> source: <cover.1781294771.git.me@ttaylorr.com>
>
> I'll try to have a look at this series later today.
Thanks.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Aug 2026, #10)
@ 2026-08-24 20:02 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-08-24 20:02 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
Patrick Steinhardt <ps@pks.im> writes:
> On Mon, Aug 24, 2026 at 06:01:10AM -0700, Junio C Hamano wrote:
>> * ps/odb-geometric-repack-loose-threshold (2026-08-11) 1 commit
>> * ps/odb-pluggable-pack-generation (2026-08-20) 6 commits
>> * jt/receive-pack-pluggable-writes (2026-08-20) 9 commits
>> * ps/odb-eagerly-load-alternates (2026-08-17) 6 commits
>> * vm/complete-history (2026-08-13) 4 commits
> ...
> I'm happy with this version.
Thanks for reconfirming these.
>> * dk/use-nsec-runtime (2026-08-20) 3 commits
>> - core: convert build-time USE_NSEC into runtime core.useNanosec
>> - environment: align repo_config_values_init with struct declaration
>> - meson: expose knob for xmlto relative links in manuals
>>
>> The build-time knob 'USE_NSEC' for nanosecond stat precision has been
>> converted to a runtime configuration 'core.useNanosec', allowing
>> distributions to bundle one binary that adapts to filesystem
>> capabilities dynamically.
>>
>> Needs review.
>> cf. <xmqqa4qgsn20.fsf@gitster.g>
>> cf. <aoaP7oIrR_Bpvx34@pks.im>
>> source: <cover.1787231825.git.ben.knoble@gmail.com>
>
> I haven't gotten around to it yet, but will try to review it tomorrow.
Thanks. FWIW, I am happy with this iteraiton (modulo a nit on a log
message).
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Aug 2026, #12)
@ 2026-08-31 19:31 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-08-31 19:31 UTC (permalink / raw)
To: Toon Claes; +Cc: git
Toon Claes <toon@iotcl.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> * tc/replay-linearize (2026-07-28) 3 commits
> ...
> Sorry it took me some longer because I was on leave. I've sent out v9
> just now.
>
>> * tc/last-modified-bloom (2026-08-07) 6 commits
> ...
> Rerolled v3.
Thanks for both. Queued and pushed out.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Aug 2026, #13)
@ 2026-09-01 17:48 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-09-01 17:48 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
Patrick Steinhardt <ps@pks.im> writes:
> On Mon, Aug 31, 2026 at 12:31:10PM -0700, Junio C Hamano wrote:
>> * ps/fetch-packfile-uris-parallel (2026-08-21) 2 commits
>> - fetch-pack: allow parallelizing packfile URI fetches
>> - fetch-pack: prepare for threaded fetching of packfile URIs
>>
>> The `git fetch` and `git clone` commands have been optimized to
>> download packfile URIs in parallel when the new
>> `fetch.packfileURIThreads` configuration is set, significantly
>> speeding up fetches from servers that advertise multiple packfiles.
>>
>> Expecting a reroll.
>> cf. <apUUiv4SD0-W8QS3@pks.im>
>> source: <20260821-pks-parallelize-fetching-packfile-uris-v1-0-0df52d9427ce@pks.im>
>
> Please evict this topic for now -- it's creating lots of conflicts with
> a series that Justin is about to send that converts git-fetch-pack(1) to
> use object transactions. I'll then resend my series once Justin's series
> got merged.
Will do.
^ permalink raw reply [relevance 99%]
* Re: What's cooking in git.git (Sep 2026, #01)
@ 2026-09-03 21:40 99% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2026-09-03 21:40 UTC (permalink / raw)
To: Yoichi Nakayama; +Cc: git
Yoichi Nakayama <yoichi.nakayama@gmail.com> writes:
> On Thu, Sep 3, 2026 at 10:25 AM Junio C Hamano <gitster@pobox.com> wrote:
>> * yn/worktree-ambiguous-remote-advice (2026-08-27) 4 commits
>> (merged to 'next' on 2026-08-30 at 8e7670286a)
>> + worktree add: treat multiple matches with --guess-remote as an error
>> + worktree add: improve message for ambiguous remote branch name
>> + checkout: improve message for ambiguous remote branch name
>> + checkout: extract function to display advice for ambiguous remotes
>
> The following description does not apply to this patch series; it appears
> to be confused with the `yn/worktree-add-no-dwim-with-b` series, which
> has already been merged to master.
Indeed. Thanks.
^ permalink raw reply [relevance 99%]
Results 1-200 of ~2000 next [<= 99%] | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2024-12-03 6:48 What's cooking in git.git (Dec 2024, #01; Tue, 3) Junio C Hamano
2024-12-03 10:17 ` Patrick Steinhardt
2024-12-03 23:09 99% ` Junio C Hamano
2025-03-01 0:45 What's cooking in git.git (Feb 2025, #09; Fri, 28) Junio C Hamano
2025-03-04 6:31 ` Patrick Steinhardt
2025-03-04 7:02 ` ps/reftable-sans-compat-util, was " Johannes Schindelin
2025-03-04 7:40 ` Johannes Schindelin
2025-03-04 9:46 ` Patrick Steinhardt
2025-03-04 10:06 ` Patrick Steinhardt
2025-03-26 16:57 ` Johannes Schindelin
2025-03-27 15:28 99% ` Junio C Hamano
2025-03-28 5:36 ` Patrick Steinhardt
2025-03-29 23:56 99% ` Junio C Hamano
2025-03-28 15:31 ` Johannes Schindelin
2025-03-30 0:56 99% ` Junio C Hamano
2025-03-03 15:24 ` shejialuo
2025-03-03 17:03 99% ` Junio C Hamano
2025-03-04 6:27 ` Patrick Steinhardt
2025-03-04 15:30 99% ` Junio C Hamano
2025-01-18 0:42 What's cooking in git.git (Jan 2025, #05; Fri, 17) Junio C Hamano
2025-01-22 16:44 ` Karthik Nayak
2025-01-22 17:28 ` Karthik Nayak
2025-01-22 17:38 99% ` Junio C Hamano
2025-01-23 17:22 ` Junio C Hamano
2025-01-23 17:45 ` Patrick Steinhardt
2025-01-23 18:25 99% ` Junio C Hamano
2025-01-24 11:05 ` Karthik Nayak
2025-01-24 17:06 99% ` Junio C Hamano
2025-01-20 6:53 ` David Aguilar
2025-01-21 19:23 99% ` Junio C Hamano
2025-01-21 20:19 ` Derrick Stolee
2025-01-21 20:30 99% ` Junio C Hamano
2025-01-18 13:15 ` Jeff King
2025-01-18 17:17 99% ` Junio C Hamano
2025-01-19 12:51 ` Jeff King
2025-01-19 12:55 ` Jeff King
2025-01-21 19:17 99% ` Junio C Hamano
2026-04-01 23:42 What's cooking in git.git (Apr 2026, #01) Junio C Hamano
2026-04-09 19:54 ` René Scharfe
2026-04-09 20:09 99% ` Junio C Hamano
2025-04-07 16:49 What's cooking in git.git (Apr 2025, #01; Mon, 7) Junio C Hamano
2025-04-09 11:24 ` Philippe Blain
2025-04-09 16:01 99% ` Junio C Hamano
2025-06-05 12:51 99% ` Junio C Hamano
2025-06-05 15:10 ` Philippe Blain
2025-06-05 18:29 99% ` Junio C Hamano
2025-04-08 6:22 ` Patrick Steinhardt
2025-04-08 14:50 99% ` Junio C Hamano
2025-12-09 21:08 What's cooking in git.git (Dec 2025, #02) Junio C Hamano
2025-12-10 7:55 ` Kristoffer Haugsbakk
2025-12-10 9:20 99% ` Junio C Hamano
2025-12-09 22:46 ` Karthik Nayak
2025-12-09 23:10 99% ` Junio C Hamano
2025-12-10 10:04 ` Karthik Nayak
2025-12-10 12:00 99% ` Junio C Hamano
2026-08-08 1:55 What's cooking in git.git (Aug 2026, #03) Junio C Hamano
2026-08-08 5:50 99% ` Junio C Hamano
2026-02-28 1:02 What's cooking in git.git (Feb 2026, #11) Junio C Hamano
2026-03-02 8:50 ` Patrick Steinhardt
2026-03-02 19:07 99% ` Junio C Hamano
2026-03-02 19:20 ` Adrian Ratiu
2026-03-02 21:41 99% ` Junio C Hamano
2025-09-10 21:03 What's cooking in git.git (Sep 2025, #04; Wed, 10) Junio C Hamano
2025-09-10 21:12 ` Kristoffer Haugsbakk
2025-09-10 21:45 99% ` Junio C Hamano
2025-09-22 23:01 What's cooking in git.git (Sep 2025, #09; Mon, 22) Junio C Hamano
2025-09-24 6:44 ` SZEDER Gábor
2025-09-24 19:01 99% ` Junio C Hamano
2025-09-23 3:19 ` Jeff King
2025-09-23 14:14 99% ` Junio C Hamano
2025-09-23 7:42 ` Patrick Steinhardt
2025-09-23 14:34 99% ` Junio C Hamano
2026-07-01 23:40 What's cooking in git.git (Jul 2026, #01) Junio C Hamano
2026-07-02 10:38 ` Patrick Steinhardt
2026-07-03 20:39 99% ` Junio C Hamano
2025-02-19 1:31 What's cooking in git.git (Feb 2025, #06; Tue, 18) Junio C Hamano
2025-02-20 11:18 ` Patrick Steinhardt
2025-02-20 15:56 99% ` Junio C Hamano
2025-11-24 4:59 What's cooking in git.git (Nov 2025, #07; Sun, 23) Junio C Hamano
2025-11-25 11:40 ` Toon Claes
2025-11-25 17:19 99% ` Junio C Hamano
2025-11-24 15:46 ` D. Ben Knoble
2025-11-24 18:26 99% ` Junio C Hamano
2025-01-22 22:48 What's cooking in git.git (Jan 2025, #06; Wed, 22) Junio C Hamano
2025-01-23 0:36 ` Jeff King
2025-01-23 1:52 99% ` Junio C Hamano
2025-01-31 23:34 ` Jeff King
2025-01-31 23:49 ` Junio C Hamano
2025-02-01 2:29 ` Jeff King
2025-02-02 23:39 99% ` Junio C Hamano
2025-01-24 6:07 ` Patrick Steinhardt
2025-01-24 16:02 99% ` Junio C Hamano
2025-01-24 12:55 ` Toon Claes
2025-01-24 17:05 99% ` Junio C Hamano
2025-01-23 0:38 ` Eric Sunshine
2025-01-23 1:53 99% ` Junio C Hamano
2026-08-24 13:01 What's cooking in git.git (Aug 2026, #10) Junio C Hamano
2026-08-24 17:43 ` Patrick Steinhardt
2026-08-24 20:02 99% ` Junio C Hamano
2025-03-26 12:46 What's cooking in git.git (Mar 2025, #07; Wed, 26) Junio C Hamano
2025-03-29 0:34 ` D. Ben Knoble
2025-04-08 22:39 ` D. Ben Knoble
2025-04-08 22:49 99% ` Junio C Hamano
2026-06-09 0:56 What's cooking in git.git (Jun 2026, #03) Junio C Hamano
2026-06-11 15:26 ` Phillip Wood
2026-06-11 16:10 99% ` Junio C Hamano
2026-01-20 12:10 What's cooking in git.git (Jan 2026, #06) Junio C Hamano
2026-01-20 15:01 ` Shreyansh Paliwal
2026-01-20 16:30 99% ` Junio C Hamano
2026-01-21 10:08 ` Johannes Schindelin
2026-01-21 15:26 99% ` Junio C Hamano
2026-01-21 16:20 99% ` Junio C Hamano
2024-12-09 20:39 What's cooking in git.git (Dec 2024, #03; Sun, 8) Jonathan Tan
2024-12-09 23:53 99% ` Junio C Hamano
2025-02-25 2:47 What's cooking in git.git (Feb 2025, #07; Mon, 24) Junio C Hamano
2025-02-25 6:48 ` Patrick Steinhardt
2025-02-25 17:06 99% ` Junio C Hamano
2026-01-29 23:52 What's cooking in git.git (Jan 2026, #10) Junio C Hamano
2026-01-30 0:33 ` Eric Sunshine
2026-01-30 5:43 99% ` Junio C Hamano
2026-01-30 14:24 ` Pushkar Singh
2026-01-30 16:50 99% ` Junio C Hamano
2025-05-06 1:20 What's cooking in git.git (May 2025, #02; Mon, 5) Junio C Hamano
2025-05-06 8:34 ` Christian Couder
2025-05-06 17:50 ` Eric Sunshine
2025-05-07 8:00 ` Patrick Steinhardt
2025-05-08 18:22 99% ` Junio C Hamano
2025-12-01 5:05 What's cooking in git.git (Nov 2025, #10; Sun, 30) Junio C Hamano
2025-12-01 10:53 ` Karthik Nayak
2025-12-07 0:43 99% ` Junio C Hamano
2025-07-10 8:03 What's cooking in git.git (Jul 2025, #03; Wed, 9) Junio C Hamano
2025-07-10 19:32 ` [-SPAM-] " Ramsay Jones
2025-07-10 21:12 ` Junio C Hamano
2025-07-10 21:44 ` Ramsay Jones
2025-07-11 8:49 ` Patrick Steinhardt
2025-07-11 15:00 99% ` Junio C Hamano
2025-07-11 2:05 ` Ayush Chandekar
2025-07-11 16:01 99% ` Junio C Hamano
2025-07-11 18:15 ` Ayush Chandekar
2025-07-11 18:34 99% ` Junio C Hamano
2025-10-06 23:41 What's cooking in git.git (Oct 2025, #02; Mon, 6) Junio C Hamano
2025-10-08 4:10 ` Elijah Newren
2025-10-08 16:41 99% ` Junio C Hamano
2025-10-07 8:22 ` Jeff King
2025-10-07 14:24 99% ` Junio C Hamano
2025-10-23 23:36 What's cooking in git.git (Oct 2025, #08; Thu, 23) Junio C Hamano
2025-10-24 15:47 ` Jeff King
2025-10-24 16:06 99% ` Junio C Hamano
2026-01-08 11:56 What's cooking in git.git (Jan 2026, #03) Junio C Hamano
2026-01-08 13:08 ` Kristoffer Haugsbakk
2026-01-09 14:01 99% ` Junio C Hamano
2025-08-20 23:44 What's cooking in git.git (Aug 2025, #09; Wed, 20) Junio C Hamano
2025-08-21 7:05 ` Patrick Steinhardt
2025-08-28 23:14 99% ` Junio C Hamano
2025-06-24 0:57 What's cooking in git.git (Jun 2025, #08; Mon, 23) Junio C Hamano
2025-06-25 8:40 ` Phillip Wood
2025-06-25 16:29 99% ` Junio C Hamano
2025-06-24 23:29 ` Karthik Nayak
2025-06-25 15:03 99% ` Junio C Hamano
2025-05-08 1:26 What's cooking in git.git (May 2025, #03; Wed, 7) Junio C Hamano
2025-05-08 6:27 ` Johannes Sixt
2025-05-08 13:28 99% ` Junio C Hamano
2025-02-01 2:51 What's cooking in git.git (Jan 2025, #09; Fri, 31) Junio C Hamano
2025-02-03 17:10 ` Derrick Stolee
2025-02-03 21:38 99% ` Junio C Hamano
2025-02-04 10:07 ` Karthik Nayak
2025-02-04 17:48 99% ` Junio C Hamano
2025-10-20 21:02 What's cooking in git.git (Oct 2025, #06; Fri, 17) Junio C Hamano
2025-10-21 5:25 ` Patrick Steinhardt
2025-10-21 21:48 99% ` Junio C Hamano
2025-05-28 0:54 What's cooking in git.git (May 2025, #08; Tue, 27) Junio C Hamano
2025-05-28 21:01 ` Jean-Noël AVILA
2025-05-28 22:02 99% ` Junio C Hamano
2025-09-29 22:19 What's cooking in git.git (Sep 2025, #11; Mon, 29) Junio C Hamano
2025-09-29 23:06 ` brian m. carlson
2025-09-30 14:43 99% ` Junio C Hamano
2025-07-29 1:57 What's cooking in git.git (Jul 2025, #08; Mon, 28) Junio C Hamano
2025-07-29 2:05 99% ` Junio C Hamano
2025-07-29 7:37 ` Toon Claes
2025-07-29 15:30 99% ` Junio C Hamano
2026-01-21 19:00 What's cooking in git.git (Jan 2026, #07) Junio C Hamano
2026-01-21 21:03 ` Lucas Seiki Oshiro
2026-01-21 21:08 99% ` Junio C Hamano
2024-11-22 10:11 What's cooking in git.git (Nov 2024, #08; Fri, 22) Junio C Hamano
2024-11-22 19:10 ` Philippe Blain
2024-11-25 0:23 99% ` Junio C Hamano
2025-08-04 8:23 What's cooking in git.git (Aug 2025, #01; Sun, 3) Junio C Hamano
2025-08-04 9:47 ` Patrick Steinhardt
2025-08-04 14:29 99% ` Junio C Hamano
2025-08-04 14:51 ` Patrick Steinhardt
2025-08-04 15:41 ` Jeff King
2025-08-05 0:34 99% ` Junio C Hamano
2025-08-05 13:05 ` Patrick Steinhardt
2025-08-05 17:10 99% ` Junio C Hamano
2025-08-05 12:51 ` Jeff King
2025-08-05 17:08 99% ` Junio C Hamano
2025-08-05 1:22 ` D. Ben Knoble
2025-08-05 10:24 99% ` Junio C Hamano
2025-08-05 16:23 ` D. Ben Knoble
2025-08-05 16:30 ` D. Ben Knoble
2025-08-05 19:06 99% ` Junio C Hamano
2025-08-06 17:28 ` Lucas Seiki Oshiro
2025-08-06 18:34 99% ` Junio C Hamano
2025-08-09 3:28 What's cooking in git.git (Aug 2025, #03; Fri, 8) Junio C Hamano
2025-08-11 5:50 ` Eric Sunshine
2025-08-11 15:41 99% ` Junio C Hamano
2024-11-28 5:35 What's cooking in git.git (Nov 2024, #10; Thu, 28) Junio C Hamano
2024-11-28 15:34 ` Phillip Wood
2024-12-02 0:39 99% ` Junio C Hamano
2024-11-28 16:11 ` Patrick Steinhardt
2024-12-02 0:48 99% ` Junio C Hamano
2025-08-04 17:24 What's cooking in git.git (Aug 2025, #02; Mon, 4) Junio C Hamano
2025-08-05 13:55 ` Toon Claes
2025-08-05 18:03 99% ` Junio C Hamano
2025-08-06 20:47 ` SZEDER Gábor
2025-08-06 21:18 99% ` Junio C Hamano
2025-08-07 4:43 ` Patrick Steinhardt
2025-08-07 15:22 99% ` Junio C Hamano
2026-07-21 2:19 What's cooking in git.git (Jul 2026, #09) Junio C Hamano
2026-07-22 9:02 ` Christian Couder
2026-07-22 18:27 99% ` Junio C Hamano
2025-07-14 20:53 What's cooking in git.git (Jul 2025, #04; Mon, 14) Junio C Hamano
2025-07-15 11:29 ` Karthik Nayak
2025-07-15 17:39 99% ` Junio C Hamano
2025-07-15 13:16 ` Carlo Marcelo Arenas Belón
2025-07-15 17:43 99% ` Junio C Hamano
2026-03-07 2:22 What's cooking in git.git (Mar 2026, #03) Junio C Hamano
2026-03-07 6:33 ` Eric Sunshine
2026-03-07 6:47 99% ` Junio C Hamano
2025-02-05 2:08 What's cooking in git.git (Feb 2025, #01; Tue, 4) Junio C Hamano
2025-02-05 7:03 ` Patrick Steinhardt
2025-02-05 20:37 99% ` Junio C Hamano
2025-02-06 0:04 99% ` Junio C Hamano
2025-02-07 10:11 ` Toon Claes
2025-02-07 17:11 99% ` Junio C Hamano
2025-10-11 0:00 What's cooking in git.git (Oct 2025, #04; Fri, 10) Junio C Hamano
2025-10-11 5:23 ` Eric Sunshine
2025-10-13 15:28 99% ` Junio C Hamano
2025-10-11 11:00 ` Patrick Steinhardt
2025-10-13 14:07 99% ` Junio C Hamano
2025-10-11 14:35 ` D. Ben Knoble
2025-10-11 17:14 99% ` Junio C Hamano
2025-11-07 18:56 What's cooking in git.git (Nov 2025, #03; Fri, 7) Junio C Hamano
2025-11-12 12:56 ` Toon Claes
2025-11-12 16:13 99% ` Junio C Hamano
2025-08-12 8:29 What's cooking in git.git (Aug 2025, #05; Mon, 11) Junio C Hamano
2025-08-12 15:24 ` Jean-Noël AVILA
2025-08-12 16:02 99% ` Junio C Hamano
2025-08-12 12:52 ` Patrick Steinhardt
2025-08-12 14:46 99% ` Junio C Hamano
2025-08-12 14:41 ` Taylor Blau
2025-08-13 7:06 ` Patrick Steinhardt
2025-08-13 13:25 ` Taylor Blau
2025-08-13 14:55 99% ` Junio C Hamano
2026-03-03 3:15 What's cooking in git.git (Mar 2026, #01) Junio C Hamano
2026-03-03 18:10 ` Derrick Stolee
2026-03-03 18:43 99% ` Junio C Hamano
2025-01-24 20:19 What's cooking in git.git (Jan 2025, #07; Fri, 24) Junio C Hamano
2025-01-29 13:40 ` Derrick Stolee
2025-01-29 15:03 99% ` Junio C Hamano
2025-01-28 16:46 ` Jeff King
2025-01-28 17:59 99% ` Junio C Hamano
2025-01-28 18:26 ` Junio C Hamano
2025-01-30 2:29 ` brian m. carlson
2025-01-30 17:26 99% ` Junio C Hamano
2025-11-14 22:26 What's cooking in git.git (Nov 2025, #04; Fri, 14) Junio C Hamano
2025-11-15 16:51 ` D. Ben Knoble
2025-11-17 16:31 ` Phillip Wood
2025-11-17 22:48 99% ` Junio C Hamano
2025-12-12 10:26 What's cooking in git.git (Dec 2025, #03) Junio C Hamano
2025-12-13 7:42 ` Adrian Ratiu
2025-12-16 1:59 ` Junio C Hamano
2025-12-16 8:13 ` Patrick Steinhardt
2025-12-16 10:41 ` Adrian Ratiu
2025-12-16 17:49 ` Emily Shaffer
2025-12-17 5:04 99% ` Junio C Hamano
2025-12-17 0:09 ` Aaron Plattner
2025-12-17 5:02 ` Junio C Hamano
2025-12-17 5:20 ` Aaron Plattner
2025-12-17 13:46 99% ` Junio C Hamano
2025-01-29 0:18 What's cooking in git.git (Jan 2025, #08; Tue, 28) Junio C Hamano
2025-01-31 17:51 99% ` Junio C Hamano
2025-01-29 7:57 ` Patrick Steinhardt
2025-01-29 14:03 99% ` Junio C Hamano
2025-01-29 21:34 99% ` Junio C Hamano
2025-01-31 23:30 ` Jeff King
2025-02-03 6:08 ` Patrick Steinhardt
2025-02-03 21:32 99% ` Junio C Hamano
2024-12-23 19:27 What's cooking in git.git (Dec 2024, #08; Mon, 23) Junio C Hamano
2024-12-24 11:55 ` Johannes Sixt
2024-12-26 16:05 99% ` Junio C Hamano
2025-01-14 18:25 What's cooking in git.git (Jan 2025, #04; Tue, 14) Junio C Hamano
2025-01-16 10:24 ` Patrick Steinhardt
2025-01-16 16:48 99% ` Junio C Hamano
2026-02-07 23:15 What's cooking in git.git (Feb 2026, #03) Junio C Hamano
2026-02-09 9:14 ` Patrick Steinhardt
2026-02-09 16:37 99% ` Junio C Hamano
2025-04-15 23:41 What's cooking in git.git (Apr 2025, #04; Tue, 15) Junio C Hamano
2025-04-18 21:35 ` aw/t9811-modernize, was " Jeff King
2025-04-18 21:38 99% ` Junio C Hamano
2025-04-18 21:44 99% ` Junio C Hamano
2025-04-18 21:57 ` Jeff King
2025-04-22 5:47 ` Patrick Steinhardt
2025-04-22 14:50 99% ` Junio C Hamano
2026-07-07 17:18 What's cooking in git.git (Jul 2026, #03) Junio C Hamano
2026-07-08 11:45 ` Kristofer Karlsson
2026-07-08 16:14 99% ` Junio C Hamano
2025-01-06 20:02 What's cooking in git.git (Jan 2025, #02; Mon, 6) Junio C Hamano
2025-01-07 21:15 ` Toon Claes
2025-01-07 23:12 99% ` Junio C Hamano
2024-11-22 14:31 What's cooking in git.git (Nov 2024, #08; Fri, 22) Caleb White
2024-11-25 0:25 99% ` Junio C Hamano
2026-09-03 1:25 What's cooking in git.git (Sep 2026, #01) Junio C Hamano
2026-09-03 20:51 ` Yoichi Nakayama
2026-09-03 21:40 99% ` Junio C Hamano
2024-11-28 21:40 What's cooking in git.git (Nov 2024, #10; Thu, 28) Caleb White
2024-12-02 2:48 99% ` Junio C Hamano
2026-02-06 1:15 What's cooking in git.git (Feb 2026, #02) Junio C Hamano
2026-02-06 16:30 ` Patrick Steinhardt
2026-02-06 19:37 99% ` Junio C Hamano
2025-10-30 21:36 What's cooking in git.git (Oct 2025, #12; Thu, 30) Junio C Hamano
2025-10-31 6:42 ` Patrick Steinhardt
2025-11-03 17:57 99% ` Junio C Hamano
2025-11-03 18:43 99% ` Junio C Hamano
2025-10-31 15:51 99% ` Junio C Hamano
2025-09-02 16:57 What's cooking in git.git (Sep 2025, #01; Tue, 2) Junio C Hamano
2025-09-02 17:35 ` rsbecker
2025-09-02 17:50 99% ` Junio C Hamano
2026-05-12 9:23 What's cooking in git.git (May 2026, #03) Junio C Hamano
2026-05-12 14:20 ` Pushkar Singh
2026-05-13 16:06 99% ` Junio C Hamano
2026-05-14 17:41 ` Pushkar Singh
2026-05-15 1:46 99% ` Junio C Hamano
2026-05-15 11:49 ` Karthik Nayak
2026-05-15 17:06 99% ` Junio C Hamano
2026-08-13 4:45 What's cooking in git.git (Aug 2026, #05) Junio C Hamano
2026-08-13 7:59 ` Patrick Steinhardt
2026-08-13 17:36 99% ` Junio C Hamano
2025-05-21 0:54 What's cooking in git.git (May 2025, #06; Tue, 20) Junio C Hamano
2025-05-21 10:10 ` Karthik Nayak
2025-05-21 14:55 99% ` Junio C Hamano
2025-11-26 0:39 What's cooking in git.git (Nov 2025, #08; Tue, 25) Junio C Hamano
2025-11-26 9:15 ` Christian Couder
2025-11-26 14:36 99% ` Junio C Hamano
2025-11-26 17:04 99% ` Junio C Hamano
2026-05-18 1:32 What's cooking in git.git (May 2026, #04) Junio C Hamano
2026-05-19 22:11 ` Justin Tobler
2026-05-20 2:37 99% ` Junio C Hamano
2026-05-19 16:26 ` Taylor Blau
2026-05-19 19:19 ` Jeff King
2026-05-20 2:35 99% ` Junio C Hamano
2024-12-28 22:23 What's cooking in git.git (Dec 2024, #10; Sat, 28) Junio C Hamano
2024-12-30 7:27 ` Patrick Steinhardt
2024-12-30 14:07 99% ` Junio C Hamano
2026-03-26 23:16 What's cooking in git.git (Mar 2026, #11) Junio C Hamano
2026-03-27 8:07 ` Christian Couder
2026-03-27 16:13 99% ` Junio C Hamano
2026-03-27 7:35 ` Patrick Steinhardt
2026-03-27 16:08 99% ` Junio C Hamano
2025-08-23 0:10 What's cooking in git.git (Aug 2025, #10; Fri, 22) Junio C Hamano
2025-08-26 15:04 ` Elijah Newren
2025-08-26 16:06 99% ` Junio C Hamano
2024-12-30 17:33 What's cooking in git.git (Dec 2024, #11; Mon, 30) Junio C Hamano
2025-01-01 19:14 ` a less-invasive racy-leak fix, was " Jeff King
2025-01-02 0:25 99% ` Junio C Hamano
2025-01-02 2:32 ` Jeff King
2025-01-02 14:42 99% ` Junio C Hamano
2025-01-02 19:06 ` Jeff King
2025-01-02 19:33 99% ` Junio C Hamano
2026-03-22 6:46 What's cooking in git.git (Mar 2026, #08) Junio C Hamano
2026-03-22 14:14 ` Shreyansh Paliwal
2026-03-22 17:53 99% ` Junio C Hamano
2026-03-22 16:30 ` René Scharfe
2026-03-22 17:50 99% ` Junio C Hamano
2026-08-31 19:31 What's cooking in git.git (Aug 2026, #13) Junio C Hamano
2026-09-01 11:26 ` Patrick Steinhardt
2026-09-01 17:48 99% ` Junio C Hamano
2024-11-20 8:49 What's cooking in git.git (Nov 2024, #07; Wed, 20) Junio C Hamano
2024-11-20 10:36 ` Patrick Steinhardt
2024-11-21 1:10 99% ` Junio C Hamano
2024-11-21 8:26 ` Kristoffer Haugsbakk
2024-11-21 12:59 99% ` Junio C Hamano
2024-11-20 16:40 ` Taylor Blau
2024-11-21 0:44 99% ` Junio C Hamano
2024-11-22 4:34 99% ` Junio C Hamano
2025-07-24 17:18 What's cooking in git.git (Jul 2025, #07; Thu, 24) Junio C Hamano
2025-07-26 2:03 ` Usman Akinyemi
2025-07-26 17:45 99% ` Junio C Hamano
2025-07-26 13:00 ` D. Ben Knoble
2025-07-27 0:00 99% ` Junio C Hamano
2026-06-11 16:08 What's cooking in git.git (Jun 2026, #04) Junio C Hamano
2026-06-11 16:40 ` Mirko Faina
2026-06-11 18:55 99% ` Junio C Hamano
2026-01-13 20:10 What's cooking in git.git (Jan " Junio C Hamano
2026-01-14 0:27 99% ` Junio C Hamano
2026-01-14 5:20 ` Patrick Steinhardt
2026-01-14 14:26 99% ` Junio C Hamano
2026-01-15 18:44 What's cooking in git.git (Jan 2026, #05) Junio C Hamano
2026-01-16 7:00 ` Elijah Newren
2026-01-16 15:23 99% ` Junio C Hamano
2026-06-26 0:30 What's cooking in git.git (Jun 2026, #10) Junio C Hamano
2026-06-30 8:20 ` Toon Claes
2026-06-30 19:27 99% ` Junio C Hamano
2025-09-04 5:07 What's cooking in git.git (Sep 2025, #02; Wed, 3) Junio C Hamano
2025-09-04 6:55 ` Kristoffer Haugsbakk
2025-09-04 16:21 99% ` Junio C Hamano
2025-09-04 13:24 ` Lucas Seiki Oshiro
2025-09-04 16:21 99% ` Junio C Hamano
2025-09-04 14:26 ` Patrick Steinhardt
2025-09-04 16:23 99% ` Junio C Hamano
2026-03-13 0:10 What's cooking in git.git (Mar 2026, #05) Junio C Hamano
2026-03-13 0:24 ` Jeff King
2026-03-13 4:24 99% ` Junio C Hamano
2026-03-16 22:07 ` Taylor Blau
2026-03-18 3:03 ` Jeff King
2026-03-18 16:36 99% ` Junio C Hamano
2026-02-14 2:01 What's cooking in git.git (Feb " Junio C Hamano
2026-02-14 21:17 ` ds/revision-maximal-only (was Re: What's cooking in git.git (Feb 2026, #05)) Derrick Stolee
2026-02-17 16:33 99% ` Junio C Hamano
2024-11-25 8:07 What's cooking in git.git (Nov 2024, #09; Mon, 25) Junio C Hamano
2024-11-27 8:30 ` Patrick Steinhardt
2024-11-28 1:57 99% ` Junio C Hamano
2025-09-09 1:37 What's cooking in git.git (Sep 2025, #03; Mon, 8) Junio C Hamano
2025-09-09 6:58 ` Elijah Newren
2025-09-09 19:35 ` Derrick Stolee
2025-09-09 21:20 99% ` Junio C Hamano
2025-09-10 7:42 ` Kristoffer Haugsbakk
2025-09-10 21:37 99% ` Junio C Hamano
2025-09-10 15:54 ` Jeff King
2025-09-10 21:42 99% ` Junio C Hamano
2025-09-10 15:32 ` Phillip Wood
2025-09-10 21:38 99% ` Junio C Hamano
2026-07-23 2:38 What's cooking in git.git (Jul 2026, #10) Junio C Hamano
2026-07-23 21:55 ` Pablo Sabater
2026-07-24 0:33 99% ` Junio C Hamano
2025-04-11 22:58 What's cooking in git.git (Apr 2025, #03; Fri, 11) Junio C Hamano
2025-04-14 11:03 ` ds/path-walk-2 (was Re: What's cooking in git.git (Apr 2025, #03; Fri, 11)) Derrick Stolee
2025-04-14 12:34 99% ` Junio C Hamano
2025-04-14 8:13 ` What's cooking in git.git (Apr 2025, #03; Fri, 11) Patrick Steinhardt
2025-04-14 13:34 99% ` Junio C Hamano
2025-04-12 18:03 ` Philippe Blain
2025-04-14 13:04 99% ` Junio C Hamano
2026-02-10 22:21 What's cooking in git.git (Feb 2026, #04) Junio C Hamano
2026-02-11 20:46 99% ` Junio C Hamano
2026-02-12 15:56 ` Phillip Wood
2026-02-12 16:38 99% ` Junio C Hamano
2026-01-23 10:01 What's cooking in git.git (Jan 2026, #08) Junio C Hamano
2026-01-23 14:35 ` Toon Claes
2026-01-23 17:22 99% ` Junio C Hamano
2026-02-23 15:13 What's cooking in git.git (Feb " Junio C Hamano
2026-02-23 15:37 ` Kristoffer Haugsbakk
2026-02-23 21:45 99% ` Junio C Hamano
2026-03-31 0:10 What's cooking in git.git (Mar 2026, #12) Junio C Hamano
2026-03-31 5:22 ` Patrick Steinhardt
2026-03-31 15:27 99% ` Junio C Hamano
2026-03-31 0:20 ` Mirko Faina
2026-03-31 15:15 99% ` Junio C Hamano
2026-03-25 4:20 What's cooking in git.git (Mar 2026, #10) Junio C Hamano
2026-03-25 8:33 ` Shreyansh Paliwal
2026-03-25 19:50 99% ` Junio C Hamano
2026-06-20 1:33 What's cooking in git.git (Jun 2026, #07) Junio C Hamano
2026-06-22 7:52 ` Patrick Steinhardt
2026-06-22 12:50 99% ` Junio C Hamano
2026-07-27 3:09 What's cooking in git.git (Jul 2026, #12) Junio C Hamano
2026-07-29 15:14 ` Phillip Wood
2026-07-29 15:52 99% ` Junio C Hamano
2026-07-29 13:24 ` Phillip Wood
2026-07-30 6:11 ` Harald Nordgren
2026-07-31 7:02 ` Matt Hunter
2026-08-03 9:05 ` Phillip Wood
2026-08-03 16:02 99% ` Junio C Hamano
2026-07-29 14:18 ` Junio C Hamano
2026-07-29 15:20 ` Phillip Wood
2026-07-29 17:48 99% ` Junio C Hamano
2026-08-05 13:10 ` Phillip Wood
2026-08-05 17:03 99% ` Junio C Hamano
2026-07-31 6:20 ` Matt Hunter
2026-07-31 15:36 99% ` Junio C Hamano
2025-09-15 19:19 What's cooking in git.git (Sep 2025, #06; Mon, 15) Junio C Hamano
2025-09-16 6:53 ` Patrick Steinhardt
2025-09-16 16:16 ` Junio C Hamano
2025-09-16 16:49 ` Jeff King
2025-09-16 17:19 99% ` Junio C Hamano
2024-12-12 12:31 What's cooking in git.git (Dec 2024, #05; Thu, 12) Junio C Hamano
2024-12-13 14:40 ` Christian Couder
2024-12-13 14:48 99% ` Junio C Hamano
2024-12-12 14:27 ` karthik nayak
2024-12-13 14:33 99% ` Junio C Hamano
2024-12-16 8:11 ` Patrick Steinhardt
2024-12-16 16:26 99% ` Junio C Hamano
2026-05-20 5:19 What's cooking in git.git (May 2026, #05) Junio C Hamano
2026-05-20 5:44 ` Jeff King
2026-05-20 6:38 99% ` Junio C Hamano
2025-03-12 23:26 What's cooking in git.git (Mar 2025, #03; Wed, 12) Junio C Hamano
2025-03-18 10:13 ` Karthik Nayak
2025-03-18 17:17 99% ` Junio C Hamano
2025-10-28 22:55 What's cooking in git.git (Oct 2025, #11; Tue, 28) Junio C Hamano
2025-10-30 15:49 ` Toon Claes
2025-10-31 21:33 99% ` Junio C Hamano
2025-03-07 0:55 What's cooking in git.git (Mar 2025, #02; Thu, 6) Junio C Hamano
2025-03-11 14:46 ` shejialuo
2025-03-11 17:05 99% ` Junio C Hamano
2025-07-23 0:11 What's cooking in git.git (Jul 2025, #06; Tue, 22) Junio C Hamano
2025-07-23 5:35 ` Patrick Steinhardt
2025-07-23 15:48 99% ` Junio C Hamano
2025-07-23 9:40 ` Phillip Wood
2025-07-23 17:17 99% ` Junio C Hamano
2025-07-23 7:40 ` Eric Sunshine
2025-07-23 16:46 99% ` Junio C Hamano
2025-07-08 0:11 What's cooking in git.git (Jul 2025, #02; Mon, 7) Junio C Hamano
2025-07-09 10:41 ` Carlo Marcelo Arenas Belón
2025-07-09 16:26 99% ` Junio C Hamano
2025-07-09 15:04 ` Johannes Sixt
2025-07-10 4:25 ` Carlo Marcelo Arenas Belón
2025-07-10 7:18 ` Johannes Sixt
2025-07-10 15:30 99% ` Junio C Hamano
2025-07-09 14:46 ` Taylor Blau
2025-07-10 0:01 99% ` Junio C Hamano
2025-07-10 1:05 ` Elijah Newren
2025-07-10 4:24 99% ` Junio C Hamano
2025-07-09 9:25 ` René Scharfe
2025-07-09 15:37 99% ` Junio C Hamano
2025-07-09 23:14 ` brian m. carlson
2025-07-10 4:24 99% ` Junio C Hamano
2026-08-28 23:41 What's cooking in git.git (Aug 2026, #12) Junio C Hamano
2026-08-31 15:23 ` Toon Claes
2026-08-31 19:31 99% ` Junio C Hamano
2026-01-27 17:42 What's cooking in git.git (Jan 2026, #09) Junio C Hamano
2026-01-27 22:03 ` Taylor Blau
2026-02-06 19:39 99% ` Junio C Hamano
Code repositories for project(s) associated with this public inbox
https://public-inbox.org/mirrors/git.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).