What's cooking in git.git (Feb 2025, #09; Fri, 28)

What's cooking in git.git (Feb 2025, #09; Fri, 28)

[Junio C Hamano]

Here are the topics that have been cooking in my tree.  Commits
prefixed with '+' are in 'next' (being in 'next' is a sign that a
topic is stable enough to be used and are candidate to be in a
future release).  Commits prefixed with '-' are only in 'seen', and
aren't considered "accepted" at all and may be annotated with an URL
to a message that raises issues but they are no means exhaustive.  A
topic without enough support may be discarded after a long period of
no activity (of course they can be resubmit when new interests
arise).

Copies of the source code to Git live in many repositories, and the
following is a list of the ones I push into or their mirrors.  Some
repositories have only a subset of branches.

With maint, master, next, seen, todo:

	git://git.kernel.org/pub/scm/git/git.git/
	git://repo.or.cz/alt-git.git/
	https://kernel.googlesource.com/pub/scm/git/git/
	https://github.com/git/git/
	https://gitlab.com/git-scm/git/

With all the integration branches and topics broken out:

	https://github.com/gitster/git/

Even though the preformatted documentation in HTML and man format
are not sources, they are published in these repositories for
convenience (replace "htmldocs" with "manpages" for the manual
pages):

	git://git.kernel.org/pub/scm/git/git-htmldocs.git/
	https://github.com/gitster/git-htmldocs.git/

Release tarballs are available at:

	https://www.kernel.org/pub/software/scm/git/

--------------------------------------------------
[Graduated to 'master']

* bc/http-push-auth-netrc-fix (2025-02-24) 1 commit
  (merged to 'next' on 2025-02-26 at c2b83ec2e7)
 + http: allow using netrc for WebDAV-based HTTP protocol

 The netrc support (via the cURL library) for the HTTP transport has
 been re-enabled.
 source: <20250223015331.588161-2-sandals@crustytoothpaste.net>


* ek/mingw-rename-symlink (2025-02-21) 1 commit
  (merged to 'next' on 2025-02-24 at 8a9f3a5cdc)
 + compat/mingw: rename the symlink, not the target

 Symlink renaming fix.
 source: <pull.1864.git.1740139296483.gitgitgadget@gmail.com>


* jc/3.0-branches-remotes-update (2025-02-25) 1 commit
  (merged to 'next' on 2025-02-26 at 76db3e05d5)
 + BreakingChanges: clarify branches/ and remotes/

 Removal of ".git/branches" and ".git/remotes" support in the
 BreakingChanges document has been further clarified.
 source: <xmqqcyf5io61.fsf@gitster.g>


* jk/check-mailmap-wo-name-fix (2025-02-21) 1 commit
  (merged to 'next' on 2025-02-25 at d6d4e05ad1)
 + mailmap: fix check-mailmap with full mailmap line

 "git check-mailmap" segfault fix.
 source: <20250221-jk-fix-sendemail-mailinfo-v2-1-9aca7dc05dbb@gmail.com>


* kn/ref-migrate-skip-reflog (2025-02-21) 1 commit
  (merged to 'next' on 2025-02-25 at c402e09d08)
 + builtin/refs: add '--no-reflog' flag to drop reflogs

 "git refs migrate" can optionally be told not to migrate the reflog.
 source: <20250221100423.91075-1-karthik.188@gmail.com>


* pw/rebase-i-ff-empty-commit (2025-02-11) 1 commit
  (merged to 'next' on 2025-02-25 at 63db268d47)
 + rebase -i: reword empty commit after fast-forward

 "git rebase -i" failed to allow rewording an empty commit that has
 been fast-forwarded.
 source: <pull.1860.v2.git.1739289549299.gitgitgadget@gmail.com>


* rs/clear-commit-marks-optim (2025-02-24) 1 commit
  (merged to 'next' on 2025-02-26 at 1773f2a2ff)
 + commit: avoid parent list buildup in clear_commit_marks_many()

 A micro-optimization.
 source: <2bd2d71f-0ee6-405f-bec8-368406ca53c8@web.de>


* ua/os-version-capability (2025-02-19) 6 commits
  (merged to 'next' on 2025-02-24 at 89ad48db14)
 + agent: advertise OS name via agent capability
 + t5701: add setup test to remove side-effect dependency
 + version: extend get_uname_info() to hide system details
 + version: refactor get_uname_info()
 + version: refactor redact_non_printables()
 + version: replace manual ASCII checks with isprint() for clarity

 The value of "uname -s" is by default sent over the wire as a part
 of the "version" capability.
 source: <20250215155130.1756934-1-usmanakinyemi202@gmail.com>

--------------------------------------------------
[New Topics]

* lo/doc-merge-submodule-update (2025-02-25) 1 commit
  (merged to 'next' on 2025-02-27 at 8086c4ca60)
 + merge-strategies.adoc: detail submodule merge

 What happens to submodules during merge has been documented in a
 bit more detail.

 Will merge to 'master'.
 source: <20250225161800.8268-1-lucasseikioshiro@gmail.com>


* ps/maintenance-reflog-expire (2025-02-26) 6 commits
 - builtin/maintenance: introduce "reflog-expire" task
 - builtin/gc: split out function to expire reflog entries
 - builtin/reflog: make functions regarding `reflog_expire_options` public
 - builtin/reflog: stop storing per-reflog expiry dates globally
 - builtin/reflog: stop storing default reflog expiry dates globally
 - reflog: rename `cmd_reflog_expire_cb` to `reflog_expire_options`

 "git maintenance" learns a new task to expire reflog entries.

 Needs (real) review.
 source: <20250226-pks-maintenance-reflog-expire-v1-0-a1204a814952@pks.im>


* ps/refname-avail-check-optim (2025-02-28) 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()`

 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: <20250228-pks-update-ref-optimization-v4-0-6425c04268b5@pks.im>


* ps/build-meson-fixes (2025-02-27) 1 commit
  (merged to 'next' on 2025-02-28 at 7e8431ab25)
 + gitlab-ci: fix "msvc-meson" test job succeeding despite test failures

 CI fix.

 Will merge to 'master'.
 source: <20250227-b4-pks-gitlab-ci-fix-msvc-meson-tests-v1-1-0420abde3807@pks.im>


* tb/multi-cruft-paxk-refresh-fix (2025-02-27) 2 commits
 - builtin/pack-objects.c: freshen objects from existing cruft packs
 - builtin/repack.c: simplify cruft pack aggregation

 Certain "cruft" objects would have never been refreshed when there
 are multiple cruft packs in the repository, which has been
 corrected.

 Expecting a (hopefully minor and final) reroll.
 cf. <Z8Dvr3F1t7JKuNQf@nand.local>
 source: <cover.1740680964.git.me@ttaylorr.com>

--------------------------------------------------
[Cooking]

* jk/zlib-inflate-fixes (2025-02-25) 10 commits
 - unpack_loose_rest(): rewrite return handling for clarity
 - unpack_loose_rest(): simplify error handling
 - unpack_loose_rest(): never clean up zstream
 - unpack_loose_rest(): avoid numeric comparison of zlib status
 - unpack_loose_header(): avoid numeric comparison of zlib status
 - git_inflate(): skip zlib_post_call() sanity check on Z_NEED_DICT
 - unpack_loose_header(): fix infinite loop on broken zlib input
 - unpack_loose_header(): report headers without NUL as "bad"
 - unpack_loose_header(): simplify next_out assignment
 - loose_object_info(): BUG() on inflating content with unknown type

 Fix our use of zlib corner cases.

 Will merge to 'next'?
 source: <20250225062518.GA1293854@coredump.intra.peff.net>


* cc/signed-fast-export-import (2025-02-24) 6 commits
 - fast-export, fast-import: add support for signed-commits
 - fast-export: do not modify memory from get_commit_buffer
 - git-fast-export.txt: clarify why 'verbatim' may not be a good idea
 - fast-export: rename --signed-tags='warn' to 'warn-verbatim'
 - fast-export: fix missing whitespace after switch
 - git-fast-import.adoc: add missing LF in the BNF

 "git fast-export | git fast-import" learns to deal with commit and
 tag objects with embedded signatures a bit better.

 Needs review.
 source: <20250224142744.279643-1-christian.couder@gmail.com>


* dk/test-aggregate-results-paste-fix (2025-02-24) 1 commit
  (merged to 'next' on 2025-02-27 at cf8ba1cde5)
 + t/aggregate-results: fix paste(1) invocation

 The use of "paste" command for aggregating the test results have
 been corrected.

 Will merge to 'master'.
 source: <20250224192724.7625-1-ben.knoble+github@gmail.com>


* sk/unit-test-oid (2025-02-25) 4 commits
 - t/unit-tests: convert oidtree test to use clar test framework
 - t/unit-tests: convert oidmap test to use clar test framework
 - t/unit-tests: convert oid-array test to use clar test framework
 - t/unit-tests: implement clar specific oid helper functions

 Convert a few unit tests to the clar framework.

 Comments?
 source: <20250225101044.84210-1-kuforiji98@gmail.com>


* ps/meson-contrib-bits (2025-02-20) 10 commits
  (merged to 'next' on 2025-02-27 at ef18273a2d)
 + 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.

 Will merge to 'master'.
 source: <20250218-b4-pks-meson-contrib-v1-0-c3edd292beb8@pks.im>


* ms/merge-recursive-string-list-micro-optimization (2025-02-13) 1 commit
  (merged to 'next' on 2025-02-27 at 839741ad40)
 + merge-recursive: optimize time complexity for process_renames

 Rename processing in the recursive merge backend has seen a micro
 optimization.

 Will merge to 'master'.
 source: <20250214044129.15282-1-meetsoni3017@gmail.com>


* pb/doc-follow-remote-head (2025-02-14) 2 commits
 - config/remote.txt: improve wording for 'remote.<name>.followRemoteHEAD'
 - config/remote.txt: reunite 'severOption' description paragraphs

 source: <pull.1894.git.git.1739554578.gitgitgadget@gmail.com>


* jt/diff-pairs (2025-02-26) 3 commits
 - builtin/diff-pairs: allow explicit diff queue flush
 - builtin: introduce diff-pairs command
 - diff: return diff_filepair from diff queue helpers

 A post-processing filter for "diff --raw" output has been
 introduced.

 Comments?
 source: <20250225233925.1345086-1-jltobler@gmail.com>


* ps/path-sans-the-repository (2025-02-28) 16 commits
  (merged to 'next' on 2025-02-28 at 41875498b7)
 + 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 'master'.
 source: <20250207-b4-pks-path-drop-the-repository-v2-0-13cad3c11b8a@pks.im>


* 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>


* ps/reftable-windows-unlink-fix (2025-02-18) 2 commits
 - reftable: ignore file-in-use errors when unlink(3p) fails on Windows
 - Merge branch 'ps/reftable-sans-compat-util' into ps/reftable-windows-unlink-fix
 (this branch uses ps/reftable-sans-compat-util.)

 Portability fix.

 Waiting for the base topic to settle.
 source: <20250206-b4-pks-reftable-win32-in-use-errors-v2-1-56985a4f6186@pks.im>


* ps/build-meson-fixes-0130 (2025-02-26) 14 commits
  (merged to 'next' on 2025-02-27 at 55aaa8c63e)
 + 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.

 Will merge to 'master'.
 source: <20250226-b4-pks-meson-improvements-v3-0-60c77cf673ae@pks.im>


* ps/reftable-sans-compat-util (2025-02-18) 18 commits
 - Makefile: skip reftable library for Coccinelle
 - reftable: decouple from Git codebase by pulling in "compat/posix.h"
 - git-compat-util.h: split out POSIX-emulating bits
 - compat/mingw: split out POSIX-related bits
 - reftable/basics: introduce `REFTABLE_UNUSED` annotation
 - reftable/basics: stop using `SWAP()` macro
 - reftable/stack: stop using `sleep_millisec()`
 - reftable/system: introduce `reftable_rand()`
 - reftable/reader: stop using `ARRAY_SIZE()` macro
 - reftable/basics: provide wrappers for big endian conversion
 - reftable/basics: stop using `st_mult()` in array allocators
 - reftable: stop using `BUG()` in trivial cases
 - reftable/record: don't `BUG()` in `reftable_record_cmp()`
 - reftable/record: stop using `BUG()` in `reftable_record_init()`
 - reftable/record: stop using `COPY_ARRAY()`
 - reftable/blocksource: stop using `xmmap()`
 - reftable/stack: stop using `write_in_full()`
 - reftable/stack: stop using `read_in_full()`
 (this branch is used by ps/reftable-windows-unlink-fix.)

 Make the code in reftable library less reliant on the service
 routines it used to borrow from Git proper, to make it easier to
 use by external users of the library.

 Waiting for Acks, especially for Windows bits?
 source: <20250218-pks-reftable-drop-git-compat-util-v6-0-8c1f39fb4c02@pks.im>


* 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>


* jc/doc-attr-tree (2024-12-14) 1 commit
 - doc: give attr.tree a bit more visibility

 Make sure that "git --attr-source=X", GIT_ATTR_SOURCE, and
 attr.tree configuration variables appear at the same places in the
 documentation.

 On hold.
 cf. <20241216111112.GA2201417@coredump.intra.peff.net>
 source: <xmqq5xnladwi.fsf@gitster.g>


* cc/lop-remote (2025-02-18) 3 commits
 - doc: add technical design doc for large object promisors
 - promisor-remote: check advertised name or URL
 - Add 'promisor-remote' capability to protocol v2

 Large-object promisor protocol extension.

 Comments?
 source: <20250218113204.2847463-1-christian.couder@gmail.com>


* 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>


* ej/cat-file-remote-object-info (2025-02-24) 8 commits
 - cat-file: add remote-object-info to batch-command
 - transport: add client support for object-info
 - serve: advertise object-info feature
 - fetch-pack: move fetch initialization
 - fetch-pack: refactor packet writing
 - t1006: split test utility functions into new "lib-cat-file.sh"
 - cat-file: add declaration of variable i inside its for loop
 - git-compat-util: add strtoul_ul() with error handling

 "git cat-file --batch" and friends can optionally ask a remote
 server about objects it does not have.
 source: <20250221190451.12536-1-eric.peijian@gmail.com>

Re: What's cooking in git.git (Feb 2025, #09; Fri, 28)

[shejialuo]

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"?

Thanks,
Jialuo

Re: What's cooking in git.git (Feb 2025, #09; Fri, 28)

[Junio C Hamano]

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.

Re: What's cooking in git.git (Feb 2025, #09; Fri, 28)

[Patrick Steinhardt]

On Mon, Mar 03, 2025 at 09:03:53AM -0800, Junio C Hamano wrote:
> 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.

Yes, I'm happy with the current state of this patch series. I'm a tiny
bit worried about the new call to `git refs verify` in git-fsck(1) being
added this late into the release cycle as we're now exercising a bunch
of new code with only a few weeks of testing. My basic assumption is
that mostly noone uses `git refs verify` explicitly right now, so all of
the code we have introduced there over the last couple of releases did
not yet receive much testing at all.

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?

Patrick

Re: What's cooking in git.git (Feb 2025, #09; Fri, 28)

[shejialuo]

On Tue, Mar 04, 2025 at 07:27:37AM +0100, Patrick Steinhardt wrote:
> On Mon, Mar 03, 2025 at 09:03:53AM -0800, Junio C Hamano wrote:
> > 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.
> 
> Yes, I'm happy with the current state of this patch series. I'm a tiny
> bit worried about the new call to `git refs verify` in git-fsck(1) being
> added this late into the release cycle as we're now exercising a bunch
> of new code with only a few weeks of testing. My basic assumption is
> that mostly noone uses `git refs verify` explicitly right now, so all of
> the code we have introduced there over the last couple of releases did
> not yet receive much testing at all.
> 

Yes, I also think that there are few people who know the `git refs
verify` and execute this command. That's the reason why I want to
integrate `git refs verify` in git-fsck(1) thus we could get feedback
and improve the code.

However, as you have said, we are also taking the risk.

> 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?
> 

Yes, by dropping the last commit, the risk would be reduced. Actually, I
don't mind which way we choose. But I somehow think that we should
execute the command in git-fsck(1), we need to get the feedback from the
users. From my point, I want to know how do the users react to the new
aded checks. Because we have tightened more rules, some may be good and
some may not be reasonable. And we could improve this in the next
release.

However, as I have said, both way works fine for me. So, I am open.

Thanks,
Jialuo

> Patrick

Re: What's cooking in git.git (Feb 2025, #09; Fri, 28)

[Junio C Hamano]

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.

Re: What's cooking in git.git (Feb 2025, #09; Fri, 28)

[Karthik Nayak]

[-- Attachment #1: Type: text/plain, Size: 1515 bytes --]

Junio C Hamano <gitster@pobox.com> writes:

> 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.
>

Sorry I missed this email. I did review an earlier version of the series
and it did look good to me, haven't reviewed the latest version (but
that's not a blocker from my side).

> Thanks.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 690 bytes --]

Re: What's cooking in git.git (Feb 2025, #09; Fri, 28)

[Patrick Steinhardt]

On Fri, Feb 28, 2025 at 04:45:31PM -0800, Junio C Hamano wrote:
> * ps/reftable-sans-compat-util (2025-02-18) 18 commits
>  - Makefile: skip reftable library for Coccinelle
>  - reftable: decouple from Git codebase by pulling in "compat/posix.h"
>  - git-compat-util.h: split out POSIX-emulating bits
>  - compat/mingw: split out POSIX-related bits
>  - reftable/basics: introduce `REFTABLE_UNUSED` annotation
>  - reftable/basics: stop using `SWAP()` macro
>  - reftable/stack: stop using `sleep_millisec()`
>  - reftable/system: introduce `reftable_rand()`
>  - reftable/reader: stop using `ARRAY_SIZE()` macro
>  - reftable/basics: provide wrappers for big endian conversion
>  - reftable/basics: stop using `st_mult()` in array allocators
>  - reftable: stop using `BUG()` in trivial cases
>  - reftable/record: don't `BUG()` in `reftable_record_cmp()`
>  - reftable/record: stop using `BUG()` in `reftable_record_init()`
>  - reftable/record: stop using `COPY_ARRAY()`
>  - reftable/blocksource: stop using `xmmap()`
>  - reftable/stack: stop using `write_in_full()`
>  - reftable/stack: stop using `read_in_full()`
>  (this branch is used by ps/reftable-windows-unlink-fix.)
> 
>  Make the code in reftable library less reliant on the service
>  routines it used to borrow from Git proper, to make it easier to
>  use by external users of the library.
> 
>  Waiting for Acks, especially for Windows bits?
>  source: <20250218-pks-reftable-drop-git-compat-util-v6-0-8c1f39fb4c02@pks.im>

Johannes, did the new version of this patch series make your life any
easier? As far as I can see the conflicts in your "shears/seen" branch
seem to have been fixed, and the failing pipeline seems to be due to
other issues. If so, we would be able to move ahead with this patch
series and the dependent fix for Windows below.

> * ps/reftable-windows-unlink-fix (2025-02-18) 2 commits
>  - reftable: ignore file-in-use errors when unlink(3p) fails on Windows
>  - Merge branch 'ps/reftable-sans-compat-util' into ps/reftable-windows-unlink-fix
>  (this branch uses ps/reftable-sans-compat-util.)

Thanks!

Patrick

ps/reftable-sans-compat-util, was Re: What's cooking in git.git (Feb 2025, #09; Fri, 28)

[Johannes Schindelin]

Hi Patrick,

On Tue, 4 Mar 2025, Patrick Steinhardt wrote:

> On Fri, Feb 28, 2025 at 04:45:31PM -0800, Junio C Hamano wrote:
> > * ps/reftable-sans-compat-util (2025-02-18) 18 commits
> >  - Makefile: skip reftable library for Coccinelle
> >  - reftable: decouple from Git codebase by pulling in "compat/posix.h"
> >  - git-compat-util.h: split out POSIX-emulating bits
> >  - compat/mingw: split out POSIX-related bits
> >  - reftable/basics: introduce `REFTABLE_UNUSED` annotation
> >  - reftable/basics: stop using `SWAP()` macro
> >  - reftable/stack: stop using `sleep_millisec()`
> >  - reftable/system: introduce `reftable_rand()`
> >  - reftable/reader: stop using `ARRAY_SIZE()` macro
> >  - reftable/basics: provide wrappers for big endian conversion
> >  - reftable/basics: stop using `st_mult()` in array allocators
> >  - reftable: stop using `BUG()` in trivial cases
> >  - reftable/record: don't `BUG()` in `reftable_record_cmp()`
> >  - reftable/record: stop using `BUG()` in `reftable_record_init()`
> >  - reftable/record: stop using `COPY_ARRAY()`
> >  - reftable/blocksource: stop using `xmmap()`
> >  - reftable/stack: stop using `write_in_full()`
> >  - reftable/stack: stop using `read_in_full()`
> >  (this branch is used by ps/reftable-windows-unlink-fix.)
> >
> >  Make the code in reftable library less reliant on the service
> >  routines it used to borrow from Git proper, to make it easier to
> >  use by external users of the library.
> >
> >  Waiting for Acks, especially for Windows bits?
> >  source: <20250218-pks-reftable-drop-git-compat-util-v6-0-8c1f39fb4c02@pks.im>
>
> Johannes, did the new version of this patch series make your life any
> easier? As far as I can see the conflicts in your "shears/seen" branch
> seem to have been fixed, and the failing pipeline seems to be due to
> other issues. If so, we would be able to move ahead with this patch
> series and the dependent fix for Windows below.

Honestly, I cannot say whether it made my life any easier. As you can see
from
https://github.com/git-for-windows/git/actions/workflows/main.yml?query=branch%3Ashears%2Fseen,
the `shears/seen` branch failed to update automatically since I updated it
manually last Thursday. According to
https://github.com/git/git/activity?ref=seen, there have been 5 updates
that were hence missed.

I'll try to update the `shears/seen` branch now, but I'll time-box it to
half an hour because I really planned on taking care of other issues.

Ciao,
Johannes

Re: ps/reftable-sans-compat-util, was Re: What's cooking in git.git (Feb 2025, #09; Fri, 28)

[Johannes Schindelin]

Hi Patrick,

On Tue, 4 Mar 2025, Johannes Schindelin wrote:

> On Tue, 4 Mar 2025, Patrick Steinhardt wrote:
>
> > On Fri, Feb 28, 2025 at 04:45:31PM -0800, Junio C Hamano wrote:
> > > * ps/reftable-sans-compat-util (2025-02-18) 18 commits
> > >  - Makefile: skip reftable library for Coccinelle
> > >  - reftable: decouple from Git codebase by pulling in "compat/posix.h"
> > >  - git-compat-util.h: split out POSIX-emulating bits
> > >  - compat/mingw: split out POSIX-related bits
> > >  - reftable/basics: introduce `REFTABLE_UNUSED` annotation
> > >  - reftable/basics: stop using `SWAP()` macro
> > >  - reftable/stack: stop using `sleep_millisec()`
> > >  - reftable/system: introduce `reftable_rand()`
> > >  - reftable/reader: stop using `ARRAY_SIZE()` macro
> > >  - reftable/basics: provide wrappers for big endian conversion
> > >  - reftable/basics: stop using `st_mult()` in array allocators
> > >  - reftable: stop using `BUG()` in trivial cases
> > >  - reftable/record: don't `BUG()` in `reftable_record_cmp()`
> > >  - reftable/record: stop using `BUG()` in `reftable_record_init()`
> > >  - reftable/record: stop using `COPY_ARRAY()`
> > >  - reftable/blocksource: stop using `xmmap()`
> > >  - reftable/stack: stop using `write_in_full()`
> > >  - reftable/stack: stop using `read_in_full()`
> > >  (this branch is used by ps/reftable-windows-unlink-fix.)
> > >
> > >  Make the code in reftable library less reliant on the service
> > >  routines it used to borrow from Git proper, to make it easier to
> > >  use by external users of the library.
> > >
> > >  Waiting for Acks, especially for Windows bits?
> > >  source: <20250218-pks-reftable-drop-git-compat-util-v6-0-8c1f39fb4c02@pks.im>
> >
> > Johannes, did the new version of this patch series make your life any
> > easier? As far as I can see the conflicts in your "shears/seen" branch
> > seem to have been fixed, and the failing pipeline seems to be due to
> > other issues. If so, we would be able to move ahead with this patch
> > series and the dependent fix for Windows below.
>
> Honestly, I cannot say whether it made my life any easier. As you can see
> from
> https://github.com/git-for-windows/git/actions/workflows/main.yml?query=branch%3Ashears%2Fseen,
> the `shears/seen` branch failed to update automatically since I updated it
> manually last Thursday. According to
> https://github.com/git/git/activity?ref=seen, there have been 5 updates
> that were hence missed.
>
> I'll try to update the `shears/seen` branch now, but I'll time-box it to
> half an hour because I really planned on taking care of other issues.

It seems that there are the usual CMake-related breakages (not related to
ps/reftable-sans-compat-util, but to the introduction of the
`CLAR_TEST_OBJS` or at least the `lib-oid` addition to that). I hope that
the tip commit of `shears/seen` that I just pushed addresses that, but I
ran out of time to monitor this.

And there are some pretty bad `exit code 127` problems in the unit tests
on Windows, see e.g.
https://github.com/git-for-windows/git/actions/runs/13648196783/job/38151312208#step:5:213
(but again, I ran out of the allotted time).

Ciao,
Johannes

Re: ps/reftable-sans-compat-util, was Re: What's cooking in git.git (Feb 2025, #09; Fri, 28)

[Patrick Steinhardt]

On Tue, Mar 04, 2025 at 08:40:13AM +0100, Johannes Schindelin wrote:
> On Tue, 4 Mar 2025, Johannes Schindelin wrote:
> > On Tue, 4 Mar 2025, Patrick Steinhardt wrote:
> > > Johannes, did the new version of this patch series make your life any
> > > easier? As far as I can see the conflicts in your "shears/seen" branch
> > > seem to have been fixed, and the failing pipeline seems to be due to
> > > other issues. If so, we would be able to move ahead with this patch
> > > series and the dependent fix for Windows below.
> >
> > Honestly, I cannot say whether it made my life any easier. As you can see
> > from
> > https://github.com/git-for-windows/git/actions/workflows/main.yml?query=branch%3Ashears%2Fseen,
> > the `shears/seen` branch failed to update automatically since I updated it
> > manually last Thursday. According to
> > https://github.com/git/git/activity?ref=seen, there have been 5 updates
> > that were hence missed.
> >
> > I'll try to update the `shears/seen` branch now, but I'll time-box it to
> > half an hour because I really planned on taking care of other issues.
> 
> It seems that there are the usual CMake-related breakages (not related to
> ps/reftable-sans-compat-util, but to the introduction of the
> `CLAR_TEST_OBJS` or at least the `lib-oid` addition to that). I hope that
> the tip commit of `shears/seen` that I just pushed addresses that, but I
> ran out of time to monitor this.
> 
> And there are some pretty bad `exit code 127` problems in the unit tests
> on Windows, see e.g.
> https://github.com/git-for-windows/git/actions/runs/13648196783/job/38151312208#step:5:213
> (but again, I ran out of the allotted time).

Interesting. All of the errors relate to reftable stuff. Curiously,
those errors only seem to happen in the MinGW build, but not with the
Meson-based MSVC build. I can reproduce the issue in MinGW indeed, so
I'll investigate. Thanks for the hint!

Patrick

Re: ps/reftable-sans-compat-util, was Re: What's cooking in git.git (Feb 2025, #09; Fri, 28)

[Patrick Steinhardt]

On Tue, Mar 04, 2025 at 10:46:17AM +0100, Patrick Steinhardt wrote:
> On Tue, Mar 04, 2025 at 08:40:13AM +0100, Johannes Schindelin wrote:
> > On Tue, 4 Mar 2025, Johannes Schindelin wrote:
> > > On Tue, 4 Mar 2025, Patrick Steinhardt wrote:
> > > > Johannes, did the new version of this patch series make your life any
> > > > easier? As far as I can see the conflicts in your "shears/seen" branch
> > > > seem to have been fixed, and the failing pipeline seems to be due to
> > > > other issues. If so, we would be able to move ahead with this patch
> > > > series and the dependent fix for Windows below.
> > >
> > > Honestly, I cannot say whether it made my life any easier. As you can see
> > > from
> > > https://github.com/git-for-windows/git/actions/workflows/main.yml?query=branch%3Ashears%2Fseen,
> > > the `shears/seen` branch failed to update automatically since I updated it
> > > manually last Thursday. According to
> > > https://github.com/git/git/activity?ref=seen, there have been 5 updates
> > > that were hence missed.
> > >
> > > I'll try to update the `shears/seen` branch now, but I'll time-box it to
> > > half an hour because I really planned on taking care of other issues.
> > 
> > It seems that there are the usual CMake-related breakages (not related to
> > ps/reftable-sans-compat-util, but to the introduction of the
> > `CLAR_TEST_OBJS` or at least the `lib-oid` addition to that). I hope that
> > the tip commit of `shears/seen` that I just pushed addresses that, but I
> > ran out of time to monitor this.
> > 
> > And there are some pretty bad `exit code 127` problems in the unit tests
> > on Windows, see e.g.
> > https://github.com/git-for-windows/git/actions/runs/13648196783/job/38151312208#step:5:213
> > (but again, I ran out of the allotted time).
> 
> Interesting. All of the errors relate to reftable stuff. Curiously,
> those errors only seem to happen in the MinGW build, but not with the
> Meson-based MSVC build. I can reproduce the issue in MinGW indeed, so
> I'll investigate. Thanks for the hint!

Okay, I found the issue: it's mismatching allocators. Git for Windows
has support for the custom mimalloc allocator, and it's getting roped in
by default in MinGW builds. And because the allocator is declared in
"git-compat-util.h", the reftable library uses allocators from mscrt.dll,
whereas the rest of the Git code base uses allocators from mimalloc.
This causes us to sometimes free memory with a different allocator than
we have allocated it with, and that causes a SIGTRAP.

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

Re: ps/reftable-sans-compat-util, was Re: What's cooking in git.git (Feb 2025, #09; Fri, 28)

[Johannes Schindelin]

Hi Patrick,

On Tue, 4 Mar 2025, Patrick Steinhardt wrote:

> On Tue, Mar 04, 2025 at 10:46:17AM +0100, Patrick Steinhardt wrote:
> > On Tue, Mar 04, 2025 at 08:40:13AM +0100, Johannes Schindelin wrote:
> > > On Tue, 4 Mar 2025, Johannes Schindelin wrote:
> > > > On Tue, 4 Mar 2025, Patrick Steinhardt wrote:
> > > > > Johannes, did the new version of this patch series make your life any
> > > > > easier? As far as I can see the conflicts in your "shears/seen" branch
> > > > > seem to have been fixed, and the failing pipeline seems to be due to
> > > > > other issues. If so, we would be able to move ahead with this patch
> > > > > series and the dependent fix for Windows below.
> > > >
> > > > Honestly, I cannot say whether it made my life any easier. As you can see
> > > > from
> > > > https://github.com/git-for-windows/git/actions/workflows/main.yml?query=branch%3Ashears%2Fseen,
> > > > the `shears/seen` branch failed to update automatically since I updated it
> > > > manually last Thursday. According to
> > > > https://github.com/git/git/activity?ref=seen, there have been 5 updates
> > > > that were hence missed.
> > > >
> > > > I'll try to update the `shears/seen` branch now, but I'll time-box it to
> > > > half an hour because I really planned on taking care of other issues.
> > >
> > > It seems that there are the usual CMake-related breakages (not related to
> > > ps/reftable-sans-compat-util, but to the introduction of the
> > > `CLAR_TEST_OBJS` or at least the `lib-oid` addition to that). I hope that
> > > the tip commit of `shears/seen` that I just pushed addresses that, but I
> > > ran out of time to monitor this.
> > >
> > > And there are some pretty bad `exit code 127` problems in the unit tests
> > > on Windows, see e.g.
> > > https://github.com/git-for-windows/git/actions/runs/13648196783/job/38151312208#step:5:213
> > > (but again, I ran out of the allotted time).
> >
> > Interesting. All of the errors relate to reftable stuff. Curiously,
> > those errors only seem to happen in the MinGW build, but not with the
> > Meson-based MSVC build. I can reproduce the issue in MinGW indeed, so
> > I'll investigate. Thanks for the hint!
>
> Okay, I found the issue: it's mismatching allocators. Git for Windows
> has support for the custom mimalloc allocator, and it's getting roped in
> by default in MinGW builds. And because the allocator is declared in
> "git-compat-util.h", the reftable library uses allocators from mscrt.dll,
> whereas the rest of the Git code base uses allocators from mimalloc.
> This causes us to sometimes free memory with a different allocator than
> we have allocated it with, and that causes a SIGTRAP.
>
> 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

Thank you very much!
Johannes

Re: ps/reftable-sans-compat-util, was Re: What's cooking in git.git (Feb 2025, #09; Fri, 28)

[Junio C Hamano]

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.

Re: ps/reftable-sans-compat-util, was Re: What's cooking in git.git (Feb 2025, #09; Fri, 28)

[Patrick Steinhardt]

On Thu, Mar 27, 2025 at 08:28:34AM -0700, Junio C Hamano wrote:
> 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.

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!

Patrick

Re: ps/reftable-sans-compat-util, was Re: What's cooking in git.git (Feb 2025, #09; Fri, 28)

[Johannes Schindelin]

Hi,

On Fri, 28 Mar 2025, Patrick Steinhardt wrote:

> On Thu, Mar 27, 2025 at 08:28:34AM -0700, Junio C Hamano wrote:
> > 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.
>
> 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.

Ciao,
Johannes

Re: ps/reftable-sans-compat-util, was Re: What's cooking in git.git (Feb 2025, #09; Fri, 28)

[Junio C Hamano]

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.

Re: ps/reftable-sans-compat-util, was Re: What's cooking in git.git (Feb 2025, #09; Fri, 28)

[Junio C Hamano]

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'.