postinstall: support installation by a service user that isn't the end user

[petros]

Feature description

Hi! Thanks for maintaining GCM, it's a great tool.

I'd like to raise an issue with how the macOS .pkg postinstall script handles user detection when the package is installed by a service user rather than the end user.

Context

Workbrew is a fleet management platform for Homebrew. It runs brew commands (including cask installs) as a dedicated workbrew service user, with $USER and $HOME set to that service user's values (workbrew and /opt/workbrew/home respectively). The real end user is a different account on the machine.

This is conceptually similar to MDM-initiated installs or any deployment tool that uses a service account to install packages on behalf of users.

Problem

The postinstall script runs:

sudo -u ${USER} "$INSTALL_DESTINATION/git-credential-manager" configure

This writes GCM's credential helper configuration into the service user's ~/.gitconfig (in our case /opt/workbrew/home/.gitconfig). Because GCM's configure command prepends an empty credential.helper = line to reset the helper list, it effectively overrides any credential helper that was already configured for that user:

# Workbrew's original config:
[credential]
    helper =
    helper = /opt/workbrew/libexec/git-credential-workbrew

# After GCM postinstall appends its config:
[credential]
    helper =
    helper = /opt/workbrew/libexec/git-credential-workbrew
    helper =
    helper = /usr/local/share/gcm-core/git-credential-manager

The second helper = resets the list, so only GCM is active. When the service user later runs git fetch (e.g. during brew update), GCM launches its GUI, which can't authenticate in a non-interactive service context and hangs indefinitely.

Suggestion

Would it be possible for the postinstall script to detect the actual logged-in console user instead of relying on $USER? macOS provides this via scutil:

logged_in_user=$(echo "show State:/Users/ConsoleUser" | scutil | awk '/Name :/ { print $3 }')

Homebrew's own .pkg installer uses this exact pattern to determine the real user when the installer runs in a different user context.

Alternatively, configuring at the system level (git-credential-manager configure --system) rather than --global might be another option, as was discussed in #186.

I understand this may be a niche scenario and am happy to help test any changes. We can also work around this on our side in the meantime, but it felt worth raising since other enterprise deployment tools likely hit the same issue.

Thanks for considering this!