Automatically avoid GUI prompts when run in remote terminal

[derrickstolee]

Feature description

I'm not sure if this is even possible, but can we detect if the parent Git process is being run in a remote terminal without an attached GUI?

The case I'm thinking about is a user who is remoting into a macOS device and their credential prompts are blocking Git commands with a GUI prompt that is not visible to them.

There are workarounds, such as setting credential.interactive=false in the Git config. It would be nice if GCM could detect such a scenario and do the right thing right away.

(I have no idea if the macOS platform or any other platform supports this distinction.)

[mjcheetham]

This sort of thing has been brought up in the past, specifically around reliably determining if the parent of this Git process chain is interactive on the terminal vs GUI: #600 (comment)

macOS has APIs to determine if there is a Quartz session available, and we are using this already in GCM:

git-credential-manager/src/shared/Core/Interop/MacOS/MacOSSessionManager.cs

Lines 13 to 29 in 312354b

	public override bool IsDesktopSession
	{
	get
	{
	// Get information about the current session
	int error = SecurityFramework.SessionGetInfo(SecurityFramework.CallerSecuritySession, out int id, out var sessionFlags);
	// Check if the session supports Quartz
	if (error == 0 && (sessionFlags & SessionAttributeBits.SessionHasGraphicAccess) != 0)
	{
	return true;
	}
	// Fall-through and check if X11 is available on macOS
	return base.IsDesktopSession;
	}
	}

The case I'm thinking about is a user who is remoting into a macOS device and their credential prompts are blocking Git commands with a GUI prompt that is not visible to them.

Are you finding this is the case?

Sessions are a complicated subject when it comes to remote access (across all OSes). I once found that if you SSH'd into a Linux machine that was sat at the GUI login screen, that invoking a libsecret/GNOME Keyring unlock _would cause a dialog to appear on the login screen - which has no session!).

Also see this conversation about sessions using the install process on macOS: #2302