git/connect.c, branch jch

transport-helper, connect: use clean_on_exit to reap children on abnormal exit

2026-03-12T21:51:50Z

When a long-running service (e.g., a source indexer) runs as PID 1 inside a container and repeatedly spawns git, git may in turn spawn child processes such as git-remote-https or ssh. If git exits abnormally (e.g., via exit(128) on a transport error), the normal cleanup paths (disconnect_helper, finish_connect) are bypassed, and these children are never waited on. The children are reparented to PID 1, which does not reap them, so they accumulate as zombies over time. Set clean_on_exit and wait_after_clean on child_process structs in both transport-helper.c and connect.c so that the existing run-command cleanup infrastructure handles reaping on any exit path. This avoids rolling custom atexit handlers that call finish_command(), which could deadlock if the child is blocked waiting for the parent to close a pipe. The clean_on_exit mechanism sends SIGTERM first, then waits, ensuring the child terminates promptly. It also handles signal-based exits, not just atexit. Signed-off-by: Andrew Au Signed-off-by: Junio C Hamano

promisor-remote: change promisor_remote_reply()'s signature

2026-02-17T19:46:41Z

The `promisor_remote_reply()` function performs two tasks: 1. It uses filter_promisor_remote() to parse the server's "promisor-remote" advertisement and to mark accepted remotes in the repository configuration. 2. It assembles a reply string containing the accepted remote names to send back to the server. In a following commit, the fetch-pack logic will need to trigger the side effect (1) to ensure the repository state is correct, but it will not need to send a reply (2). To avoid assembling a reply string when it is not needed, let's change the signature of promisor_remote_reply(). It will now return `void` and accept a second `char **accepted_out` argument. Only if that argument is not NULL will a reply string be assembled and returned back to the caller via that argument. Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano

connect: plug protocol capability leak

2025-12-08T22:11:42Z

When pushing to a set of remotes using a nickname for the group, the client initializes the connection to each remote, talks to the remote and reads and parses capabilities line, and holds the capabilities in a file-scope static variable server_capabilities_v1. There are a few other such file-scope static variables, and these connections cannot be parallelized until they are refactored to a structure that keeps track of active connections. Which is *not* the theme of this patch ;-) For a single connection, the server_capabilities_v1 variable is initialized to NULL (at the program initialization), populated when we talk to the other side, used to look up capabilities of the other side possibly multiple times, and the memory is held by the variable until program exit, without leaking. When talking to multiple remotes, however, the server capabilities from the second connection overwrites without freeing the one from the first connection, which leaks. ==1080970==ERROR: LeakSanitizer: detected memory leaks Direct leak of 421 byte(s) in 2 object(s) allocated from: #0 0x5615305f849e in strdup (/home/gitster/g/git-jch/bin/bin/git+0x2b349e) (BuildId: 54d149994c9e85374831958f694bd0aa3b8b1e26) #1 0x561530e76cc4 in xstrdup /home/gitster/w/build/wrapper.c:43:14 #2 0x5615309cd7fa in process_capabilities /home/gitster/w/build/connect.c:243:27 #3 0x5615309cd502 in get_remote_heads /home/gitster/w/build/connect.c:366:4 #4 0x561530e2cb0b in handshake /home/gitster/w/build/transport.c:372:3 #5 0x561530e29ed7 in get_refs_via_connect /home/gitster/w/build/transport.c:398:9 #6 0x561530e26464 in transport_push /home/gitster/w/build/transport.c:1421:16 #7 0x561530800bec in push_with_options /home/gitster/w/build/builtin/push.c:387:8 #8 0x5615307ffb99 in do_push /home/gitster/w/build/builtin/push.c:442:7 #9 0x5615307fe926 in cmd_push /home/gitster/w/build/builtin/push.c:664:7 #10 0x56153065673f in run_builtin /home/gitster/w/build/git.c:506:11 #11 0x56153065342f in handle_builtin /home/gitster/w/build/git.c:779:9 #12 0x561530655b89 in run_argv /home/gitster/w/build/git.c:862:4 #13 0x561530652cba in cmd_main /home/gitster/w/build/git.c:984:19 #14 0x5615308dda0a in main /home/gitster/w/build/common-main.c:9:11 #15 0x7f051651bca7 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 SUMMARY: AddressSanitizer: 421 byte(s) leaked in 2 allocation(s). Free the capablities data for the previous server before overwriting it with the next server to plug this leak. The added test fails without the freeing with SANITIZE=leak; I somehow couldn't get it fail reliably with SANITIZE=leak,address though. Signed-off-by: Junio C Hamano

Merge branch 'jc/string-list-split'

2025-08-21T20:46:59Z

string_list_split*() family of functions have been extended to simplify common use cases. * jc/string-list-split: string-list: split-then-remove-empty can be done while splitting string-list: optionally omit empty string pieces in string_list_split*() diff: simplify parsing of diff.colormovedws string-list: optionally trim string pieces split by string_list_split*() string-list: unify string_list_split* functions string-list: align string_list_split() with its _in_place() counterpart string-list: report programming error with BUG

string-list: align string_list_split() with its _in_place() counterpart

2025-08-03T05:29:27Z

The string_list_split_in_place() function was updated by 52acddf3 (string-list: multi-delimiter `string_list_split_in_place()`, 2023-04-24) to take more than one delimiter characters, hoping that we can later use it to replace our uses of strtok(). We however did not make a matching change to the string_list_split() function, which is very similar. Before giving both functions more features in future commits, allow string_list_split() to also take more than one delimiter characters to make them closer to each other. Signed-off-by: Junio C Hamano

config: drop `git_config_get_string()` wrapper

2025-07-23T15:15:19Z

In 036876a1067 (config: hide functions using `the_repository` by default, 2024-08-13) we have moved around a bunch of functions in the config subsystem that depend on `the_repository`. Those function have been converted into mere wrappers around their equivalent function that takes in a repository as parameter, and the intent was that we'll eventually remove those wrappers to make the dependency on the global repository variable explicit at the callsite. Follow through with that intent and remove `git_config_get_string()`. All callsites are adjusted so that they use `repo_config_get_string(the_repository, ...)` instead. While some callsites might already have a repository available, this mechanical conversion is the exact same as the current situation and thus cannot cause any regression. Those sites should eventually be cleaned up in a later patch series. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

config: drop `git_config()` wrapper

2025-07-23T15:15:18Z

In 036876a1067 (config: hide functions using `the_repository` by default, 2024-08-13) we have moved around a bunch of functions in the config subsystem that depend on `the_repository`. Those function have been converted into mere wrappers around their equivalent function that takes in a repository as parameter, and the intent was that we'll eventually remove those wrappers to make the dependency on the global repository variable explicit at the callsite. Follow through with that intent and remove `git_config()`. All callsites are adjusted so that they use `repo_config(the_repository, ...)` instead. While some callsites might already have a repository available, this mechanical conversion is the exact same as the current situation and thus cannot cause any regression. Those sites should eventually be cleaned up in a later patch series. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

Use legacy hash for legacy formats

2025-07-01T21:58:24Z

We have a large variety of data formats and protocols where no hash algorithm was defined and the default was assumed to always be SHA-1. Instead of explicitly stating SHA-1, let's use the constant to represent the legacy hash algorithm (which is still SHA-1) so that it's clear for documentary purposes that it's a legacy fallback option and not an intentional choice to use SHA-1. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

Merge branch 'cc/lop-remote'

2025-03-05T18:37:44Z

Large-object promisor protocol extension. * cc/lop-remote: doc: add technical design doc for large object promisors promisor-remote: check advertised name or URL Add 'promisor-remote' capability to protocol v2

Merge branch 'ua/os-version-capability'

2025-02-27T23:23:00Z

The value of "uname -s" is by default sent over the wire as a part of the "version" capability. * ua/os-version-capability: agent: advertise OS name via agent capability t5701: add setup test to remove side-effect dependency version: extend get_uname_info() to hide system details version: refactor get_uname_info() version: refactor redact_non_printables() version: replace manual ASCII checks with isprint() for clarity