Skip to content

Rebase shears/main: 2 conflict(s) (0 skipped, 2 resolved) (#26503349023)#207

Open
gitforwindowshelper[bot] wants to merge 311 commits into
base/shears/main-26503349023from
shears/main-26503349023
Open

Rebase shears/main: 2 conflict(s) (0 skipped, 2 resolved) (#26503349023)#207
gitforwindowshelper[bot] wants to merge 311 commits into
base/shears/main-26503349023from
shears/main-26503349023

Conversation

@gitforwindowshelper
Copy link
Copy Markdown

Workflow run

Rebase Summary: main

From: 787131b09b (Drop mimalloc (git-for-windows#6231), 2026-05-26) (af02d4239f..787131b09b)

Resolved: 348c033 (compat/mingw: handle WSA errors in strerror, 2024-12-22)

kept both u-mingw and u-odb-inmemory entries in alphabetical order in Makefile and t/meson.build

Range-diff
  • 1: 348c033 ! 1: 383761d compat/mingw: handle WSA errors in strerror

    @@ Makefile: CLAR_TEST_SUITES += u-hash
      CLAR_TEST_SUITES += u-list-objects-filter-options
      CLAR_TEST_SUITES += u-mem-pool
     +CLAR_TEST_SUITES += u-mingw
    + CLAR_TEST_SUITES += u-odb-inmemory
      CLAR_TEST_SUITES += u-oid-array
      CLAR_TEST_SUITES += u-oidmap
    - CLAR_TEST_SUITES += u-oidtree
     
      ## compat/mingw-posix.h ##
     @@ compat/mingw-posix.h: int mingw_socket(int domain, int type, int protocol);
    @@ t/meson.build: clar_test_suites = [
        'unit-tests/u-list-objects-filter-options.c',
        'unit-tests/u-mem-pool.c',
     +  'unit-tests/u-mingw.c',
    +   'unit-tests/u-odb-inmemory.c',
        'unit-tests/u-oid-array.c',
        'unit-tests/u-oidmap.c',
    -   'unit-tests/u-oidtree.c',
     
      ## t/unit-tests/u-mingw.c (new) ##
     @@

Resolved: 5835e5b06c (AGENTS.md: document amend!, fixup-only PRs, and direct GfW PRs (git-for-windows#6232), 2026-05-26)

Resolved AA conflict in AGENTS.md by taking second parent's version (HEAD + 95 new lines); all other files resolved to HEAD since the merge only modified AGENTS.md

Range-diff
  • 1: 5835e5b06c ! 1: 869c34c AGENTS.md: document amend!, fixup-only PRs, and direct GfW PRs (AGENTS.md: document amend!, fixup-only PRs, and direct GfW PRs git#6232)

    @@ Commit message
     
         Add subsections that cover those gaps. Nothing in the existing text
         changes.
    +
    + ## AGENTS.md ##
    + remerge CONFLICT (add/add): Merge conflict in AGENTS.md
    + index 2b0baac7ac..c60945448f 100644
    + --- AGENTS.md
    + +++ AGENTS.md
    +@@ AGENTS.md: gets squashed into.
    + 
    + Run affected tests before finalizing.
    + 
    +-<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 1c895d818c (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233))
    +-================================
    + ### `amend!` Commits
    + 
    + A `fixup!` commit keeps the target's commit message and merely combines
    +@@ AGENTS.md: This is the preferred pattern for reverting a multi-commit downstream
    + feature. Order the fixups in **reverse** of the originals so each
    + revert applies cleanly to the worktree as you build the series.
    + 
    +->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs)
    + ### Common Adaptation Patterns
    + 
    + **Struct field moves**: When upstream moves fields between structs, update
    +@@ AGENTS.md: On Windows, `unsigned long` is 32 bits even on 64-bit systems. Use `size_t`
    + for sizes that may exceed 4GB. Be careful with format strings: use `PRIuMAX`
    + with a cast for `size_t` values.
    + 
    +-<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 1c895d818c (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233))
    +-================================
    + ## Contributing to Git for Windows
    + 
    + The primary contribution path for this fork is a PR against
    +@@ AGENTS.md: upstream commit's diff is the canonical pattern. The next
    + merging-rebase that picks up the upstream commit will recognize the
    + two as byte-identical and collapse them.
    + 
    +->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs)
    + ## Contributing to Upstream Git via GitGitGadget
    + 
    + ### Overview
    +
    + ## Documentation/config/sideband.adoc ##
    + remerge CONFLICT (add/add): Merge conflict in Documentation/config/sideband.adoc
    + index 41b35fb440..96fade7f5f 100644
    + --- Documentation/config/sideband.adoc
    + +++ Documentation/config/sideband.adoc
    +@@ Documentation/config/sideband.adoc: sideband.allowControlCharacters::
    + 	By default, control characters that are delivered via the sideband
    + 	are masked, except ANSI color sequences. This prevents potentially
    + 	unwanted ANSI escape sequences from being sent to the terminal. Use
    +-<<<<<<< 1c895d818c (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233))
    + 	this config setting to override this behavior (the value can be
    + 	a comma-separated list of the following keywords):
    + +
    +@@ Documentation/config/sideband.adoc: sideband.allowControlCharacters::
    + sideband.<url>.*::
    + 	Apply the `sideband.*` option selectively to specific URLs. The
    + 	same URL matching logic applies as for `http.<url>.*` settings.
    +-=======
    +-	this config setting to override this behavior:
    +-+
    +---
    +-	color::
    +-		Allow ANSI color sequences, line feeds and horizontal tabs,
    +-		but mask all other control characters. This is the default.
    +-	false::
    +-		Mask all control characters other than line feeds and
    +-		horizontal tabs.
    +-	true::
    +-		Allow all control characters to be sent to the terminal.
    +---
    +->>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs)
    +
    + ## Makefile ##
    + remerge CONFLICT (content): Merge conflict in Makefile
    + index ccfd36dab1..7b8ed395c2 100644
    + --- Makefile
    + +++ Makefile
    +@@ Makefile: CLAR_TEST_SUITES += u-hashmap
    + CLAR_TEST_SUITES += u-list-objects-filter-options
    + CLAR_TEST_SUITES += u-mem-pool
    + CLAR_TEST_SUITES += u-mingw
    +-<<<<<<< 1c895d818c (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233))
    + CLAR_TEST_SUITES += u-odb-inmemory
    +-=======
    +->>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs)
    + CLAR_TEST_SUITES += u-oid-array
    + CLAR_TEST_SUITES += u-oidmap
    + CLAR_TEST_SUITES += u-oidtree
    +@@ Makefile: $(MIMALLOC_OBJS): COMPAT_CFLAGS += \
    + endif
    + endif
    + 
    +-<<<<<<< 1c895d818c (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233))
    + 
    +-=======
    +->>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs)
    + ifdef OVERRIDE_STRDUP
    + 	COMPAT_CFLAGS += -DOVERRIDE_STRDUP
    + 	COMPAT_OBJS += compat/strdup.o
    +
    + ## compat/mingw.c ##
    + remerge CONFLICT (content): Merge conflict in compat/mingw.c
    + index 4ed96e47cb..940243e0a3 100644
    + --- compat/mingw.c
    + +++ compat/mingw.c
    +@@ compat/mingw.c: int mingw_unlink(const char *pathname, int handle_in_use_error)
    + 		return -1;
    + 
    + 	if (use_legacy_delete < 0)
    +-<<<<<<< 1c895d818c (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233))
    + 		use_legacy_delete = git_env_bool("GIT_TEST_LEGACY_DELETE", 0);
    +-=======
    +-		use_legacy_delete = !!getenv("GIT_TEST_LEGACY_DELETE");
    +->>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs)
    + 
    + 	if (try_delete_file(wpathname, use_legacy_delete))
    + 		return 0;
    +
    + ## config.mak.dev ##
    + remerge CONFLICT (content): Merge conflict in config.mak.dev
    + index 787c2eec46..9906065b15 100644
    + --- config.mak.dev
    + +++ config.mak.dev
    +@@ config.mak.dev: endif
    + endif
    + 
    + ifneq ($(uname_S),FreeBSD)
    +-<<<<<<< 1c895d818c (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233))
    + ifneq ($(filter gcc6,$(COMPILER_FEATURES)),)
    +-=======
    +-ifneq ($(or $(filter gcc6,$(COMPILER_FEATURES)),$(filter clang7,$(COMPILER_FEATURES))),)
    +->>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs)
    + ifndef USE_MIMALLOC
    + DEVELOPER_CFLAGS += -std=gnu99
    + endif
    +
    + ## contrib/buildsystems/CMakeLists.txt ##
    + remerge CONFLICT (content): Merge conflict in contrib/buildsystems/CMakeLists.txt
    + index a9bea01673..d80160cf96 100644
    + --- contrib/buildsystems/CMakeLists.txt
    + +++ contrib/buildsystems/CMakeLists.txt
    +@@ contrib/buildsystems/CMakeLists.txt: if(CMAKE_SYSTEM_NAME STREQUAL "Windows")
    + 	add_compile_definitions(HAVE_ALLOCA_H NO_POSIX_GOODIES NATIVE_CRLF NO_UNIX_SOCKETS WIN32
    + 				_CONSOLE DETECT_MSYS_TTY STRIP_EXTENSION=".exe"  NO_SYMLINK_HEAD UNRELIABLE_FSTAT
    + 				NOGDI OBJECT_CREATION_MODE=1 __USE_MINGW_ANSI_STDIO=0
    +-<<<<<<< 1c895d818c (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233))
    + 				OVERRIDE_STRDUP MMAP_PREVENTS_DELETE USE_WIN32_MMAP
    +-=======
    +-				USE_NED_ALLOCATOR OVERRIDE_STRDUP MMAP_PREVENTS_DELETE USE_WIN32_MMAP
    +->>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs)
    + 				HAVE_WPGMPTR HAVE_RTLGENRANDOM)
    + 	if(CMAKE_GENERATOR_PLATFORM STREQUAL "x64")
    + 		add_compile_definitions(ENSURE_MSYSTEM_IS_SET="MINGW64" MINGW_PREFIX="mingw64")
    +@@ contrib/buildsystems/CMakeLists.txt: if(CMAKE_SYSTEM_NAME STREQUAL "Windows")
    + 		compat/win32/trace2_win32_process_info.c
    + 		compat/win32/dirent.c
    + 		compat/win32/wsl.c
    +-<<<<<<< 1c895d818c (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233))
    +-=======
    +-		compat/nedmalloc/nedmalloc.c
    +->>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs)
    + 		compat/strdup.c
    + 		compat/win32/fscache.c)
    + 	set(NO_UNIX_SOCKETS 1)
    +
    + ## sideband.c ##
    + remerge CONFLICT (content): Merge conflict in sideband.c
    + index c628398d1e..1523a53e1d 100644
    + --- sideband.c
    + +++ sideband.c
    +@@ sideband.c: static struct keyword_entry keywords[] = {
    + };
    + 
    + static enum {
    +-<<<<<<< 1c895d818c (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233))
    + 	ALLOW_CONTROL_SEQUENCES_UNSET = -1,
    + 	ALLOW_NO_CONTROL_CHARACTERS   = 0,
    + 	ALLOW_ANSI_COLOR_SEQUENCES    = 1<<0,
    +@@ sideband.c: void sideband_apply_url_config(const char *url)
    + 	string_list_clear(&config.vars, 1);
    + 	urlmatch_config_release(&config);
    + }
    +-=======
    +-	ALLOW_NO_CONTROL_CHARACTERS = 0,
    +-	ALLOW_ALL_CONTROL_CHARACTERS = 1,
    +-	ALLOW_ANSI_COLOR_SEQUENCES = 2
    +-} allow_control_characters = ALLOW_ANSI_COLOR_SEQUENCES;
    +->>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs)
    + 
    + /* Returns a color setting (GIT_COLOR_NEVER, etc). */
    + static enum git_colorbool use_sideband_colors(void)
    +@@ sideband.c: static enum git_colorbool use_sideband_colors(void)
    + 	if (use_sideband_colors_cached != GIT_COLOR_UNKNOWN)
    + 		return use_sideband_colors_cached;
    + 
    +-<<<<<<< 1c895d818c (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233))
    + 	if (allow_control_characters == ALLOW_CONTROL_SEQUENCES_UNSET) {
    + 		if (!repo_config_get_value(the_repository, "sideband.allowcontrolcharacters", &value))
    + 			sideband_allow_control_characters_config("sideband.allowcontrolcharacters", value);
    + 
    + 		if (allow_control_characters == ALLOW_CONTROL_SEQUENCES_UNSET)
    + 			allow_control_characters = ALLOW_DEFAULT_ANSI_SEQUENCES;
    +-=======
    +-	switch (repo_config_get_maybe_bool(the_repository, "sideband.allowcontrolcharacters", &i)) {
    +-	case 0: /* Boolean value */
    +-		allow_control_characters = i ? ALLOW_ALL_CONTROL_CHARACTERS :
    +-			ALLOW_NO_CONTROL_CHARACTERS;
    +-		break;
    +-	case -1: /* non-Boolean value */
    +-		if (repo_config_get_string_tmp(the_repository, "sideband.allowcontrolcharacters",
    +-					      &value))
    +-			; /* huh? `get_maybe_bool()` returned -1 */
    +-		else if (!strcmp(value, "color"))
    +-			allow_control_characters = ALLOW_ANSI_COLOR_SEQUENCES;
    +-		else
    +-			warning(_("unrecognized value for `sideband."
    +-				  "allowControlCharacters`: '%s'"), value);
    +-		break;
    +-	default:
    +-		break; /* not configured */
    +->>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs)
    + 	}
    + 
    + 	if (!repo_config_get_string_tmp(the_repository, key, &value))
    +@@ sideband.c: void list_config_color_sideband_slots(struct string_list *list, const char *pref
    + 		list_config_item(list, prefix, keywords[i].keyword);
    + }
    + 
    +-<<<<<<< 1c895d818c (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233))
    + static int handle_ansi_sequence(struct strbuf *dest, const char *src, int n)
    +-=======
    +-static int handle_ansi_color_sequence(struct strbuf *dest, const char *src, int n)
    +->>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs)
    + {
    + 	int i;
    + 
    +@@ sideband.c: static int handle_ansi_color_sequence(struct strbuf *dest, const char *src, int
    + 	 * Valid ANSI color sequences are of the form
    + 	 *
    + 	 * ESC [ [<n> [; <n>]*] m
    +-<<<<<<< 1c895d818c (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233))
    + 	 *
    + 	 * These are part of the Select Graphic Rendition sequences which
    + 	 * contain more than just color sequences, for more details see
    +@@ sideband.c: static int handle_ansi_color_sequence(struct strbuf *dest, const char *src, int
    + 		     strchr("ABCDEFGHf", src[i])) ||
    + 		    ((allow_control_characters & ALLOW_ANSI_ERASE) &&
    + 		     strchr("JKMPX", src[i]))) {
    +-=======
    +-	 */
    +-
    +-	if (allow_control_characters != ALLOW_ANSI_COLOR_SEQUENCES ||
    +-	    n < 3 || src[0] != '\x1b' || src[1] != '[')
    +-		return 0;
    +-
    +-	for (i = 2; i < n; i++) {
    +-		if (src[i] == 'm') {
    +->>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs)
    + 			strbuf_add(dest, src, i + 1);
    + 			return i;
    + 		}
    +@@ sideband.c: static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
    + {
    + 	int i;
    + 
    +-<<<<<<< 1c895d818c (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233))
    + 	if ((allow_control_characters & ALLOW_ALL_CONTROL_CHARACTERS)) {
    +-=======
    +-	if (allow_control_characters == ALLOW_ALL_CONTROL_CHARACTERS) {
    +->>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs)
    + 		strbuf_add(dest, src, n);
    + 		return;
    + 	}
    + 
    + 	strbuf_grow(dest, n);
    + 	for (; n && *src; src++, n--) {
    +-<<<<<<< 1c895d818c (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233))
    + 		if (!iscntrl(*src) || *src == '\t' || *src == '\n') {
    + 			strbuf_addch(dest, *src);
    + 		} else if (allow_control_characters != ALLOW_NO_CONTROL_CHARACTERS &&
    + 			   (i = handle_ansi_sequence(dest, src, n))) {
    +-=======
    +-		if (!iscntrl(*src) || *src == '\t' || *src == '\n')
    +-			strbuf_addch(dest, *src);
    +-		else if ((i = handle_ansi_color_sequence(dest, src, n))) {
    +->>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs)
    + 			src += i;
    + 			n -= i;
    + 		} else {
    + 			strbuf_addch(dest, '^');
    +-<<<<<<< 1c895d818c (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233))
    + 			strbuf_addch(dest, *src == 0x7f ? '?' : 0x40 + *src);
    +-=======
    +-			strbuf_addch(dest, 0x40 + *src);
    +->>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs)
    + 		}
    + 	}
    + }
    +
    + ## t/meson.build ##
    + remerge CONFLICT (content): Merge conflict in t/meson.build
    + index 6831958738..bd4b2e9c69 100644
    + --- t/meson.build
    + +++ t/meson.build
    +@@ t/meson.build: clar_test_suites = [
    +   'unit-tests/u-list-objects-filter-options.c',
    +   'unit-tests/u-mem-pool.c',
    +   'unit-tests/u-mingw.c',
    +-<<<<<<< 1c895d818c (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233))
    +   'unit-tests/u-odb-inmemory.c',
    +-=======
    +->>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs)
    +   'unit-tests/u-oid-array.c',
    +   'unit-tests/u-oidmap.c',
    +   'unit-tests/u-oidtree.c',
    +
    + ## t/t5409-colorize-remote-messages.sh ##
    + remerge CONFLICT (content): Merge conflict in t/t5409-colorize-remote-messages.sh
    + index 575dd95e87..3010913bb1 100755
    + --- t/t5409-colorize-remote-messages.sh
    + +++ t/t5409-colorize-remote-messages.sh
    +@@ t/t5409-colorize-remote-messages.sh: test_expect_success 'disallow (color) control sequences in sideband' '
    + 	printf "error: Have you \\033[31mread\\033[m this?\\a\\n" >&2
    + 	exec "$@"
    + 	EOF
    +-<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 1c895d818c (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233))
    + 	test_config_global uploadPack.packObjectsHook ./color-me-surprised &&
    +-================================
    +-	test_config_global uploadPack.packObjectshook ./color-me-surprised &&
    +->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs)
    + 	test_commit need-at-least-one-commit &&
    + 
    + 	git clone --no-local . throw-away 2>stderr &&
    +@@ t/t5409-colorize-remote-messages.sh: test_expect_success 'disallow (color) control sequences in sideband' '
    + 	test_file_not_empty actual
    + '
    + 
    +-<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 1c895d818c (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233))
    + test_decode_csi() {
    + 	awk '{
    + 		while (match($0, /\033/) != 0) {
    +@@ t/t5409-colorize-remote-messages.sh: test_expect_success 'allow all control sequences for a specific URL' '
    + 	test_grep ! "\\^\\[\\[K" decoded
    + '
    + 
    +-================================
    +->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs)
    + test_done
    +
    + ## t/t5563-simple-http-auth.sh ##
    + remerge CONFLICT (content): Merge conflict in t/t5563-simple-http-auth.sh
    + index 2bba804342..aba09dccfe 100755
    + --- t/t5563-simple-http-auth.sh
    + +++ t/t5563-simple-http-auth.sh
    +@@ t/t5563-simple-http-auth.sh: test_expect_success 'access using three-legged auth' '
    + 	EOF
    + '
    + 
    +-<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 1c895d818c (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233))
    + test_lazy_prereq SPNEGO 'curl --version | grep -qi "SPNEGO\|GSS-API\|Kerberos\|negotiate"'
    + 
    + test_expect_success SPNEGO 'http.emptyAuth=auto attempts Negotiate before credential_fill' '
    +@@ t/t5563-simple-http-auth.sh: test_expect_success SPNEGO 'http.emptyAuth=false skips Negotiate' '
    + 	test_line_count = 1 actual_401s
    + '
    + 
    +-================================
    +->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs)
    + test_lazy_prereq NTLM 'curl --version | grep -q NTLM'
    + 
    + test_expect_success NTLM 'access using NTLM auth' '
    +
    + ## t/t9200-git-cvsexportcommit.sh ##
    + remerge CONFLICT (content): Merge conflict in t/t9200-git-cvsexportcommit.sh
    + index 80c86633be..e2a86d7a90 100755
    + --- t/t9200-git-cvsexportcommit.sh
    + +++ t/t9200-git-cvsexportcommit.sh
    +@@ t/t9200-git-cvsexportcommit.sh: case "$PWD" in
    + 	;;
    + esac
    + 
    +-<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 1c895d818c (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233))
    + if ! cvs version >/dev/null 2>&1
    +-================================
    +-cvs >/dev/null 2>&1
    +-if test $? -ne 1
    +->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs)
    + then
    +     skip_all='skipping git cvsexportcommit tests, cvs not found'
    +     test_done
    +
    + ## t/test-lib.sh ##
    + remerge CONFLICT (content): Merge conflict in t/test-lib.sh
    + index f036ce0f11..30a1681884 100644
    + --- t/test-lib.sh
    + +++ t/test-lib.sh
    +@@
    + # You should have received a copy of the GNU General Public License
    + # along with this program.  If not, see https://www.gnu.org/licenses/ .
    + 
    +-<<<<<<< 1c895d818c (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233))
    + # Enable the use of errexit so that any unexpected failures will cause us to
    + # abort tests, even when outside of a specific test case.
    + #
    +@@ t/test-lib.sh: case "${GIT_TEST_USE_SET_E:-false}" in
    + 	;;
    + esac
    + 
    +-=======
    +->>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs)
    + # On Unix/Linux, the path separator is the colon, on other systems it
    + # may be different, though. On Windows, for example, it is a semicolon.
    + # If the PATH variable contains semicolons, it is pretty safe to assume

To: c26366f36c (Drop mimalloc (git-for-windows#6231), 2026-05-26) (ba4c40710e..c26366f36c)

Statistics

Metric Count
Total conflicts 2
Skipped (upstreamed) 0
Resolved surgically 2
Range-diff (click to expand)

dscho and others added 30 commits May 27, 2026 09:55
Merge this early to resolve merge conflicts early.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
That option only matters there, and is in fact only really understood in
those builds; UCRT64 versions of GCC, for example, do not know what to
do with that option.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When building with `make MSVC=1 DEBUG=1`, link to `libexpatd.lib`
rather than `libexpat.lib`.

It appears that the `vcpkg` package for "libexpat" has changed and now
creates `libexpatd.lib` for debug mode builds.  Previously, both debug
and release builds created a ".lib" with the same basename.

Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
Start work on a new 'git survey' command to scan the repository
for monorepo performance and scaling problems.  The goal is to
measure the various known "dimensions of scale" and serve as a
foundation for adding additional measurements as we learn more
about Git monorepo scaling problems.

The initial goal is to complement the scanning and analysis performed
by the GO-based 'git-sizer' (https://github.com/github/git-sizer) tool.
It is hoped that by creating a builtin command, we may be able to take
advantage of internal Git data structures and code that is not
accessible from GO to gain further insight into potential scaling
problems.

Co-authored-by: Derrick Stolee <stolee@gmail.com>
Signed-off-by: Jeff Hostetler <git@jeffhostetler.com>
Signed-off-by: Derrick Stolee <stolee@gmail.com>
In bf2d5d8 (Don't let ld strip relocations, 2016-01-16) (picked from
git-for-windows@6a237925bf10),
Git for Windows introduced the `-Wl,-pic-executable` flag, specifying
the exact entry point via `-e`. This required discerning between i686
and x86_64 code because the former required the symbol to be prefixed
with an underscore, the latter did not.

As per https://sourceware.org/bugzilla/show_bug.cgi?id=10865, the
specified symbols are already the default, though.

So let's drop the overly-specific definition.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
By default we will scan all references in "refs/heads/", "refs/tags/"
and "refs/remotes/".

Add command line opts let the use ask for all refs or a subset of them
and to include a detached HEAD.

Signed-off-by: Jeff Hostetler <git@jeffhostetler.com>
Signed-off-by: Derrick Stolee <stolee@gmail.com>
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
MSYS2 already defines a couple of helpful environment variables, and we
can use those to infer the installation location as well as the CPU. No
need for hard-coding ;-)

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Create a wrapper for the Windows Resource Compiler (RC.EXE)
for use by the MSVC=1 builds. This is similar to the CL.EXE
and LIB.EXE wrappers used for the MSVC=1 builds.

Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
When 'git survey' provides information to the user, this will be presented
in one of two formats: plaintext and JSON. The JSON implementation will be
delayed until the functionality is complete for the plaintext format.

The most important parts of the plaintext format are headers specifying the
different sections of the report and tables providing concreted data.

Create a custom table data structure that allows specifying a list of
strings for the row values. When printing the table, check each column for
the maximum width so we can create a table of the correct size from the
start.

The table structure is designed to be flexible to the different kinds of
output that will be implemented in future changes.

Signed-off-by: Derrick Stolee <stolee@gmail.com>
The tell-tale is the presence of the `MSYSTEM` value while compiling, of
course. In that case, we want to ensure that `MSYSTEM` is set when
running `git.exe`, and also enable the magic MSYS2 tty detection.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Teach MSVC=1 builds to depend on the `git.rc` file so that
the resulting executables have Windows-style resources and
version number information within them.

Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
This compile-time option allows to ask Git to load libcurl dynamically
at runtime.

Together with a follow-up patch that optionally overrides the file name
depending on the `http.sslBackend` setting, this kicks open the door for
installing multiple libcurl flavors side by side, and load the one
corresponding to the (runtime-)configured SSL/TLS backend.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
At the moment, nothing is obvious about the reason for the use of the
path-walk API, but this will become more prevelant in future iterations. For
now, use the path-walk API to sum up the counts of each kind of object.

For example, this is the reachable object summary output for my local repo:

REACHABLE OBJECT SUMMARY
========================
Object Type |  Count
------------+-------
       Tags |   1343
    Commits | 179344
      Trees | 314350
      Blobs | 184030

Signed-off-by: Derrick Stolee <stolee@gmail.com>
MSYS2 defines some helpful environment variables, e.g. `MSYSTEM`. There
is code in Git for Windows to ensure that that `MSYSTEM` variable is
set, hard-coding a default.

However, the existing solution jumps through hoops to reconstruct the
proper default, and is even incomplete doing so, as we found out when we
extended it to support CLANGARM64.

This is absolutely unnecessary because there is already a perfectly
valid `MSYSTEM` value we can use at build time. This is even true when
building the MINGW32 variant on a MINGW64 system because `makepkg-mingw`
will override the `MSYSTEM` value as per the `MINGW_ARCH` array.

The same is equally true for the `/mingw64`, `/mingw32` and
`/clangarm64` prefix: those values are already available via the
`MINGW_PREFIX` environment variable, and we just need to pass that
setting through.

Only when `MINGW_PREFIX` is not set (as is the case in Git for Windows'
minimal SDK, where only `MSYSTEM` is guaranteed to be set correctly), we
use as fall-back the top-level directory whose name is the down-cased
value of the `MSYSTEM` variable.

Incidentally, this also broadens the support to all the configurations
supported by the MSYS2 project, i.e. clang64 & ucrt64, too.

Note: This keeps the same, hard-coded MSYSTEM platform support for CMake
as before, but drops it for Meson (because it is unclear how Meson could
do this in a more flexible manner).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
A change between versions 2.4.1 and 2.6.0 of the MSYS2 runtime modified
how Cygwin's runtime (and hence Git for Windows' MSYS2 runtime
derivative) handles locales: d16a56306d (Consolidate wctomb/mbtowc calls
for POSIX-1.2008, 2016-07-20).

An unintended side-effect is that "cold-calling" into the POSIX
emulation will start with a locale based on the current code page,
something that Git for Windows is very ill-prepared for, as it expects
to be able to pass a command-line containing non-ASCII characters to the
shell without having those characters munged.

One symptom of this behavior: when `git clone` or `git fetch` shell out
to call `git-upload-pack` with a path that contains non-ASCII
characters, the shell tried to interpret the entire command-line
(including command-line parameters) as executable path, which obviously
must fail.

This fixes git-for-windows#1036

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Ignore the `-fno-stack-protector` compiler argument when building
with MSVC.  This will be used in a later commit that needs to build
a Win32 GUI app.

Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
This implements the Windows-specific support code, because everything is
slightly different on Windows, even loading shared libraries.

Note: I specifically do _not_ use the code from
`compat/win32/lazyload.h` here because that code is optimized for
loading individual functions from various system DLLs, while we
specifically want to load _many_ functions from _one_ DLL here, and
distinctly not a system DLL (we expect libcurl to be located outside
`C:\Windows\system32`, something `INIT_PROC_ADDR` refuses to work with).
Also, the `curl_easy_getinfo()`/`curl_easy_setopt()` functions are
declared as vararg functions, which `lazyload.h` cannot handle. Finally,
we are about to optionally override the exact file name that is to be
loaded, which is a goal contrary to `lazyload.h`'s design.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Now that we have explored objects by count, we can expand that a bit more to
summarize the data for the on-disk and inflated size of those objects. This
information is helpful for diagnosing both why disk space (and perhaps
clone or fetch times) is growing but also why certain operations are slow
because the inflated size of the abstract objects that must be processed is
so large.

Note: zlib-ng is slightly more efficient even at those small sizes. Even
between zlib versions, there are slight differences in compression. To
accommodate for that in the tests, not the exact numbers but some rough
approximations are validated (the test should validate `git survey`,
after all, not zlib).

Signed-off-by: Derrick Stolee <stolee@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Special-casing even more configurations simply does not make sense.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Git for Windows wants to add `git.exe` to the users' `PATH`, without
cluttering the latter with unnecessary executables such as `wish.exe`.
To that end, it invented the concept of its "Git wrapper", i.e. a tiny
executable located in `C:\Program Files\Git\cmd\git.exe` (originally a
CMD script) whose sole purpose is to set up a couple of environment
variables and then spawn the _actual_ `git.exe` (which nowadays lives in
`C:\Program Files\Git\mingw64\bin\git.exe` for 64-bit, and the obvious
equivalent for 32-bit installations).

Currently, the following environment variables are set unless already
initialized:

- `MSYSTEM`, to make sure that the MSYS2 Bash and the MSYS2 Perl
  interpreter behave as expected, and

- `PLINK_PROTOCOL`, to force PuTTY's `plink.exe` to use the SSH
  protocol instead of Telnet,

- `PATH`, to make sure that the `bin` folder in the user's home
  directory, as well as the `/mingw64/bin` and the `/usr/bin`
  directories are included. The trick here is that the `/mingw64/bin/`
  and `/usr/bin/` directories are relative to the top-level installation
  directory of Git for Windows (which the included Bash interprets as
  `/`, i.e. as the MSYS pseudo root directory).

Using the absence of `MSYSTEM` as a tell-tale, we can detect in
`git.exe` whether these environment variables have been initialized
properly. Therefore we can call `C:\Program Files\Git\mingw64\bin\git`
in-place after this change, without having to call Git through the Git
wrapper.

Obviously, above-mentioned directories must be _prepended_ to the `PATH`
variable, otherwise we risk picking up executables from unrelated Git
installations. We do that by constructing the new `PATH` value from
scratch, appending `$HOME/bin` (if `HOME` is set), then the MSYS2 system
directories, and then appending the original `PATH`.

Side note: this modification of the `PATH` variable is independent of
the modification necessary to reach the executables and scripts in
`/mingw64/libexec/git-core/`, i.e. the `GIT_EXEC_PATH`. That
modification is still performed by Git, elsewhere, long after making the
changes described above.

While we _still_ cannot simply hard-link `mingw64\bin\git.exe` to `cmd`
(because the former depends on a couple of `.dll` files that are only in
`mingw64\bin`, i.e. calling `...\cmd\git.exe` would fail to load due to
missing dependencies), at least we can now avoid that extra process of
running the Git wrapper (which then has to wait for the spawned
`git.exe` to finish) by calling `...\mingw64\bin\git.exe` directly, via
its absolute path.

Testing this is in Git's test suite tricky: we set up a "new" MSYS
pseudo-root and copy the `git.exe` file into the appropriate location,
then verify that `MSYSTEM` is set properly, and also that the `PATH` is
modified so that scripts can be found in `$HOME/bin`, `/mingw64/bin/`
and `/usr/bin/`.

This addresses git-for-windows#2283

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Move the default `-ENTRY` and `-SUBSYSTEM` arguments for
MSVC=1 builds from `config.mak.uname` into `clink.pl`.
These args are constant for console-mode executables.

Add support to `clink.pl` for generating a Win32 GUI application
using the `-mwindows` argument (to match how GCC does it).  This
changes the `-ENTRY` and `-SUBSYSTEM` arguments accordingly.

Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
The previous commits introduced a compile-time option to load libcurl
lazily, but it uses the hard-coded name "libcurl-4.dll" (or equivalent
on platforms other than Windows).

To allow for installing multiple libcurl flavors side by side, where
each supports one specific SSL/TLS backend, let's first look whether
`libcurl-<backend>-4.dll` exists, and only use `libcurl-4.dll` as a fall
back.

That will allow us to ship with a libcurl by default that only supports
the Secure Channel backend for the `https://` protocol. This libcurl
won't suffer from any dependency problem when upgrading OpenSSL to a new
major version (which will change the DLL name, and hence break every
program and library that depends on it).

This is crucial because Git for Windows relies on libcurl to keep
working when building and deploying a new OpenSSL package because that
library is used by `git fetch` and `git clone`.

Note that this feature is by no means specific to Windows. On Ubuntu,
for example, a `git` built using `LAZY_LOAD_LIBCURL` will use
`libcurl.so.4` for `http.sslbackend=openssl` and `libcurl-gnutls.so.4`
for `http.sslbackend=gnutls`.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Derrick Stolee <stolee@gmail.com>
In the case of Git for Windows (say, in a Git Bash window) running in a
Windows Subsystem for Linux (WSL) directory, the GetNamedSecurityInfoW()
call in is_path_owned_By_current_side() returns an error code other than
ERROR_SUCCESS. This is consistent behavior across this boundary.

In these cases, the owner would always be different because the WSL
owner is a different entity than the Windows user.

The change here is to suppress the error message that looks like this:

  error: failed to get owner for '//wsl.localhost/...' (1)

Before this change, this warning happens for every Git command,
regardless of whether the directory is marked with safe.directory.

Signed-off-by: Derrick Stolee <derrickstolee@github.com>
For Windows builds >= 15063 set $env:TERM to "xterm-256color" instead of
"cygwin" because they have a more capable console system that supports
this. Also set $env:COLORTERM="truecolor" if unset.

$env:TERM is initialized so that ANSI colors in color.c work, see
29a3963 (Win32: patch Windows environment on startup, 2012-01-15).

See git-for-windows#3629 regarding problems caused by always setting
$env:TERM="cygwin".

This is the same heuristic used by the Cygwin runtime.

Signed-off-by: Rafael Kitover <rkitover@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
NtQueryObject under Wine can return a success but fill out no name.
In those situations, Wine will set Buffer to NULL, and set result to
the sizeof(OBJECT_NAME_INFORMATION).

Running a command such as

echo "$(git.exe --version 2>/dev/null)"

will crash due to a NULL pointer dereference when the code attempts to
null terminate the buffer, although, weirdly, removing the subshell or
redirecting stdout to a file will not trigger the crash.

Code has been added to also check Buffer and Length to ensure the check
is as robust as possible due to the current behavior being fragile at
best, and could potentially change in the future

This code is based on the behavior of NtQueryObject under wine and
reactos.

Signed-off-by: Christopher Degawa <ccom@randomderp.com>
Atomic append on windows is only supported on local disk files, and it may
cause errors in other situations, e.g. network file system. If that is the
case, this config option should be used to turn atomic append off.

Co-Authored-By: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: 孙卓识 <sunzhuoshi@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
From the documentation of said setting:

	This boolean will enable fsync() when writing object files.

	This is a total waste of time and effort on a filesystem that
	orders data writes properly, but can be useful for filesystems
	that do not use journalling (traditional UNIX filesystems) or
	that only journal metadata and not file contents (OS X’s HFS+,
	or Linux ext3 with "data=writeback").

The most common file system on Windows (NTFS) does not guarantee that
order, therefore a sudden loss of power (or any other event causing an
unclean shutdown) would cause corrupt files (i.e. files filled with
NULs). Therefore we need to change the default.

Note that the documentation makes it sound as if this causes really bad
performance. In reality, writing loose objects is something that is done
only rarely, and only a handful of files at a time.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Whith Windows 2000, Microsoft introduced a flag to the PE header to mark executables as
"terminal server aware". Windows terminal servers provide a redirected Windows directory and
redirected registry hives when launching legacy applications without this flag set. Since we
do not use any INI files in the Windows directory and don't write to the registry, we don't
need  this additional preparation. Telling the OS that we don't need this should provide
slightly improved startup times in terminal server environments.

When building for supported Windows Versions with MSVC the /TSAWARE linker flag is
automatically set, but MinGW requires us to set the --tsaware flag manually.

This partially addresses git-for-windows#3935.

Signed-off-by: Matthias Aßhauer <mha1993@live.de>
dscho and others added 30 commits May 27, 2026 09:57
This is the recommended way on GitHub to describe policies revolving around
security issues and about supported versions.

Helped-by: Sven Strickroth <email@cs-ware.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In this time and age, AI is everywhere. However, it's sometimes not very
easy to use. For green-field projects it works quite a bit better than
for existing legacy projects. And Git's source code is _quite_ as legacy
code as they come... 😁

Now, the only way how AI can be used efficiently with legacy code
is by providing enough information by way of prompt context for the
AI to have a chance to make any sense of the code. The structure and
the architecture is, after all, not designed for AI, but rather the
opposite: By virtue of having grown organically over two decades, there
is no design that AI coding models would readily grasp.

So here is a document that describes all kinds of aspects about this
project. The idea is to help AI by providing information that it does
not have ingrained in its weights. The idea is to provide information
that a human prompter might take for granted, but no coding model will
have been trained on specifically.

Assisted-by: Claude Opus 4.5
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
…opment

This adds an extensive section about resolving merge conflicts during
rebases, which happens quite often in Git for Windows' day-to-day.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
A fix for calling `vim` in Windows Terminal caused a regression and was
reverted. We partially un-revert this, to get the fix again.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
…opment

AGENTS.md: add upstream contribution and worktree guidance

Add sections covering the GitGitGadget workflow for contributing to
upstream Git, commit message conventions specific to the upstream
project, how to manage patch series with dependencies (branch
thickets), effective worktree usage including --update-refs for
history rewrites, and techniques for analyzing merge-structured
topic branches with git replay.

These learnings come from a session contributing the
safe.bareRepository test preparation patches via GitGitGadget.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Assisted-by: Claude Opus 4.6
This topic branch re-adds the deprecated --stdin/-z options to `git
reset`. Those patches were overridden by a different set of options in
the upstream Git project before we could propose `--stdin`.

We offered this in MinGit to applications that wanted a safer way to
pass lots of pathspecs to Git, and these applications will need to be
adjusted.

Instead of `--stdin`, `--pathspec-from-file=-` should be used, and
instead of `-z`, `--pathspec-file-nul`.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
…opment

AGENTS.md: document rebase, staging, and log -L tricks for AI agents

Add practical recipes for three workflows that are particularly useful
when AI agents work with Git:

Non-interactive "interactive" rebases using `sed -i 1ib` as a sequence
editor to insert a `break` command, then editing the todo file directly
via the path from `git rev-parse --git-path rebase-merge/git-rebase-todo`.
This avoids the impossible task of driving an interactive editor from an
AI agent.

Scripted hunk staging via `printf '%s\n' s y q | git add -p`, which
feeds predictable keystrokes to the add-patch protocol to stage
individual hunks without human interaction.

The `git log -L <start>,+<count>:<file>` trick for finding which commit
last touched specific lines, enabling an `hg absorb`-like workflow where
the agent can identify the right fixup! target surgically rather than
grepping through full diffs.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Assisted-by: Claude Opus 4.6
Originally introduced as `core.useBuiltinFSMonitor` in Git for Windows
and developed, improved and stabilized there, the built-in FSMonitor
only made it into upstream Git (after unnecessarily long hemming and
hawing and throwing overly perfectionist style review sticks into the
spokes) as `core.fsmonitor = true`.

In Git for Windows, with this topic branch, we re-introduce the
now-obsolete config setting, with warnings suggesting to existing users
how to switch to the new config setting, with the intention to
ultimately drop the patch at some stage.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
…opment

AGENTS.md: add pre-commit checklist for lint checks

Bundle the existing ASCII-only, 80-column, and whitespace validation
recipes into a "pre-commit checklist" block that agents should run
before every commit. The individual recipes already existed in the
Coding Conventions section but were presented as reference material
rather than as an actionable workflow step.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Assisted-by: Claude Opus 4.6
…updates

Start monitoring updates of Git for Windows' component in the open
This was marked as a temporary work-around in 4538ee6 (ci: work
around a problem with HTTP/2 vs libcurl v8.10.0 (git-for-windows#5165), 2024-09-24), to
help CI builds pass even on macOS. The faulty libcurl version has hence
been replaced with plenty of fixed ones, therefore this work-around is
no longer necessary.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
…opment

AGENTS: document learnings from split-index + fsmonitor investigation

While investigating a CI failure in the `linux-TEST-vars` job caused by
the interaction between the `pt/fsmonitor-linux` and
`hn/git-checkout-m-with-stash` topics in `seen`, several debugging
techniques proved essential and were not previously documented.

The investigation required bisecting the first-parent history of `seen`
while temporarily merging the fsmonitor topic at each step. This
revealed that `GIT_TEST_SPLIT_INDEX=yes` corrupts the bisect
machinery's own index operations unless it is unset before cleanup
checkouts. It also revealed that `fprintf(stderr, ...)` instrumentation
in Git's C code is swallowed by the test framework, making Trace2 the
correct instrumentation approach.

A key insight was that the bug appeared Linux-specific only because
`linux-TEST-vars` is the sole CI job setting `GIT_TEST_SPLIT_INDEX=yes`;
there is no macOS or Windows equivalent. The actual root cause (the
`index.skipHash=true` + split-index interaction producing a null
`base_oid` in the shared index) is platform-independent.

Add four documentation sections capturing these learnings: bisecting
`seen` interactions, reproducing with exact CI variables, verifying CI
platform coverage before concluding platform-specificity, and using
Trace2 for instrumentation inside the test framework.

Assisted-by: Claude Opus 4.6
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add a README.md for GitHub goodness.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This was a preparatory commit for the path-walk API, which has since
been upstreamed into v2.54.0. During the merging-rebase, the code
changes this commit introduced were already present in the new base,
leaving it empty. Drop it.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
…it-for-windows#6198)

AI-assisted contributions are a reality of open source in 2025 and
beyond. Contributors will use AI tools, and that includes the
maintainers themselves. Over recent months, I have found AI increasingly
useful for the kind of menial, tedious work that does not require much
creativity but is highly boring when done by hand: resolving merge
conflicts during merging-rebases, chasing down CI failures across
platforms, adapting downstream patches to upstream API changes.

To that end, I would like to have an `AGENTS.md` file in the code base
that helps any LLM to understand the context of the project.

A secondary goal of this is to preemptively help outside contributors.
The risk is not AI usage per se, but low-quality AI slop: contributions
where the human hits "accept" without sufficient context being available
to the model (and without proper review by the human, we've all been
there), resulting in changes that miss conventions, break patterns, or
misunderstand the project's architecture. Git's source code is about as
legacy as they come, having grown organically over two decades with no
design that AI coding models would readily grasp from a narrow code
sample alone.

This `AGENTS.md` is designed to raise the floor on AI-assisted
contributions by providing enough context that even when a human
contributor fails to steer carefully, the model has the information it
needs to produce something reasonable. It documents the repository
structure, build process, test conventions, the object model and ODB
internals, debugging techniques (Trace2, instrumenting tests, bisecting
failures), the merging-rebase workflow, conflict resolution patterns,
coding conventions (ASCII only, 80 columns, tabs), commit message
expectations, and the GitGitGadget contribution workflow. This is
information that a human might take for granted, but no coding model
will have been trained on specifically.

Similar `AGENTS.md` files have recently been added to other repositories
in the Git for Windows project:
[MINGW-packages](git-for-windows/MINGW-packages#194),
[git-for-windows.github.io](git-for-windows/git-for-windows.github.io#88)
and
[msys2-runtime](git-for-windows/msys2-runtime@1e0ff37).
…erver

Bump actions/checkout from v5 to v6 and
git-for-windows/setup-git-for-windows-sdk from v1 to v2.

Both bumps are Node.js 20 to Node.js 24 runtime migrations with
no functional changes to the actions themselves. checkout v6 moves
persisted credentials to `` instead of `.git/config`,
which does not affect this workflow since no subsequent steps rely
on the credential location. The setup-sdk v2 provisions the same
minimal SDK as v1.

Risk: very low. The only precondition is a recent Actions Runner,
which github.com-hosted runners already satisfy.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Over time, as upstream Git absorbs fixes and features that originated in
or were carried by Git for Windows, downstream patches accumulate that
are no longer needed. The steady stream of merged PRs makes this
virtually inevitable. This PR collects fixup! commits to drop three such
patches during the next autosquash rebase.

The HTTP/2 workaround in `t5551` was a temporary fix for a libcurl
v8.10.0 regression on macOS CI runners. The faulty libcurl has long been
superseded by fixed versions, making it unnecessary.

The `unix-socket: avoid leak when initialization fails` patch changed
`return -1` to `goto fail` in `unix_stream_connect()` so cleanup would
run when `unix_sockaddr_init()` failed. Upstream fixed the same leak
more surgically in c5fe29f (unix-socket: fix memory leak when
chdir(3p) fails, 2025-01-30) by having `unix_sockaddr_init()` call
`FREE_AND_NULL(ctx->orig_dir)` before returning, making the downstream
caller-side fix redundant.

The `revision: create mark_trees_uninteresting_dense()` commit was a
preparatory patch for the path-walk API. That API has since been
upstreamed, and this commit became empty during the merging-rebase
because its changes were already in the new base.
When building with `make DEVELOPER=1` we explicitly pass "-std=gnu99" to
the compiler so that we don't start leaning on features exposed by more
recent versions of the C standard. Unfortunately though, glibc 2.43
started to use type-generic expressions. This works alright with GCC,
but when compiling with Clang this leads to errors:

  $ make DEVELOPER=1 CC=clang
  CC daemon.o
  In file included from daemon.c:3:
  ./git-compat-util.h:344:11: error: '_Generic' is a C11 extension [-Werror,-Wc11-extensions]
    344 |         return !!strchr(path, '/');
        |                  ^
  /usr/include/string.h:265:3: note: expanded from macro 'strchr'
    265 |   __glibc_const_generic (S, const char *, strchr (S, C))
        |   ^
  /usr/include/x86_64-linux-gnu/sys/cdefs.h:838:3: note: expanded from macro '__glibc_const_generic'
    838 |   _Generic (0 ? (PTR) : (void *) 1,                     \
        |   ^

In theory, the `__glibc_const_generic` macro does have feature gating:

  #if !defined __cplusplus \
      && (__GNUC_PREREQ (4, 9) \
          || __glibc_has_extension (c_generic_selections) \
          || (!defined __GNUC__ && defined __STDC_VERSION__ \
              && __STDC_VERSION__ >= 201112L))
  # define __HAVE_GENERIC_SELECTION 1
  #else
  # define __HAVE_GENERIC_SELECTION 0
  #endif

But this feature gating isn't effective because `_has_extension()` will
always evaluate to true as C generics _are_ available as a language
extension to GNU C99 when using Clang. This would have been different if
`_has_feature()` was used instead, in which case it would have properly
evaluated to `false`.

Unfortunately, there is no easy way for us to work around the warning.
We cannot define `__HAVE_GENERIC_SELECTION` ourselves as that would lead
to a redefinition, and given that the conditions are or'd together we
cannot disable any of those, either.

Instead, work around the issue by not using -std=gnu99 with Clang when
using the Makefile and by disabling warnings about C11 extensions when
using Meson. This isn't ideal, but we at least retain the ability to
detect the (mis-)use of features from newer standards with GCC.

An alternative to this might be to simply bump the required C standard
to C11, which is 15 years old by now and should have support on most
platforms out there. But some more esoteric platforms may not have it.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
…windows#6220)

This includes gitgitgadget#2097 and a
`fixup!` for a workflow that is not upstream (Nano Server).
…indows#6233)

The `linux-{asan-ubsan,sha256,reftable}` jobs run inside
`ubuntu:rolling`, which now resolves to Ubuntu 26.04 with glibc 2.43;
that pulls `_Generic` into `<sys/cdefs.h>` and breaks our `-std=gnu99
-Werror` Clang builds. Concrete failure:
https://github.com/git-for-windows/git/actions/runs/25390480083/job/74463338845.

Picking up Patrick Steinhardt's fix from
https://lore.kernel.org/git/20260505-b4-pks-ci-tolerate-glibc-generic-v1-1-5786386fe512@pks.im/
ahead of its upstream merge so the GfW CI goes green again. The diff
conflicts with `fe5704a3695c "mimalloc: offer a build-time option to
enable it"`, which wraps the affected `config.mak.dev` block in `ifndef
USE_MIMALLOC`; the resolution preserves that wrap on the `gcc6`-only
branch surviving Patrick's patch. `meson.build` auto-merged.
…-for-windows#6232)

This closes two gaps in the current `AGENTS.md` that came up while
drafting git-for-windows#6231 and git-for-windows#2104:

1. The `Fixup Commits` section only covered `fixup!`. `amend!` has
different semantics (replaces the target's commit message and combines
diffs to produce any final state), and the "amend! whose body is the
upstream commit and whose diff aligns the squashed result with that
upstream commit" pattern is precisely how the first commit of git-for-windows#6231
anticipates the in-flight nedmalloc removal in `seen` as `e576abb9f8`.
That pattern is undocumented today.

2. There is no top-level "Contributing to Git for Windows" section, only
"Contributing to Upstream Git via GitGitGadget". The cross-fork `gh pr
create` invocation, the conditions under which a PR is naturally a
fixup/amend-only series against existing thicket commits, and the
upstream-aligning `amend!` shape were all things I inferred from context
rather than the guide.

Add subsections that cover those gaps. Nothing in the existing text
changes.
mingw: stop using nedmalloc

The vendored nedmalloc allocator under compat/nedmalloc/ has been
unmaintained upstream for a very long time: the original repository at
https://github.com/ned14/nedmalloc received its last commit on July 5,
2014, and was archived (made read-only) by its owner on March 15, 2019.
Our copy has been carried forward unchanged ever since.

The Git for Windows commit that introduced mimalloc as a replacement
on Windows ("mingw: use mimalloc", 2019-06-24, present in the Git for
Windows branch thicket but not upstream) already observed at that time
that nedmalloc had ceased to see any updates for several years.

This came to a head when the Git for Windows SDK upgraded to GCC 16:
the `add_segment()` function in `compat/nedmalloc/malloc.c.h` declares
`int nfences = 0` and only references it inside an `assert()`, which
GCC 16 now flags as `-Wunused-but-set-variable`. Combined with the
`-Werror` enabled by `DEVELOPER=1`, this turns into a hard build
failure:

	compat/nedmalloc/malloc.c.h: In function 'add_segment':
	compat/nedmalloc/malloc.c.h:3897:7: error: variable 'nfences' set but not used [-Werror=unused-but-set-variable=]
	 3897 |   int nfences = 0;
	      |       ^~~~~~~
	cc1.exe: all warnings being treated as errors

The same source built without complaint under GCC 15.2.0; the
regression was bisected to the SDK package update at
git-for-windows/git-sdk-64@188d93dd455
(`mingw-w64-x86_64-gcc 15.2.0-14 -> 16.1.0-1`), with the failing CI
run captured at
https://github.com/git-for-windows/git-sdk-64/actions/runs/25244795074.

Rather than patch the unmaintained vendored sources to silence the
warning, stop opting into nedmalloc altogether on MINGW. The platform
allocator is what every non-MINGW build already uses, and a fresh
build of git.git's master against a minimal Git for Windows SDK
upgraded to GCC 16, with `USE_NED_ALLOCATOR` removed from the MINGW
section, completes successfully.

The compat/nedmalloc/ subtree itself is left in place to keep this
change minimal; nothing in the build links against it any longer, so
it can be removed in a follow-up if desired.

Assisted-by: Claude Opus 4.7
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Re-running the `git repack -adfq` benchmark from
6a29c2d ("mingw: use mimalloc",
2019-06-24) against the platform's *current* default allocator (so
without `nedmalloc` in the picture at all) shows mimalloc is no longer
faster than the system allocator on any of Windows, macOS, or Linux,
neither for the original ~30-second `linux v2.6.20` workload nor for a
4x larger `linux v3.0` workload where each individual run takes ~2
minutes (and the noise floor on Linux is below 0.3% of the mean, so
even small differences would be visible if any existed).

`mimalloc` was originally chosen over nedmalloc, not over the system
allocator. Six years on, with nedmalloc now being dropped from the
codebase entirely, the allocator that mimalloc has to beat is whatever
the OS ships by default; modern Windows segment-heap, glibc malloc, and
the macOS libsystem allocator have all closed the gap, and there is no
longer a measurable benefit to keep maintaining a custom allocator.

The actual benchmark methodology, the per-platform numbers, and links
to the workflow runs that produced them are spelled out in the PR
description rather than repeated across each fixup.

The `fixup!` subject is so that the next rebase against an upstream
Git that already lacks this commit will autosquash this revert into
the original (which becomes empty and is dropped), leaving the tree
free of `mimalloc`.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Part of the series that drops the vendored `mimalloc` from this fork;
the rationale (no measurable speedup over the platform allocator on
any of Windows, macOS, or Linux) is in the second commit of the
series and the PR description. The `fixup!` subject is so the next
rebase against an upstream Git that already lacks the target commit
autosquashes this revert into it, dropping the original cleanly.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Part of the series that drops the vendored `mimalloc` from this fork;
the rationale (no measurable speedup over the platform allocator on
any of Windows, macOS, or Linux) is in the second commit of the
series and the PR description. The `fixup!` subject is so the next
rebase against an upstream Git that already lacks the target commit
autosquashes this revert into it, dropping the original cleanly.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Part of the series that drops the vendored `mimalloc` from this fork;
the rationale (no measurable speedup over the platform allocator on
any of Windows, macOS, or Linux) is in the second commit of the
series and the PR description. The `fixup!` subject is so the next
rebase against an upstream Git that already lacks the target commit
autosquashes this revert into it, dropping the original cleanly.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Part of the series that drops the vendored `mimalloc` from this fork;
the rationale (no measurable speedup over the platform allocator on
any of Windows, macOS, or Linux) is in the second commit of the
series and the PR description. The original commit was a preparation
step for vendoring `mimalloc` in (which forces C11 mode under
mingw-w64 GCC and so implicitly links libwinpthread, clashing with
Git's own emulation). With `mimalloc` gone the rename is no longer
needed, so this revert restores the plain `pthread_create` /
`pthread_self` names. The `fixup!` subject is so the next rebase
against an upstream Git that already lacks the target commit
autosquashes this revert into it, dropping the original cleanly.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When 6a29c2d ("mingw: use mimalloc",
2019-06-24) introduced the vendored mimalloc, the comparison was against
`nedmalloc` (which by then had not seen an upstream commit since 2014,
and whose repository was archived in 2019). The two were essentially at
parity in that benchmark; mimalloc was chosen because it was actively
developed. I do not really recall whether the platform's *default*
allocator was not part of the comparison; If it was, the performance was
still worse than mimalloc, if it wasn't, I forgot to test ;-)

Six years on, with `nedmalloc` safely on its way to being dropped from
the upstream codebase entirely
(gitgitgadget#2104, currently in `seen` as
e576abb), the question is no longer "mimalloc vs nedmalloc" but
"mimalloc vs the OS allocator". Re-running the same `git repack -adfq`
benchmark against each platform's current default allocator finds no
measurable speedup from mimalloc on any of Windows, macOS, or Linux.

## Methods

I recapitulated the same benchmark as cited in 6a29c2d (the original
comparison was nedmalloc vs mimalloc on `git repack -adfq` over a subset
of `linux.git`), now extended to the three GitHub-hosted runners
(`ubuntu-latest`, `macos-latest`, `windows-latest`). Each job built two
`git` binaries from the same source tree, vanilla and
`USE_MIMALLOC=YesPlease`, then prepared a fresh bare clone of
`linux.git` to a fixed `SHA`, and ran the repacks with both built `git`s
in randomized order for five iterations. Each iteration ran both
binaries exactly once on a freshly `copytree`-ed copy of the immutable
template repository; the order *within* an iteration was randomized so
any per-iteration confounder (cache state, runner warm-up, neighbour-VM
contention) would be shared symmetrically between variants. Timings
excluded the `copytree`. The full driver is the Python script
`ci/bench-mimalloc.py` on the [`mimalloc-benchmark`
branch](https://github.com/dscho/git/tree/mimalloc-benchmark/ci).

## Results: original `linux v2.6.20`-era workload (49,917 commits,
431,605 objects, ~204 MB pack)

| Platform | vanilla mean ± stdev | mimalloc mean ± stdev | Δ (mimalloc
− vanilla) |
|---|---|---|---|
| `ubuntu-latest` | 27.089s ± 0.060s | 27.041s ± 0.065s | −0.048s
(−0.18%) |
| `macos-latest` | 23.259s ± 1.206s | 25.076s ± 2.279s | +1.817s (+7.8%)
|
| `windows-latest` | 29.828s ± 1.651s | 30.329s ± 2.428s | +0.501s
(+1.7%) |

Workflow run: https://github.com/dscho/git/actions/runs/25374127848

## Results: 4x larger `linux v3.0` workload (255,039 commits, 2,059,429
objects, ~788 MB pack)

| Platform | vanilla mean ± stdev | mimalloc mean ± stdev | Δ (mimalloc
− vanilla) |
|---|---|---|---|
| `ubuntu-latest` | 134.723s ± **0.329s** | 134.801s ± **0.191s** |
+0.078s (+0.06%) |
| `macos-latest` | 130.183s ± 19.098s | 133.292s ± 18.991s | +3.109s
(+2.4%) |
| `windows-latest` | 145.183s ± 1.272s | 146.271s ± 4.161s | +1.088s
(+0.75%) |

Workflow run: https://github.com/dscho/git/actions/runs/25376885309

## Discussion

The Linux numbers on the larger workload are particularly clear: stdev
is below 0.3% of the mean for both variants, and the difference is well
inside that floor. Glibc's allocator and the vendored mimalloc are
statistically indistinguishable for `git repack -adfq` here.

`windows-latest` runners are noisier (per-run variance ~1-4%, mostly
neighbour-VM scheduling), but mimalloc never beats vanilla in either
workload. With the original justification for keeping a custom allocator
gone (the modern Windows segment-heap is no longer the slow
Windows-XP-era `HeapAlloc` that drove the original 2009 nedmalloc
adoption), there is nothing left to motivate the maintenance cost of a
vendored allocator.

`macos-latest` is too noisy at n=5 (stdev 14% of the mean) to draw a
firm conclusion, but the visible point-estimate goes the wrong way and
there is no plausible mechanism by which Apple's `libsystem_malloc`
would be slower than mimalloc.

## What this PR does *not* do

It does not by itself remove `nedmalloc` from the tree; that is still
promised as a follow-up of the in-flight upstream patch
gitgitgadget#2104, presently in `seen` as
e576abb. The first commit here is an `amend!` whose autosquashed
result is byte-identical to that upstream commit, so once the next
merging-rebase picks up the upstream patch the two will collapse
cleanly.

The five remaining `fixup!` reverts target each of the original
mimalloc-vendoring commits in reverse chronological order; once
autosquashed, the pairs cancel out to empty commits which the rebase
will drop, leaving the tree free of `compat/mimalloc/`, the
`USE_MIMALLOC` build infrastructure, and the supporting changes
(`compat/posix.h` `_DEFAULT_SOURCE` guard, `win32_pthread_*` renames)
that only existed to support the vendored allocator.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.