git/builtin, branch v2.47.2

Merge branch 'kh/checkout-ignore-other-docfix' into maint-2.47

2024-11-25T03:29:45Z

Doc updates. * kh/checkout-ignore-other-docfix: checkout: refer to other-worktree branch, not ref

Merge branch 'jh/config-unset-doc-fix' into maint-2.47

2024-11-25T03:29:40Z

Docfix. * jh/config-unset-doc-fix: git-config.1: remove value from positional args in unset usage

Merge branch 'db/submodule-fetch-with-remote-name-fix' into maint-2.47

2024-11-20T05:43:00Z

A "git fetch" from the superproject going down to a submodule used a wrong remote when the default remote names are set differently between them. * db/submodule-fetch-with-remote-name-fix: submodule: correct remote name with fetch

Merge branch 'ps/maintenance-start-crash-fix' into maint-2.47

2024-11-20T05:42:58Z

"git maintenance start" crashed due to an uninitialized variable reference, which has been corrected. * ps/maintenance-start-crash-fix: builtin/gc: fix crash when running `git maintenance start`

Merge branch 'jk/fsmonitor-event-listener-race-fix' into maint-2.47

2024-11-20T05:42:57Z

On macOS, fsmonitor can fall into a race condition that results in a client waiting forever to be notified for an event that have already happened. This problem has been corrected. * jk/fsmonitor-event-listener-race-fix: fsmonitor: initialize fs event listener before accepting clients simple-ipc: split async server initialization and running

checkout: refer to other-worktree branch, not ref

2024-10-10T20:09:13Z

We can only check out commits or branches, not refs in general. And the problem here is if another worktree is using the branch that we want to check out. Let’s be more direct and just talk about branches instead of refs. Also replace “be held” with “in use”. Further, “in use” is not restricted to a branch being checked out (e.g. the branch could be busy on a rebase), hence generalize to “or otherwise in use” in the option description. Signed-off-by: Kristoffer Haugsbakk Signed-off-by: Junio C Hamano

builtin/gc: fix crash when running `git maintenance start`

2024-10-10T17:04:43Z

It was reported on the mailing list that running `git maintenance start` immediately segfaults starting with b6c3f8e12c (builtin/maintenance: fix leak in `get_schedule_cmd()`, 2024-09-26). And indeed, this segfault is trivial to reproduce up to a point where one is scratching their head why we didn't catch this regression in our test suite. The root cause of this error is `get_schedule_cmd()`, which does not populate the `out` parameter in all cases anymore starting with the mentioned commit. Callers do assume it to always be populated though and will e.g. call `strvec_split()` on the returned value, which will of course segfault when the variable is uninitialized. So why didn't we catch this trivial regression? The reason is that our tests always set up the "GIT_TEST_MAINT_SCHEDULER" environment variable via "t/test-lib.sh", which allows us to override the scheduler command with a custom one so that we don't accidentally modify the developer's system. But the faulty code where we don't set the `out` parameter will only get hit in case that environment variable is _not_ set, which is never the case when executing our tests. Fix the regression by again unconditionally allocating the value in the `out` parameter, if provided. Add a test that unsets the environment variable to catch future regressions in this area. Reported-by: Shubham Kanodia Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

submodule: correct remote name with fetch

2024-10-09T17:48:08Z

The code fetches the submodules remote based on the superproject remote name instead of the submodule remote name[1]. Instead of grabbing the default remote of the superproject repository, ask the default remote of the submodule we are going to run 'git fetch' in. 1. https://lore.kernel.org/git/ZJR5SPDj4Wt_gmRO@pweza/ Signed-off-by: Daniel Black Signed-off-by: Junio C Hamano

git-config.1: remove value from positional args in unset usage

2024-10-09T06:35:45Z

The synopsis for `git config unset` mentions two positional arguments: `` and ``. While the first argument is correct, the second is not. Users are expected to provide the value via `--value=`. Remove the positional argument. The `--value=` option is already documented correctly, so this is all we need to do to fix the documentation. Signed-off-by: Josh Heinrichs Reviewed-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

fsmonitor: initialize fs event listener before accepting clients

2024-10-08T19:03:56Z

There's a racy hang in fsmonitor on macOS that we sometimes see in CI. When we serve a client, what's supposed to happen is: 1. The client thread calls with_lock__wait_for_cookie() in which we create a cookie file and then wait for a pthread_cond event 2. The filesystem event listener sees the cookie file creation, does some internal book-keeping, and then triggers the pthread_cond. But there's a problem: we start the listener that accepts client threads before we start the fs event thread. So it's possible for us to accept a client which creates the cookie file and starts waiting before the fs event thread is initialized, and we miss those filesystem events entirely. That leaves the client thread hanging forever. In CI, the symptom is that t9210 (which is testing scalar, which always enables fsmonitor under the hood) may hang forever in "scalar clone". It is waiting on "git fetch" which is waiting on the fsmonitor daemon. The race happens more frequently under load, but you can trigger it predictably with a sleep like this, which delays the start of the fs event thread: --- a/compat/fsmonitor/fsm-listen-darwin.c +++ b/compat/fsmonitor/fsm-listen-darwin.c @@ -510,6 +510,7 @@ void fsm_listen__loop(struct fsmonitor_daemon_state *state) FSEventStreamSetDispatchQueue(data->stream, data->dq); data->stream_scheduled = 1; + sleep(1); if (!FSEventStreamStart(data->stream)) { error(_("Failed to start the FSEventStream")); goto force_error_stop_without_loop; One solution might be to reverse the order of initialization: start the fs event thread before we start the thread listening for clients. But the fsmonitor code explicitly does it in the opposite direction. The fs event thread wants to refer to the ipc_server_data struct, so we need it to be initialized first. A further complication is that we need a signal from the fs event thread that it is actually ready and listening. And those details happen within backend-specific fsmonitor code, whereas the initialization is in the shared code. So instead, let's use the ipc_server init/start split added in the previous commit. The generic fsmonitor code will init the ipc_server but _not_ start it, leaving that to the backend specific code, which now needs to call ipc_server_start_async() at the right time. For macOS, that is right after we start the FSEventStream that you can see in the diff above. It's not clear to me if Windows suffers from the same problem (and we simply don't trigger it in CI), or if it is immune. Regardless, the obvious place to start accepting clients there is right after we've established the ReadDirectoryChanges watch. This makes the hangs go away in our macOS CI environment, even when compiled with the sleep() above. Helped-by: Koji Nakamaru Signed-off-by: Jeff King Acked-by: Koji Nakamaru Signed-off-by: Junio C Hamano