Repository navigation
Conversation
On Windows, difftool can fail with "Function not implemented" even on NTFS with core.symlinks explicitly enabled. See git-for-windows#5517 for context. 8241ae6 (difftool: eliminate use of global variables, 2025-02-05) stopped propagating core.symlinks beyond difftool's private setting. The canonical flag checked by mingw_create_symlink() therefore stays false without MSYS=winsymlinks:nativestrict, rejecting creation before CreateSymbolicLinkW() is called. This is a configuration propagation regression, not a filesystem or Developer Mode limitation. Honor the explicit setting consistently without requiring an MSYS override. Assisted-by: GPT-6.1 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On native Windows, difftool fails with "Function not implemented" when core.symlinks is absent and MSYS is empty. This is another manifestation of git-for-windows#5517. 8241ae6 (difftool: eliminate use of global variables, 2025-02-05) introduced a private flag initialized to true instead of preserving the platform default. On Windows, the fallback is false unless MSYS contains winsymlinks:nativestrict, so the unconfigured case requests a native symlink that mingw_create_symlink() rejects. Restore the platform default when core.symlinks is unset. Configured values still take precedence, and the non-Windows default remains true. Assisted-by: GPT-6.1 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Member
Author
|
/snapshot The |
mjcheetham
approved these changes
Oct 9, 2026
dscho
added a commit
to dscho/gfw-helper-github-app
that referenced
this pull request
Oct 9, 2026
We want to edit the `/git-artifacts` PR comment when cascading runs are started. At the moment, we use the GitHub REST API for that, searching for the corresponding comment with the expected edit referring to the `tag-git` run. Unfortunately, this Search API has become quite unreliable. In addition, the current logic recognizes only `/git-artifacts`, so it cannot rediscover this `/snapshot` request: git-for-windows/git#6468 (comment) The `tag-git` and `git-artifacts` workflows just learned to accept the PR comment URL directly, as an optional input, to sidestep the Search API altogether. Let's use this information, if available. Keep the legacy lookup and dispatch payloads unchanged when the PR comment URL is absent from the metadata, to make things more robust. Assisted-by: GPT-6.1 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to git-for-windows/git-for-windows-automation
that referenced
this pull request
Oct 9, 2026
) The [`/snapshot` request on git-for-windows/git#6468](git-for-windows/git#6468 (comment)) received the tagging-workflow link, but not links to the cascading architecture builds. The helper already knows the requesting comment URL from the webhook, but that origin needs to survive tagging so later builds can be linked back to the same comment. This is the workflow prerequisite for the companion update in git-for-windows/gfw-helper-github-app#250. It must land before deploying the helper update. The comment URL is optional; dispatches without it, check names, and summaries remain unchanged.
dscho
added a commit
to git-for-windows/gfw-helper-github-app
that referenced
this pull request
Oct 9, 2026
…#250) The legacy resolver depends on `/search/issues` and only recognizes comments starting with `/git-artifacts`. It therefore cannot locate the [`/snapshot` request on git-for-windows/git#6468](git-for-windows/git#6468 (comment)), leaving that comment without the cascading architecture-build links even though the webhook supplies its exact URL. Return those links to the known requesting comment instead of searching for it. The current request's origin takes precedence when a successful tagging check is reused; older check payloads without a comment URL retain the legacy lookup and dispatch behavior. Depends on git-for-windows/git-for-windows-automation#199; merge the automation change before deploying this helper update.
This branch has not been deployed
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
A regression introduced into Git v2.49.0 prevented
git difftoolfrom honoring thecore.symlinkssetting fully, except whenMSYS=winsymlinks:nativestrictwas set, too. Let's fix this.This addresses #5517