-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prepare for v2.47.0.windows.2 #5221
Prepare for v2.47.0.windows.2 #5221
Commits on Oct 21, 2024
-
git-config.1: remove value from positional args in unset usage
The synopsis for `git config unset` mentions two positional arguments: `<name>` and `<value>`. While the first argument is correct, the second is not. Users are expected to provide the value via `--value=<value>`. Remove the positional argument. The `--value=<value>` option is already documented correctly, so this is all we need to do to fix the documentation. Signed-off-by: Josh Heinrichs <joshiheinrichs@gmail.com> Reviewed-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Configuration menu - View commit details
-
Copy full SHA for c92a039 - Browse repository at this point
Copy the full SHA c92a039View commit details -
Merge branch 'jh/config-unset-doc-fix'
Docfix. * jh/config-unset-doc-fix: git-config.1: remove value from positional args in unset usage
Configuration menu - View commit details
-
Copy full SHA for 53d9f27 - Browse repository at this point
Copy the full SHA 53d9f27View commit details -
docs: fix the
maintain-git
links intechnical/platform-support
These links should point to `.html` files, not to `.txt` ones. Compare also to 4945f04 (api docs: link to html version of api-trace2, 2022-09-16). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Configuration menu - View commit details
-
Copy full SHA for 422a4e3 - Browse repository at this point
Copy the full SHA 422a4e3View commit details -
Merge branch 'js/doc-platform-support-link-fix'
Docfix. * js/doc-platform-support-link-fix: docs: fix the `maintain-git` links in `technical/platform-support`
Configuration menu - View commit details
-
Copy full SHA for a89881e - Browse repository at this point
Copy the full SHA a89881eView commit details -
simple-ipc: split async server initialization and running
To start an async ipc server, you call ipc_server_run_async(). That initializes the ipc_server_data object, and starts all of the threads running, which may immediately start serving clients. This can create some awkward timing problems, though. In the fsmonitor daemon (the sole user of the simple-ipc system), we want to create the ipc server early in the process, which means we may start serving clients before the rest of the daemon is fully initialized. To solve this, let's break run_async() into two parts: an initialization which allocates all data and spawns the threads (without letting them run), and a start function which actually lets them begin work. Since we have two simple-ipc implementations, we have to handle this twice: - in ipc-unix-socket.c, we have a central listener thread which hands connections off to worker threads using a work_available mutex. We can hold that mutex after init, and release it when we're ready to start. We do need an extra "started" flag so that we know whether the main thread is holding the mutex or not (e.g., if we prematurely stop the server, we want to make sure all of the worker threads are released to hear about the shutdown). - in ipc-win32.c, we don't have a central mutex. So we'll introduce a new startup_barrier mutex, which we'll similarly hold until we're ready to let the threads proceed. We again need a "started" flag here to make sure that we release the barrier mutex when shutting down, so that the sub-threads can proceed to the finish. I've renamed the run_async() function to init_async() to make sure we catch all callers, since they'll now need to call the matching start_async(). We could leave run_async() as a wrapper that does both, but there's not much point. There are only two callers, one of which is fsmonitor, which will want to actually do work between the two calls. And the other is just a test-tool wrapper. For now I've added the start_async() calls in fsmonitor where they would otherwise have happened, so there should be no behavior change with this patch. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Koji Nakamaru <koji.nakamaru@gree.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Configuration menu - View commit details
-
Copy full SHA for 823223f - Browse repository at this point
Copy the full SHA 823223fView commit details -
fsmonitor: initialize fs event listener before accepting clients
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 <koji.nakamaru@gree.net> Signed-off-by: Jeff King <peff@peff.net> Acked-by: Koji Nakamaru <koji.nakamaru@gree.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Configuration menu - View commit details
-
Copy full SHA for dacf467 - Browse repository at this point
Copy the full SHA dacf467View commit details -
cache-tree: refactor verification to return error codes
The function `cache_tree_verify()` will `BUG()` whenever it finds that the cache-tree extension of the index is corrupt. The function is thus inherently untestable because the resulting call to `abort()` will be detected by our testing framework and labelled an error. And rightfully so: it shouldn't ever be possible to hit bugs, as they should indicate a programming error rather than corruption of on-disk state. Refactor the function to instead return error codes. This also ensures that the function can be used e.g. by git-fsck(1) without the whole process dying. Furthermore, this refactoring plugs some memory leaks when returning early by creating a common exit path. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Configuration menu - View commit details
-
Copy full SHA for e8922bd - Browse repository at this point
Copy the full SHA e8922bdView commit details -
cache-tree: detect mismatching number of index entries
In t4058 we have some tests that exercise git-read-tree(1) when used with a tree that contains duplicate entries. While the expectation is that we fail, we ideally should fail gracefully without a segfault. But that is not the case: we never check that the number of entries in the cache-tree is less than or equal to the number of entries in the index. This can lead to an out-of-bounds read as we unconditionally access `istate->cache[idx]`, where `idx` is controlled by the number of cache-tree entries and the current position therein. The result is a segfault. Fix this segfault by adding a sanity check for the number of index entries before dereferencing them. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Configuration menu - View commit details
-
Copy full SHA for ce5ee8d - Browse repository at this point
Copy the full SHA ce5ee8dView commit details -
Merge branch 'jk/fsmonitor-event-listener-race-fix'
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
Configuration menu - View commit details
-
Copy full SHA for 5bd0b3f - Browse repository at this point
Copy the full SHA 5bd0b3fView commit details -
unpack-trees: detect mismatching number of cache-tree/index entries
Same as the preceding commit, we unconditionally dereference the index's cache entries depending on the number of cache-tree entries, which can lead to a segfault when the cache-tree is corrupted. Fix this bug. This also makes t4058 pass with the leak sanitizer enabled. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Configuration menu - View commit details
-
Copy full SHA for 7959bb6 - Browse repository at this point
Copy the full SHA 7959bb6View commit details -
Makefile: fix dependency for $(UNIT_TEST_DIR)/clar/clar.o
The clar source file '$(UNIT_TEST_DIR)/clar/clar.c' includes the generated 'clar.suite', but this dependency is not taken into account by our Makefile, so that it is possible for a parallel build to fail if Make tries to build 'clar.o' before 'clar.suite' is generated. Correctly specify the dependency. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Configuration menu - View commit details
-
Copy full SHA for 9abda5e - Browse repository at this point
Copy the full SHA 9abda5eView commit details -
Merge branch 'ps/cache-tree-w-broken-index-entry' into next
Fail gracefully instead of crashing when attempting to write the contents of a corrupt in-core index as a tree object. * ps/cache-tree-w-broken-index-entry: unpack-trees: detect mismatching number of cache-tree/index entries cache-tree: detect mismatching number of index entries cache-tree: refactor verification to return error codes
Configuration menu - View commit details
-
Copy full SHA for d16d17d - Browse repository at this point
Copy the full SHA d16d17dView commit details -
submodule: correct remote name with fetch
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 <daniel@mariadb.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Configuration menu - View commit details
-
Copy full SHA for 6e0b224 - Browse repository at this point
Copy the full SHA 6e0b224View commit details -
Merge branch 'pb/clar-build-fix' into next
Build fix. * pb/clar-build-fix: Makefile: fix dependency for $(UNIT_TEST_DIR)/clar/clar.o
Configuration menu - View commit details
-
Copy full SHA for b303d03 - Browse repository at this point
Copy the full SHA b303d03View commit details -
mingw.c: Fix complier warnings for a 64 bit msvc
Remove some complier warnings from msvc in compat/mingw.c for value truncation from 64 bit to 32 bit integers. Compiling compat/mingw.c under a 64 bit version of msvc produces warnings. An "int" is 32 bit, and ssize_t or size_t should be 64 bit long. Prepare compat/vcbuild/include/unistd.h to have a 64 bit type _ssize_t, when _WIN64 is defined and 32 bit otherwise. Further down in this include file, as before, ssize_t is defined as _ssize_t, if needed. Use size_t instead of int for all variables that hold the result of strlen() or wcslen() (which cannot be negative). Use ssize_t to hold the return value of read(). Signed-off-by: Sören Krecker <soekkle@freenet.de> Signed-off-by: Taylor Blau <me@ttaylorr.com>
Configuration menu - View commit details
-
Copy full SHA for a7a3cea - Browse repository at this point
Copy the full SHA a7a3ceaView commit details -
Merge branch 'db/submodule-fetch-with-remote-name-fix' into next
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
Configuration menu - View commit details
-
Copy full SHA for cfc349e - Browse repository at this point
Copy the full SHA cfc349eView commit details -
Merge branch 'sk/msvc-warnings' into next
Fixes compile time warnings with 64-bit MSVC. * sk/msvc-warnings: mingw.c: Fix complier warnings for a 64 bit msvc
Configuration menu - View commit details
-
Copy full SHA for a306a68 - Browse repository at this point
Copy the full SHA a306a68View commit details