The Git project followed Git for Windows' lead and added their Code of
Conduct, based on the Contributor Covenant v1.4, later updated to v2.0.
We adapt it slightly to Git for Windows.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The Git for Windows project has grown quite complex over the years,
certainly much more complex than during the first years where the
`msysgit.git` repository was abusing Git for package management purposes
and the `git/git` fork was called `4msysgit.git`.
Let's describe the status quo in a thorough way.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Historically, the macOS jobs have always been among the longest-running
ones, and recently the `git p4` tests became another liability: They
started to fail much more often (maybe as of the switch away from the
`macos-13` pool?), requiring re-runs of the jobs that already were
responsible for long CI build times.
Of the 35 test scripts that exercise `git p4`, 32 are actually run on
macOS (3 are skipped for reasons like case-sensitivee filesystem), and
they take an accumulated runtime of over half an hour.
Furthermore, the `git p4` command is not really affected by Git for
Windows' patches, at least not as far as macOS is concerned, therefore
it is not only causing developer friction to have these long-running,
frequently failing tests, it is also quite wasteful: There has not been
a single instance so far where any `git p4` test failure in Git for
Windows had demonstrated an actionable bug.
So let's just disable those tests in the CI runs, at least on macOS.
This is the branch thicket of patches in Git for Windows that are
considered ready for upstream. To keep them in a ready-to-submit shape,
they are kept as close to the beginning of the branch thicket as
possible.
Historically, the macOS jobs have always been among the longest-running
ones, and recently the `git p4` tests became another liability: They
started to fail much more often (maybe as of the switch away from the
`macos-13` pool?), requiring re-runs of the jobs that already were
responsible for long CI build times.
Of the 35 test scripts that exercise `git p4`, 32 are actually run on
macOS (3 are skipped for reasons like case-sensitivee filesystem), and
they take an accumulated runtime of over half an hour.
Furthermore, the `git p4` command is not really affected by Git for
Windows' patches, at least not as far as macOS is concerned, therefore
it is not only causing developer friction to have these long-running,
frequently failing tests, it is also quite wasteful: There has not been
a single instance so far where any `git p4` test failure in Git for
Windows had demonstrated an actionable bug.
While upstream Git is confident to have addressed the flakiness of the
`git p4` tests via ffff0bb0da (Use Perforce arm64 binary on macOS CI
jobs, 2025-11-16) (which got slipped in at the 11th hour into the
v2.52.0 release, fast-tracked without ever hitting `seen` even after
-rc2 was released), I am not quite so confident, and besides, the
runtime penalty of running those tests in Git for Windows' CI runs is
still a worrisome burden.
So let's just disable those tests in the CI runs, at least on macOS.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When a server advertises Negotiate (SPNEGO) authentication alongside
Basic, the "auto" mode of http.emptyAuth should allow libcurl to
attempt Kerberos authentication using the system ticket cache before
falling back to credential_fill(). Currently this never happens due
to an interaction between two older features.
The Negotiate-stripping logic from 4dbe66464b (remote-curl: fall back
to Basic auth if Negotiate fails, 2015-01-08) removes
CURLAUTH_GSSNEGOTIATE on the first 401, before the auto-detection
from 40a18fc77c (http: add an "auto" mode for http.emptyauth,
2017-02-25) gets a chance to see it as an "exotic" method. The result
is that auto mode silently degrades to the same behavior as
emptyAuth=false for any server whose only non-Basic/Digest method is
Negotiate, forcing Kerberos users to manually set http.emptyAuth=true
to get seamless ticket-based authentication.
This series fixes the interaction by delaying the Negotiate stripping
in auto mode by one round-trip, giving empty auth a chance to use the
system Kerberos ticket. If there is no valid ticket, Negotiate is
stripped on the second 401 and we fall through to credential_fill()
as before. The true and false modes are unchanged.
Patch 1: Extract a http_reauth_prepare() helper from the three
retry paths that call credential_fill() on HTTP_REAUTH.
Pure refactor, no behavior change.
Patch 2: Delay the GSSNEGOTIATE stripping in auto mode and teach
http_reauth_prepare() to skip credential_fill() when
empty auth should be attempted first.
Patch 3: Add tests verifying that auto mode produces an extra
round-trip (empty auth attempt) compared to false mode,
using the existing nph-custom-auth.sh CGI infrastructure.
There is a trade-off in auto mode: when a server advertises Negotiate
but the client has no valid Kerberos ticket, there is one extra
round-trip compared to the current behavior. This matches the
trade-off already documented in 40a18fc77c. Users who want to avoid
it can set http.emptyAuth=false.
While the currently used way to detect the number of CPU cores ond
Windows is nice and straight-forward, GetSystemInfo() only [gives us
access to the number of processors within the current
group.](https://learn.microsoft.com/en-us/windows/win32/api/sysinfoapi/ns-sysinfoapi-system_info#members)
While that is usually fine for systems with a single physical CPU,
separate physical sockets are typically separate groups.
Switch to using GetLogicalProcessorInformationEx() to handle
multi-socket
systems better.
I've tested this on a physical single-socket x86-64 and a physical
dual-socket x86-64 system, and on a virtual single-socket ARM64 system.
Physical [multi-socket ARM64 systems seem to
exist](https://cloudbase.it/ampere-altra-industry-leading-arm64-server/),
but I don't have access to such hardware and the hypervisor I use
apparently can't emulate that either.
`remove_dir_recurse()` in `dir.c` doesn't check for mount points, even
though this check was already added for `git clean` in #2268. So `git
worktree remove` (or anything else that calls it) will traverse NTFS
junctions and delete whatever is there. Similar to #607.
This extends the same check from #2268 but for anything that calls
`remove_dir_recurse()`.
This topic branch addresses the following vulnerability:
- **CVE-2025-66413**:
When a user clones a repository from an attacker-controlled server,
Git may attempt NTLM authentication and disclose the user's NTLMv2 hash
to the remote server. Since NTLM hashing is weak, the captured hash can
potentially be brute-forced to recover the user's credentials. This is
addressed by disabling NTLM authentication by default.
(https://github.com/git-for-windows/git/security/advisories/GHSA-hv9c-4jm9-jh3x)
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Git v2.53.0-rc0 included f406b89552 (Merge branch
'ar/run-command-hook', 2026-01-06), which caused a regression on
Windows. While this merge was reverted for independent reasons in
a3d1f391d3 (Revert "Merge branch 'ar/run-command-hook'", 2026-01-15),
it seems worthwhile to ensure that writing to standard error from a
`pre-push` hook remains unbroken.
The symptom, when running this regression test case against
v2.53.0-rc0.windows.1 is that the `git push` fails, with this message
printed to standard error:
.git/hooks/pre-push: line 2: /dev/stderr: No such file or
direct[61/1940]
error: failed to push some refs to 'repo1'
When that hook runs, `/dev/stderr` is a symlink to `/proc/self/fd/2`, as
always, but `ls -l /proc/self/fd/` shows this in the failing run
total 0
lrwxrwxrwx 1 me 4096 0 Jan 27 14:34 0 -> pipe:[0]
lrwxrwxrwx 1 me 4096 0 Jan 27 14:34 1 -> pipe:[0]
lrwxrwxrwx 1 me 4096 0 Jan 27 14:34 2 -> pipe:[0]
instead of the expected contents (which are shown when running this
against v2.53.0-rc1.windows.1):
total 0
lrwxrwxrwx 1 me 4096 0 Jan 27 14:53 0 -> 'pipe:[0]'
lrwxrwxrwx 1 me 4096 0 Jan 27 14:53 1 -> /dev/cons1
lrwxrwxrwx 1 me 4096 0 Jan 27 14:53 2 -> '/path/to/git/t/trash
directory.t5571-pre-push-hook/actual'
This suggests that the underlying reason might be that `stdout` has an
exclusive handle to that pipe, and opening `stderr` (which points to the
same pipe) fails because of that exclusively-opened `stdout` handle.
This closes https://github.com/git-for-windows/git/issues/6053.
To avoid `check-whitespace` failures when rebasing Git for Windows onto
new Git versions, let's limit that job's scope to downstream commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This introduces `git survey` to Git for Windows ahead of upstream for
the express purpose of getting the path-based analysis in the hands of
more folks.
The inspiration of this builtin is
[`git-sizer`](https://github.com/github/git-sizer), but since that
command relies on `git cat-file --batch` to get the contents of objects,
it has limits to how much information it can provide.
This is mostly a rewrite of the `git survey` builtin that was introduced
into the `microsoft/git` fork in microsoft/git#667. That version had a
lot more bells and whistles, including an analysis much closer to what
`git-sizer` provides.
The biggest difference in this version is that this one is focused on
using the path-walk API in order to visit batches of objects based on a
common path. This allows identifying, for instance, the path that is
contributing the most to the on-disk size across all versions at that
path.
For example, here are the top ten paths contributing to my local Git
repository (which includes `microsoft/git` and `gitster/git`):
```
TOP FILES BY DISK SIZE
============================================================================
Path | Count | Disk Size | Inflated Size
-----------------------------------------+-------+-----------+--------------
whats-cooking.txt | 1373 | 11637459 | 37226854
t/helper/test-gvfs-protocol | 2 | 6847105 | 17233072
git-rebase--helper | 1 | 6027849 | 15269664
compat/mingw.c | 6111 | 5194453 | 463466970
t/helper/test-parse-options | 1 | 3420385 | 8807968
t/helper/test-pkt-line | 1 | 3408661 | 8778960
t/helper/test-dump-untracked-cache | 1 | 3408645 | 8780816
t/helper/test-dump-fsmonitor | 1 | 3406639 | 8776656
po/vi.po | 104 | 1376337 | 51441603
po/de.po | 210 | 1360112 | 71198603
```
This kind of analysis has been helpful in identifying the reasons for
growth in a few internal monorepos. Those findings motivated the changes
in #5157 and #5171.
With this early version in Git for Windows, we can expand the reach of
the experimental tool in advance of it being contributed to the upstream
project.
Unfortunately, this will mean that in the next `microsoft/git` rebase,
Jeff Hostetler's version will need to be pulled out since there are
enough conflicts. These conflicts include how tables are stored and
generated, as the version in this PR is slightly more general to allow
for different kinds of data.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Since Git LFS v3.5.x implicitly dropped Windows 7 support, we now want
users to be advised _what_ is going wrong on that Windows version. This
topic branch goes out of its way to provide users with such guidance.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This topic branch adds support for a more Windows-native user-wide
config file than `XDG_CONFIG_HOME` (or `~/.config/`) will ever be.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This topic branch contains a patch that made it into Git for Windows
v2.45.1 but not into Git v2.45.1 (because the latter does not come with
symlink support on Windows).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Another (hopefully clean) PR for showing the error warning about atomic
append on windows after failure on APFS, which returns EBADF not EINVAL.
Signed-off-by: David Lomas <dl3@pale-eds.co.uk>
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
This patch adds a GitHub workflow (to be triggered manually) to allow
for conveniently verifying that Git and Scalar still work as intended in
Windows Nano Server (a relatively small container base image that is
frequently used where a "small Windows" is needed, e.g. in automation
;-))
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
As per
https://github.com/git-for-windows/git/issues/4350#issuecomment-1485041503,
the major block for upgrading Git for Windows' OpenSSL from v1.1 to v3
is the tricky part where such an upgrade would break `git fetch`/`git
clone` and `git push` because the libcurl depends on the OpenSSL DLL,
and the major version bump will _change_ the file name of said DLL.
To overcome that, the plan is to build libcurl flavors for each
supported SSL/TLS backend, aligning with the way MSYS2 builds libcurl,
then switch Git for Windows' SDK to the Secure Channel-flavored libcurl,
and teach Git to look for the specific flavor of libcurl corresponding
to the `http.sslBackend` setting (if that was configured).
Here is the PR to teach Git that trick.
Every once in a while, there are bug reports in Git for Windows' bug
tracker that describe an issue running [inside MSYS2
proper](https://gitforwindows.org/install-inside-msys2-proper), totally
ignoring the big, honking warning on top of [the
page](https://gitforwindows.org/install-inside-msys2-proper) that spells
out clearly that this is an unsupported use case.
At the same time, we cannot easily deflect and say "just use MSYS2
directly" (and leave the "and stop pestering us" out). We cannot do that
because there is only an _MSYS_ `git` package in MSYS2 (i.e. a Git that
uses the quite slow POSIX emulation layer provided by the MSYS2
runtime), but no `mingw-w64-git` package (which would be equivalent in
speed to Git for Windows).
In https://github.com/msys2/MINGW-packages/pull/26470, I am preparing to
change that. As part of that PR, I noticed and fixed a couple of issues
_in `git-for-windows/git` that prevented full support for
`mingw-w64-git` in MSYS2, such as problems with CLANG64 and UCRT64.
While at it, I simplified the entire setup to trust MSYS2's
`MINGW_PREFIX` & related environment variables instead of hard-coding
values like the installation prefix and what `MSYSTEM` to fall back on
if it is unset.
It is merely a historical wart that, say, `git-commit` exists in the
`libexec/git-core/` directory, a tribute to the original idea to let Git
be essentially a bunch of Unix shell scripts revolving around very few
"plumbing" (AKA low-level) commands.
Git has evolved a lot from there. These days, most of Git's
functionality is contained within the `git` executable, in the form of
"built-in" commands.
To accommodate for scripts that use the "dashed" form of Git commands,
even today, Git provides hard-links that make the `git` executable
available as, say, `git-commit`, just in case that an old script has not
been updated to invoke `git commit`.
Those hard-links do not come cheap: they take about half a minute for
every build of Git on Windows, they are mistaken for taking up huge
amounts of space by some Windows Explorer versions that do not
understand hard-links, and therefore many a "bug" report had to be
addressed.
The "dashed form" has been officially deprecated in Git version 1.5.4,
which was released on February 2nd, 2008, i.e. a very long time ago.
This deprecation was never finalized by skipping these hard-links, but
we can start the process now, in Git for Windows.
This addresses the concern raised in
https://github.com/git-for-windows/git/pull/4185#discussion_r1051661894
It is checked for w.r.t. global repository struct down in the callstack
in compatibility layer for MinGW before being assigned in the function
that `free()`'d it.
Add `FileVersion`, which is a required string ([Microsoft
documentation](https://learn.microsoft.com/en-us/windows/win32/menurc/versioninfo-resource))
in the `StringFileInfo` block.
As not all required strings were present in the block, none were being
included.
Fixes#4090
After including the `FileVersion` string, all other defined strings are
now being included on executables.
File version information for `git.exe` has changed from:
```
PS C:\Program Files\Git\bin> [System.Diagnostics.FileVersionInfo]::GetVersionInfo("C:\Data\git-sdk-64\usr\src\git\git.exe") | Select-Object *
FileVersionRaw : 2.38.1.1
ProductVersionRaw : 2.38.1.1
Comments :
CompanyName :
FileBuildPart : 1
FileDescription :
FileMajorPart : 2
FileMinorPart : 38
FileName : C:\Data\git-sdk-64\usr\src\git\git.exe
FilePrivatePart : 1
FileVersion :
InternalName :
IsDebug : False
IsPatched : False
IsPrivateBuild : False
IsPreRelease : False
IsSpecialBuild : False
Language : English (United States)
LegalCopyright :
LegalTrademarks :
OriginalFilename :
PrivateBuild :
ProductBuildPart : 1
ProductMajorPart : 2
ProductMinorPart : 38
ProductName :
ProductPrivatePart : 1
ProductVersion :
SpecialBuild :
```
To the following:
```
PS C:\Program Files\Git\bin> [System.Diagnostics.FileVersionInfo]::GetVersionInfo("C:\Data\git-sdk-64\usr\src\git\git.exe") | Select-Object *
FileVersionRaw : 2.38.1.1
ProductVersionRaw : 2.38.1.1
Comments :
CompanyName : The Git Development Community
FileBuildPart : 1
FileDescription : Git for Windows
FileMajorPart : 2
FileMinorPart : 38
FileName : C:\Data\git-sdk-64\usr\src\git\git.exe
FilePrivatePart : 1
FileVersion : 2.38.1.windows.1.10.g6ed65a6fab
InternalName : git
IsDebug : False
IsPatched : False
IsPrivateBuild : False
IsPreRelease : False
IsSpecialBuild : False
Language : English (United States)
LegalCopyright :
LegalTrademarks :
OriginalFilename : git.exe
PrivateBuild :
ProductBuildPart : 1
ProductMajorPart : 2
ProductMinorPart : 38
ProductName : Git
ProductPrivatePart : 1
ProductVersion : 2.38.1.windows.1.10.g6ed65a6fab
SpecialBuild :
```
I wasn't really expecting `GIT_VERSION` to contain the Git commit, I was
hoping for just `2.38.1` or `2.38.1.1`, at least for the `FileVersion`
string.
Anybody know if it's possible to concatenate the `MAJOR`, `MINOR`,
`MICRO`, and `PATCHLEVEL` fields with dots, or if there's another
variable that can be used (with or without `PATCHLEVEL`)?
Alternatively, use the complete `GIT_VERSION` for both `FileVersion` and
`ProductVersion`.
The first three commits are rebased versions of those in gitgitgadget/git#1215. These allow the following:
1. Fix `git config --global foo.bar <path>` from allowing the `<path>`. As a bonus, users with a config value starting with `/` will not get a warning about "old-style" paths needing a "`%(prefix)/`".
2. When in WSL, the path starts with `/` so it needs to be interpolated properly. Update the warning to include `%(prefix)/` to get the right value for WSL users. (This is specifically for using Git for Windows from Git Bash, but in a WSL directory.)
3. When using WSL, the ownership check fails and reports an error message. This is noisy, and happens even if the user has marked the path with `safe.directory`. Remove that error message.
Add tests exercising the interaction between http.emptyAuth and
servers that advertise Negotiate (SPNEGO) authentication.
Verify that auto mode gives Negotiate a chance via empty auth
(resulting in two 401 responses before falling through to
credential_fill with Basic credentials), and that false mode
strips Negotiate immediately (only one 401 response).
Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com>
It was already decided in ef22148 (clean: do not traverse mount points,
2018-12-07) that we shouldn't traverse NTFS junctions/bind mounts when
using `git clean`, partly because they're sometimes used in worktrees.
But the same check wasn't applied to `remove_dir_recurse()` in `dir.c`,
which `git worktree remove` uses. So removing a worktree suffers the
same problem we had previously with `git clean`.
Let's add the same guard from ef22148.
Signed-off-by: Maks Kuznia <makskuznia244@gmail.com>
The previous commits disabled NTLM authentication by default due to its
cryptographic weaknesses. Users can re-enable it via the config setting
http.<url>.allowNTLMAuth, but this requires manual intervention.
Credential helpers may have knowledge about which servers are trusted
for NTLM authentication (e.g., known on-prem Azure DevOps instances).
To allow them to signal this trust, introduce a simple negotiation:
when NTLM is suppressed and the server offered it, Git advertises
ntlm=suppressed to the credential helper. The helper can respond with
ntlm=allow to re-enable NTLM for this request.
This happens precisely at the point where we would otherwise warn the
user about NTLM being suppressed, ensuring the capability is only
advertised when relevant.
Helped-by: Matthew John Cheetham <mjcheetham@outlook.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The 2.53.0.rc0.windows release candidate had a regression where
writing to stderr from a pre-push hook would error out.
The regression was fixed in 2.53.0.rc1.windows and the test here ensures
that this stays fixed.
Signed-off-by: Thomas Braun <thomas.braun@virtuell-zuhause.de>
Every once in a while, whitespace errors are introduced in Git for
Windows' rebases to newer Git versions, simply by virtue of integrating
upstream commits that do not follow upstream Git's own whitespace rule.
In Git v2.50.0-rc0, for example, 03f2915541 (xdiff: disable
cleanup_records heuristic with --minimal, 2025-04-29) introduced a
trailing space.
Arguably, non-actionable alerts are worse than no alerts at all, so
let's suppress those alerts that we cannot do anything about, anyway.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The reftable library goes out of its way to use its own set of allocator
functions that can be configured using `reftable_set_alloc()`. However,
Git does not configure this.
That is not typically a problem, except when Git uses a custom allocator
via some definitions in `git-compat-util.h`, as is the case in Git for
Windows (which switched away from the long-unmaintained nedmalloc to
mimalloc).
Then, it is quite possible that Git assigns a `strbuf` (allocated via
the custom allocator) to, say, the `refname` field of a
`reftable_log_record` in `write_transaction_table()`, and later on asks
the reftable library function `reftable_log_record_release()` to release
it, but that function was compiled without using `git-compat-util.h` and
hence calls regular `free()` (i.e. _not_ the custom allocator's own
function).
This has been a problem for a long time and it was a matter of some sort
of "luck" that 1) reftables are not commonly used on Windows, and 2)
mimalloc can often ignore gracefully when it is asked to release memory
that it has not allocated.
However, a recent update to `seen` brought this problem to the
forefront, letting t1460 fail in Git for Windows, with symptoms much in
the same way as the problem I had to address in d02c37c3e6
(t-reftable-basics: allow for `malloc` to be `#define`d, 2025-01-08)
where exit code 127 was also produced in lieu of
`STATUS_HEAP_CORRUPTION` (C0000374) because exit codes are only 7 bits
wide.
It was not possible to figure out what change in particular caused these
new failures within a reasonable time frame, as there are too many
changes in `seen` that conflict with Git for Windows' patches, I had to
stop the investigation after spending four hours on it fruitlessly.
To verify that this patch fixes the issue, I avoided using mimalloc and
temporarily patched in a "custom allocator" that would more reliably
point out problems, like this:
diff --git a/refs/reftable-backend.c b/refs/reftable-backend.c
index 68f38291f84c..9421d630b9f5 100644
--- a/refs/reftable-backend.c
+++ b/refs/reftable-backend.c
@@ -353,6 +353,69 @@ static int reftable_be_fsync(int fd)
return fsync_component(FSYNC_COMPONENT_REFERENCE, fd);
}
+#define DEBUG_REFTABLE_ALLOC
+#ifdef DEBUG_REFTABLE_ALLOC
+#include "khash.h"
+
+static inline khint_t __ac_X31_hash_ptr(void *ptr)
+{
+ union {
+ void *ptr;
+ char s[sizeof(void *)];
+ } u;
+ size_t i;
+ khint_t h;
+
+ u.ptr = ptr;
+ h = (khint_t)*u.s;
+ for (i = 0; i < sizeof(void *); i++)
+ h = (h << 5) - h + (khint_t)u.s[i];
+ return h;
+}
+
+#define kh_ptr_hash_func(key) __ac_X31_hash_ptr(key)
+#define kh_ptr_hash_equal(a, b) ((a) == (b))
+
+KHASH_INIT(ptr, void *, int, 0, kh_ptr_hash_func, kh_ptr_hash_equal)
+
+static kh_ptr_t *my_malloced;
+
+static void *my_malloc(size_t sz)
+{
+ int dummy;
+ void *ptr = malloc(sz);
+ if (ptr)
+ kh_put_ptr(my_malloced, ptr, &dummy);
+ return ptr;
+}
+
+static void *my_realloc(void *ptr, size_t sz)
+{
+ int dummy;
+ if (ptr) {
+ khiter_t pos = kh_get_ptr(my_malloced, ptr);
+ if (pos >= kh_end(my_malloced))
+ die("Was not my_malloc()ed: %p", ptr);
+ kh_del_ptr(my_malloced, pos);
+ }
+ ptr = realloc(ptr, sz);
+ if (ptr)
+ kh_put_ptr(my_malloced, ptr, &dummy);
+ return ptr;
+}
+
+static void my_free(void *ptr)
+{
+ if (ptr) {
+ khiter_t pos = kh_get_ptr(my_malloced, ptr);
+ if (pos >= kh_end(my_malloced))
+ die("Was not my_malloc()ed: %p", ptr);
+ kh_del_ptr(my_malloced, pos);
+ }
+ free(ptr);
+}
+#endif
+
static struct ref_store *reftable_be_init(struct repository *repo,
const char *gitdir,
unsigned int store_flags)
@@ -362,6 +425,11 @@ static struct ref_store *reftable_be_init(struct repository *repo,
int is_worktree;
mode_t mask;
+#ifdef DEBUG_REFTABLE_ALLOC
+ my_malloced = kh_init_ptr();
+ reftable_set_alloc(my_malloc, my_realloc, my_free);
+#endif
+
mask = umask(0);
umask(mask);
I briefly considered contributing this "custom allocator" patch, too,
but it is unwieldy (for example, it would not work at all when compiling
with mimalloc support) and it would only waste space (or even time, if a
compile flag was introduced and exercised as part of the CI builds).
Given that it is highly unlikely that Git will lose the new
`reftable_set_alloc()` call by mistake, I rejected that idea as simply
too wasteful.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
