Repository navigation
Prepare for v3.0.1 - #2466
Merged
Merged
Prepare for v3.0.1#2466
Conversation
Fix the VERSION file parsing for release steps. The VERSION file previously had four parts (x.y.z.w), but we only care about the first three components (x.y.z). Now we moved VERSION to only have 3-parts itself, so the release pipeline does not need to strip the .w part. Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com>
With GCM 3.0 on Windows, drop the 32-bit x86 target from being built in CI and release jobs. We still retain the ability to build for win-x86 locally for those that wish to build it themselves. This is similar to the support we have for linux-arm (armhf) - you can built it yourself; we do not publish bits. Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com>
…stem#2456) With GCM 3.x on Windows, drop the 32-bit x86 target from being built in CI and release jobs. We still retain the ability to build for win-x86 locally for those that wish to build it themselves. This is similar to the support we have for linux-arm (armhf) - you can built it yourself; we do not publish bits. cc @dscho as this impacts what GCM package version the i686 MinGit distributions will need to reference (they'll need to reference the latest 2.x rather than 3.x).
Clarify that only .NET supported Linux distros are supported by GCM, that x86 on Windows no longer carries official builds, and that x64 on macOS is best effort (with Apple dropping Intel support with their next major release; macOS 28). Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com>
As of GCM 3.0, the 'UseMsAuthDefaultAccount' setting is now a tri-state flag, which has the following meanings: true => always use the OS account false => never use the OS account unset => ask to use the OS account This means that, on DevBox, where we currently special-case and return 'true' for this setting, the user has no way to sign-in to an Entra-backed provider using a _different_ account than the OS default account. Remove the special-casing of DevBox, and return `null` (unset) so the user continues to see the prompt. Until we can wire-up `continue=1` and retry logic to the Azure Repos provider, we need to make the user experience better for this scenario. Note, there is an obscure workaround: manually bind your Azure DevOps org to a different account - this is not very discoverable. Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com>
As of GCM 3.0, the 'UseMsAuthDefaultAccount' setting is now a tri-state flag, which has the following meanings: ```text true => always use the OS account false => never use the OS account unset => ask to use the OS account ``` This means that, on DevBox, where we currently special-case and return 'true' for this setting, the user has no way to sign-in to an Entra-backed provider using a _different_ account than the OS default account. Remove the special-casing of DevBox, and return `null` (unset) so the user continues to see the prompt. Until we can wire-up `continue=1` and retry logic to the Azure Repos provider, we need to make the user experience better for this scenario. Note, there is an obscure workaround: manually bind your Azure DevOps org to a different account - this is not very discoverable.
add and register capability flag for 'authtype' create credential output based on Authorization type and support define and use Constants for credential protocol keys move default arguments for GitResponse flags to internal constructor
emit 'ephemeral' value in GitResponse if set and capability is present check 'ephemeral' setting in GitRequest content
Different versions of Git for Windows have different installation path prefixes; our existing docs only reference the mingw64 toolchain path. Update the docs to call out the different installation paths for x64 (UCRT64 and MINGW64), and ARM64 (CLANGARM64). Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com>
…#2460) Different versions of Git for Windows have different installation path prefixes; our existing docs only reference the mingw64 toolchain path. Update the docs to call out the different installation paths for x64 (UCRT64 and MINGW64), and ARM64 (CLANGARM64). [Rendered docs](https://github.com/mjcheetham/git-credential-manager/blob/a091842e6200cca938df97fb3750d4dd48008951/docs/wsl.md)
The file paths for using GCM in WSL _without_ Git for Windows are only correct for the old x86 GCM installations. Update the docs to call out the x64 and ARM64 paths too, first. Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com>
The file paths for using GCM in WSL _without_ Git for Windows are only correct for the old x86 GCM installations. Update the docs to call out the x64 and ARM64 paths too, first. [Rendered docs](https://github.com/mjcheetham/git-credential-manager/blob/917c8244794c37412c556e1fab36a79b87df68f6/docs/wsl.md)
switch to alternative credential properties for 'authtype' add support for 'ephemeral' state to protocol and basic credential interface
Ensure that we only consider a console window (or hosting terminal in case of ConPTY) a valid parent for MSAL windows if it is visible. This will prevent MSAL windows from being hidden too. Note that we do **not** apply the visibility check to the optional explicitly provided parent window (via `GCM_MODEL_PARENTHWND)` - the caller should be the one to decide if their handle is good to use or not. Finally, note that we do **not** check for a minimised parent window (via `IsIconic(HWND)`) because we should probably also remain minimised if our parent was. Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com>
Extract the console parent lookup logic to a static method in preparation for allowing tests to mock it. Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com>
Allow testing of the parent window adapter by allowing mocks of the core platform-specific APIs: * creation of stub window * window visibilty checking * get console window Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com>
In previous versions of GCM (2.x) we preferred to parent MSAL windows to the console window, if possible, over creating our own stub 'progress' window. In GCM 3.0.0 we accidentally reversed that preference, which means in practice we always used the stub window and never the console window. Let's reverse that back to the desired order: 1. Explicit parent (via `GCM_MODAL_PARENTHWND`) 2. Console window parent (if present and visible) 3. Stub progress window (if required by the caller) 4. None Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com>
Add comprehensive tests of the MSAL parent window adapter, and the precedence logic for selecting (and creating) an appropriate parent window. Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com>
Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com>
Windows authentication dialogs need an appropriate parent window, but Git is not always launched from a visible terminal. GUI applications and background processes can retain a hidden console with a valid HWND. Automatically selecting that invisible owner can leave authentication UI out of view, making the operation appear stalled while it waits for credentials. GCM 3.0 also accidentally reversed the parent-selection preference used in 2.x: interactive Windows broker authentication creates a progress window before considering an existing console owner. This introduces unnecessary temporary UI and disconnects authentication dialogs from the terminal that initiated the operation. This PR restores console-first parenting while rejecting invisible automatically discovered owners. The selection order becomes: 1. An explicit HWND supplied through `GCM_MODAL_PARENTHWND`. 2. The console’s root-owner HWND, provided `IsWindowVisible` returns true. 3. A GCM-created progress window, if a parent is required. 4. No parent otherwise. The visibility check applies **after** walking the window parent/owner chain. This matters for ConPTY, where the console HWND may be a hidden compatibility window while its root owner is the visible terminal. Explicit HWNDs remain the caller’s responsibility and are not visibility-filtered. Minimised owners also remain eligible: this change deliberately does not add an `IsIconic` check or replace a minimised owner with an independent progress window. The series adds regression coverage for parent precedence, hidden or missing owners, and progress-window cleanup, and documents `GCM_MODAL_PARENTHWND` for applications integrating Git into their own GUI.
Console parenting currently lives inside the MSAL adapter, so other in-process authentication dialogs do not benefit from the visible terminal owner. Those prompts can appear disconnected from the Git operation that opened them. Resolve the parent at the shared authentication boundary so all in-process prompts follow the same policy. Explicit handles retain precedence, hidden console owners are ignored, and minimised owners remain eligible. Keep progress-window creation in the MSAL adapter: it is a fallback for broker flows that require a parent, not a default owner for ordinary authentication dialogs. Assisted-by: Claude Sonnet 5 Assisted-by: GPT-6.1 Sol Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com>
Helper commands resolve their parent handle independently of the in-process authentication path. Keeping only the explicit-HWND case would leave their default parent-selection policy inconsistent with the shared authentication lookup. Use the same visible-console fallback when no handle is configured. Explicit handles still take precedence, and a missing or hidden console leaves the parent unset. Assisted-by: GPT-6.1 Sol Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com>
This follows up on git-ecosystem#2464. Visible-console parenting currently lives inside the MSAL adapter, so _other_ in-process authentication dialogs remain unparented unless `GCM_MODAL_PARENTHWND` is supplied. Those prompts can appear disconnected from the terminal that initiated the Git operation. This PR moves console-parent discovery into a shared platform helper and uses it in the authentication and UI-helper parent handle lookups. This extends the fallback beyond MSAL while keeping the two lookup paths consistent. MSAL retains responsibility for creating a progress window when broker authentication requires a parent and no usable handle was resolved. Explicit HWNDs still take precedence and are not visibility-filtered. Automatically discovered owners must be visible, with visibility checked after resolving the console's root owner to accommodate ConPTY compatibility windows. Update the environment variable documentation to describe the fallback to the console-parent window. Tested behaviour on Windows Terminal, conhost.exe (classic terminal host), and Git Bash/MSYS2's terminal.
Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com>
mjcheetham
enabled auto-merge
October 6, 2026 11:19
dscho
approved these changes
Oct 6, 2026
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
5 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.
Bug Fixes:
Features:
authtypeGit capability (protocol: add support for 'authtype' capability #2457)Other changes: