Prepare for v2.47.0.windows.2 #5221
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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>
Docfix. * jh/config-unset-doc-fix: git-config.1: remove value from positional args in unset usage
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>
Docfix. * js/doc-platform-support-link-fix: docs: fix the `maintain-git` links in `technical/platform-support`
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>
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>
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>
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>
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
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>
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>
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
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>
Build fix. * pb/clar-build-fix: Makefile: fix dependency for $(UNIT_TEST_DIR)/clar/clar.o
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>
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
Fixes compile time warnings with 64-bit MSVC. * sk/msvc-warnings: mingw.c: Fix complier warnings for a 64 bit msvc
dscho
force-pushed
the
prepare-for-v2.47.0.windows.2
branch
from
6860bff
to
a306a68
Compare
git-for-windows-ci
pushed a commit
that referenced
this pull request
Oct 22, 2024
At the moment, the Git maintainer is on vacation. While there _is_ an interim maintainer, it seems as if v2.47.1 will need to wait for "the end of the month". However, I do not have the luxury of waiting for the end of the month, as #5199 is stacking up comments relating various degrees of upset over the lack of a new Git for Windows version that fixes fetches/pushes via SSH. To make it truly worth the effort, let's integrate a couple of topics that have been integrated into upstream Git's `master` and `next` branches in the meantime, topics I consider important enough to be fast-tracked into a new Git for Windows version, since we already have the need for one: - 53d9f27 Merge branch 'jh/config-unset-doc-fix' Fixes incorrect documentation - a89881e Merge branch 'js/doc-platform-support-link-fix' Fixes broken links in the documentation - 784986f Merge branch 'jk/fsmonitor-event-listener-race-fix' CI-only: fixes 6h timeouts in the `osx-*` jobs - 59bf8d2 Merge branch 'ps/cache-tree-w-broken-index-entry' into next Fixes segmentation faults e.g. after a checkout failed due to invalid filenames and there is now a half-valid Git index - ffd5653 Merge branch 'pb/clar-build-fix' into next I suspect that this might cause some flakiness in (parallel) CI builds, even if I have not personally noticed those flakes. - fe0f4bc Merge branch 'db/submodule-fetch-with-remote-name-fix' into next Seems like a bug fix submodule users might want - 6860bff Merge branch 'sk/msvc-warnings' into next This _should_ only affect builds with MS Visual C (which Git for Windows does not use for the official builds), it's still a good idea to do, if only to align with upstream Git's code.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Oct 22, 2024
At the moment, the Git maintainer is on vacation. While there _is_ an interim maintainer, it seems as if v2.47.1 will need to wait for "the end of the month". However, I do not have the luxury of waiting for the end of the month, as #5199 is stacking up comments relating various degrees of upset over the lack of a new Git for Windows version that fixes fetches/pushes via SSH. To make it truly worth the effort, let's integrate a couple of topics that have been integrated into upstream Git's `master` and `next` branches in the meantime, topics I consider important enough to be fast-tracked into a new Git for Windows version, since we already have the need for one: - 53d9f27 Merge branch 'jh/config-unset-doc-fix' Fixes incorrect documentation - a89881e Merge branch 'js/doc-platform-support-link-fix' Fixes broken links in the documentation - 784986f Merge branch 'jk/fsmonitor-event-listener-race-fix' CI-only: fixes 6h timeouts in the `osx-*` jobs - 59bf8d2 Merge branch 'ps/cache-tree-w-broken-index-entry' into next Fixes segmentation faults e.g. after a checkout failed due to invalid filenames and there is now a half-valid Git index - ffd5653 Merge branch 'pb/clar-build-fix' into next I suspect that this might cause some flakiness in (parallel) CI builds, even if I have not personally noticed those flakes. - fe0f4bc Merge branch 'db/submodule-fetch-with-remote-name-fix' into next Seems like a bug fix submodule users might want - 6860bff Merge branch 'sk/msvc-warnings' into next This _should_ only affect builds with MS Visual C (which Git for Windows does not use for the official builds), it's still a good idea to do, if only to align with upstream Git's code.
|
/add relnote bug A few documentation and other, minor bug fixes from upstream Git were integrated into Git for Windows early. The workflow run was started |
github-actions bot
pushed a commit
to git-for-windows/build-extra
that referenced
this pull request
Oct 22, 2024
A few documentation and other, minor bug fixes from upstream Git [were integrated into Git for Windows early](git-for-windows/git#5221). Signed-off-by: gitforwindowshelper[bot] <gitforwindowshelper-bot@users.noreply.github.com>
git-for-windows-ci
pushed a commit
that referenced
this pull request
Oct 22, 2024
At the moment, the Git maintainer is on vacation. While there _is_ an interim maintainer, it seems as if v2.47.1 will need to wait for "the end of the month". However, I do not have the luxury of waiting for the end of the month, as #5199 is stacking up comments relating various degrees of upset over the lack of a new Git for Windows version that fixes fetches/pushes via SSH. To make it truly worth the effort, let's integrate a couple of topics that have been integrated into upstream Git's `master` and `next` branches in the meantime, topics I consider important enough to be fast-tracked into a new Git for Windows version, since we already have the need for one: - 53d9f27 Merge branch 'jh/config-unset-doc-fix' Fixes incorrect documentation - a89881e Merge branch 'js/doc-platform-support-link-fix' Fixes broken links in the documentation - 784986f Merge branch 'jk/fsmonitor-event-listener-race-fix' CI-only: fixes 6h timeouts in the `osx-*` jobs - 59bf8d2 Merge branch 'ps/cache-tree-w-broken-index-entry' into next Fixes segmentation faults e.g. after a checkout failed due to invalid filenames and there is now a half-valid Git index - ffd5653 Merge branch 'pb/clar-build-fix' into next I suspect that this might cause some flakiness in (parallel) CI builds, even if I have not personally noticed those flakes. - fe0f4bc Merge branch 'db/submodule-fetch-with-remote-name-fix' into next Seems like a bug fix submodule users might want - 6860bff Merge branch 'sk/msvc-warnings' into next This _should_ only affect builds with MS Visual C (which Git for Windows does not use for the official builds), it's still a good idea to do, if only to align with upstream Git's code.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Oct 22, 2024
At the moment, the Git maintainer is on vacation. While there _is_ an interim maintainer, it seems as if v2.47.1 will need to wait for "the end of the month". However, I do not have the luxury of waiting for the end of the month, as #5199 is stacking up comments relating various degrees of upset over the lack of a new Git for Windows version that fixes fetches/pushes via SSH. To make it truly worth the effort, let's integrate a couple of topics that have been integrated into upstream Git's `master` and `next` branches in the meantime, topics I consider important enough to be fast-tracked into a new Git for Windows version, since we already have the need for one: - 53d9f27 Merge branch 'jh/config-unset-doc-fix' Fixes incorrect documentation - a89881e Merge branch 'js/doc-platform-support-link-fix' Fixes broken links in the documentation - 784986f Merge branch 'jk/fsmonitor-event-listener-race-fix' CI-only: fixes 6h timeouts in the `osx-*` jobs - 59bf8d2 Merge branch 'ps/cache-tree-w-broken-index-entry' into next Fixes segmentation faults e.g. after a checkout failed due to invalid filenames and there is now a half-valid Git index - ffd5653 Merge branch 'pb/clar-build-fix' into next I suspect that this might cause some flakiness in (parallel) CI builds, even if I have not personally noticed those flakes. - fe0f4bc Merge branch 'db/submodule-fetch-with-remote-name-fix' into next Seems like a bug fix submodule users might want - 6860bff Merge branch 'sk/msvc-warnings' into next This _should_ only affect builds with MS Visual C (which Git for Windows does not use for the official builds), it's still a good idea to do, if only to align with upstream Git's code.
This was referenced Oct 22, 2024
derrickstolee
added a commit
to microsoft/git
that referenced
this pull request
Oct 22, 2024
For quite a while now we have been haunted by those evil timeouts in some of the slowest CI jobs. There is a fix in upstream Git now, already on their `master` branch, but still unreleased. I have integrated a backport in Git for Windows v2.47.0(2) via git-for-windows#5221. Let's integrate this into `vfs-2.47.0` separately since I do not plan on merging Git for Windows' `main` branch into `vfs-2.47.0` any time soon (basically, I integrated those recent changes only because I had to have a version out that fixes git-for-windows#5199 but v2.47.0.vfs.0.2 _already_ fixed that, so there is no urgency).
git-for-windows-ci
pushed a commit
that referenced
this pull request
Oct 22, 2024
At the moment, the Git maintainer is on vacation. While there _is_ an interim maintainer, it seems as if v2.47.1 will need to wait for "the end of the month". However, I do not have the luxury of waiting for the end of the month, as #5199 is stacking up comments relating various degrees of upset over the lack of a new Git for Windows version that fixes fetches/pushes via SSH. To make it truly worth the effort, let's integrate a couple of topics that have been integrated into upstream Git's `master` and `next` branches in the meantime, topics I consider important enough to be fast-tracked into a new Git for Windows version, since we already have the need for one: - 53d9f27 Merge branch 'jh/config-unset-doc-fix' Fixes incorrect documentation - a89881e Merge branch 'js/doc-platform-support-link-fix' Fixes broken links in the documentation - 784986f Merge branch 'jk/fsmonitor-event-listener-race-fix' CI-only: fixes 6h timeouts in the `osx-*` jobs - 59bf8d2 Merge branch 'ps/cache-tree-w-broken-index-entry' into next Fixes segmentation faults e.g. after a checkout failed due to invalid filenames and there is now a half-valid Git index - ffd5653 Merge branch 'pb/clar-build-fix' into next I suspect that this might cause some flakiness in (parallel) CI builds, even if I have not personally noticed those flakes. - fe0f4bc Merge branch 'db/submodule-fetch-with-remote-name-fix' into next Seems like a bug fix submodule users might want - 6860bff Merge branch 'sk/msvc-warnings' into next This _should_ only affect builds with MS Visual C (which Git for Windows does not use for the official builds), it's still a good idea to do, if only to align with upstream Git's code.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Oct 22, 2024
At the moment, the Git maintainer is on vacation. While there _is_ an interim maintainer, it seems as if v2.47.1 will need to wait for "the end of the month". However, I do not have the luxury of waiting for the end of the month, as #5199 is stacking up comments relating various degrees of upset over the lack of a new Git for Windows version that fixes fetches/pushes via SSH. To make it truly worth the effort, let's integrate a couple of topics that have been integrated into upstream Git's `master` and `next` branches in the meantime, topics I consider important enough to be fast-tracked into a new Git for Windows version, since we already have the need for one: - 53d9f27 Merge branch 'jh/config-unset-doc-fix' Fixes incorrect documentation - a89881e Merge branch 'js/doc-platform-support-link-fix' Fixes broken links in the documentation - 784986f Merge branch 'jk/fsmonitor-event-listener-race-fix' CI-only: fixes 6h timeouts in the `osx-*` jobs - 59bf8d2 Merge branch 'ps/cache-tree-w-broken-index-entry' into next Fixes segmentation faults e.g. after a checkout failed due to invalid filenames and there is now a half-valid Git index - ffd5653 Merge branch 'pb/clar-build-fix' into next I suspect that this might cause some flakiness in (parallel) CI builds, even if I have not personally noticed those flakes. - fe0f4bc Merge branch 'db/submodule-fetch-with-remote-name-fix' into next Seems like a bug fix submodule users might want - 6860bff Merge branch 'sk/msvc-warnings' into next This _should_ only affect builds with MS Visual C (which Git for Windows does not use for the official builds), it's still a good idea to do, if only to align with upstream Git's code.
dscho
added a commit
that referenced
this pull request
Oct 23, 2024
At the moment, the Git maintainer is on vacation. While there _is_ an interim maintainer, it seems as if v2.47.1 will need to wait for "the end of the month". However, I do not have the luxury of waiting for the end of the month, as #5199 is stacking up comments relating various degrees of upset over the lack of a new Git for Windows version that fixes fetches/pushes via SSH. To make it truly worth the effort, let's integrate a couple of topics that have been integrated into upstream Git's `master` and `next` branches in the meantime, topics I consider important enough to be fast-tracked into a new Git for Windows version, since we already have the need for one: - 53d9f27 Merge branch 'jh/config-unset-doc-fix' Fixes incorrect documentation - a89881e Merge branch 'js/doc-platform-support-link-fix' Fixes broken links in the documentation - 784986f Merge branch 'jk/fsmonitor-event-listener-race-fix' CI-only: fixes 6h timeouts in the `osx-*` jobs - 59bf8d2 Merge branch 'ps/cache-tree-w-broken-index-entry' into next Fixes segmentation faults e.g. after a checkout failed due to invalid filenames and there is now a half-valid Git index - ffd5653 Merge branch 'pb/clar-build-fix' into next I suspect that this might cause some flakiness in (parallel) CI builds, even if I have not personally noticed those flakes. - fe0f4bc Merge branch 'db/submodule-fetch-with-remote-name-fix' into next Seems like a bug fix submodule users might want - 6860bff Merge branch 'sk/msvc-warnings' into next This _should_ only affect builds with MS Visual C (which Git for Windows does not use for the official builds), it's still a good idea to do, if only to align with upstream Git's code.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Oct 25, 2024
At the moment, the Git maintainer is on vacation. While there _is_ an interim maintainer, it seems as if v2.47.1 will need to wait for "the end of the month". However, I do not have the luxury of waiting for the end of the month, as #5199 is stacking up comments relating various degrees of upset over the lack of a new Git for Windows version that fixes fetches/pushes via SSH. To make it truly worth the effort, let's integrate a couple of topics that have been integrated into upstream Git's `master` and `next` branches in the meantime, topics I consider important enough to be fast-tracked into a new Git for Windows version, since we already have the need for one: - 53d9f27 Merge branch 'jh/config-unset-doc-fix' Fixes incorrect documentation - a89881e Merge branch 'js/doc-platform-support-link-fix' Fixes broken links in the documentation - 784986f Merge branch 'jk/fsmonitor-event-listener-race-fix' CI-only: fixes 6h timeouts in the `osx-*` jobs - 59bf8d2 Merge branch 'ps/cache-tree-w-broken-index-entry' into next Fixes segmentation faults e.g. after a checkout failed due to invalid filenames and there is now a half-valid Git index - ffd5653 Merge branch 'pb/clar-build-fix' into next I suspect that this might cause some flakiness in (parallel) CI builds, even if I have not personally noticed those flakes. - fe0f4bc Merge branch 'db/submodule-fetch-with-remote-name-fix' into next Seems like a bug fix submodule users might want - 6860bff Merge branch 'sk/msvc-warnings' into next This _should_ only affect builds with MS Visual C (which Git for Windows does not use for the official builds), it's still a good idea to do, if only to align with upstream Git's code.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Oct 25, 2024
At the moment, the Git maintainer is on vacation. While there _is_ an interim maintainer, it seems as if v2.47.1 will need to wait for "the end of the month". However, I do not have the luxury of waiting for the end of the month, as #5199 is stacking up comments relating various degrees of upset over the lack of a new Git for Windows version that fixes fetches/pushes via SSH. To make it truly worth the effort, let's integrate a couple of topics that have been integrated into upstream Git's `master` and `next` branches in the meantime, topics I consider important enough to be fast-tracked into a new Git for Windows version, since we already have the need for one: - 53d9f27 Merge branch 'jh/config-unset-doc-fix' Fixes incorrect documentation - a89881e Merge branch 'js/doc-platform-support-link-fix' Fixes broken links in the documentation - 784986f Merge branch 'jk/fsmonitor-event-listener-race-fix' CI-only: fixes 6h timeouts in the `osx-*` jobs - 59bf8d2 Merge branch 'ps/cache-tree-w-broken-index-entry' into next Fixes segmentation faults e.g. after a checkout failed due to invalid filenames and there is now a half-valid Git index - ffd5653 Merge branch 'pb/clar-build-fix' into next I suspect that this might cause some flakiness in (parallel) CI builds, even if I have not personally noticed those flakes. - fe0f4bc Merge branch 'db/submodule-fetch-with-remote-name-fix' into next Seems like a bug fix submodule users might want - 6860bff Merge branch 'sk/msvc-warnings' into next This _should_ only affect builds with MS Visual C (which Git for Windows does not use for the official builds), it's still a good idea to do, if only to align with upstream Git's code.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Oct 25, 2024
At the moment, the Git maintainer is on vacation. While there _is_ an interim maintainer, it seems as if v2.47.1 will need to wait for "the end of the month". However, I do not have the luxury of waiting for the end of the month, as #5199 is stacking up comments relating various degrees of upset over the lack of a new Git for Windows version that fixes fetches/pushes via SSH. To make it truly worth the effort, let's integrate a couple of topics that have been integrated into upstream Git's `master` and `next` branches in the meantime, topics I consider important enough to be fast-tracked into a new Git for Windows version, since we already have the need for one: - 53d9f27 Merge branch 'jh/config-unset-doc-fix' Fixes incorrect documentation - a89881e Merge branch 'js/doc-platform-support-link-fix' Fixes broken links in the documentation - 784986f Merge branch 'jk/fsmonitor-event-listener-race-fix' CI-only: fixes 6h timeouts in the `osx-*` jobs - 59bf8d2 Merge branch 'ps/cache-tree-w-broken-index-entry' into next Fixes segmentation faults e.g. after a checkout failed due to invalid filenames and there is now a half-valid Git index - ffd5653 Merge branch 'pb/clar-build-fix' into next I suspect that this might cause some flakiness in (parallel) CI builds, even if I have not personally noticed those flakes. - fe0f4bc Merge branch 'db/submodule-fetch-with-remote-name-fix' into next Seems like a bug fix submodule users might want - 6860bff Merge branch 'sk/msvc-warnings' into next This _should_ only affect builds with MS Visual C (which Git for Windows does not use for the official builds), it's still a good idea to do, if only to align with upstream Git's code.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
At the moment, the Git maintainer is on vacation. While there is an interim maintainer, it seems as if v2.47.1 will need to wait for "the end of the month".
However, I do not have the luxury of waiting for the end of the month, as #5199 is stacking up comments relating various degrees of upset over the lack of a new Git for Windows version that fixes fetches/pushes via SSH.
To make it truly worth the effort, let's integrate a couple of topics that have been integrated into upstream Git's
masterandnextbranches in the meantime, topics I consider important enough to be fast-tracked into a new Git for Windows version, since we already have the need for one:Fixes incorrect documentation
Fixes broken links in the documentation
CI-only: fixes 6h timeouts in the
osx-*jobsFixes segmentation faults e.g. after a checkout failed due to invalid filenames and there is now a half-valid Git index
I suspect that this might cause some flakiness in (parallel) CI builds, even if I have not personally noticed those flakes.
Seems like a bug fix submodule users might want
This should only affect builds with MS Visual C (which Git for Windows does not use for the official builds), it's still a good idea to do, if only to align with upstream Git's code.