TortoiseGit Push to Public Remote Without Confirmation Prompt

Answer to the Core Question

There is no built‑in TortoiseGit setting that classifies a remote as "public" or that automatically prompts the user before pushing to a potentially public URL. The Push dialog simply forwards the command to the underlying Git executable, which follows the standard Git configuration without any visibility checks.

Why That Is the Case

• TortoiseGit’s UI is a thin wrapper around Git for Windows; it does not maintain a separate notion of public vs private remotes.
• Git’s configuration stores only the URL; access control is enforced by the remote server (e.g., SSH key, HTTPS token).
• Because the GUI cannot introspect server visibility, it cannot present a “public‑remote” warning.

Using a Client‑Side pre‑push Hook

The most reliable way to guard against accidental pushes to a public destination is to install a pre‑push hook in the repository’s .git/hooks directory. Git will invoke this script before any push is sent, and if the script exits with a non‑zero status the push is aborted. TortoiseGit respects this exit code and displays the hook’s error message in the Push dialog.

# .git/hooks/pre-push
#!/usr/bin/env bash
# Abort pushes to any remote whose URL contains "github.com" or "gitlab.com"
# Adjust the list below to match your public hosts.

PUBLIC_HOSTS=("github.com" "gitlab.com" "bitbucket.org")

# Extract the remote name and URL
REMOTE_NAME=$1
REMOTE_URL=$(git remote get-url $REMOTE_NAME)

for host in "${PUBLIC_HOSTS[@]}"; do
    if [[ "$REMOTE_URL" == *"$host"* ]]; then
        echo "\n*** ERROR: Pushing to public remote '$REMOTE_URL' is blocked by the pre-push hook. ***\n" >&2
        exit 1
    fi
done

exit 0

Make the script executable:

chmod +x .git/hooks/pre-push

When you attempt to push, TortoiseGit will now show the hook’s error message and refuse to send the commit. The hook runs in the same environment as the Git command line, so it works across all recent TortoiseGit releases (from 2.x onward).

Limitations & Caveats

• The hook lives in .git/hooks and is not version‑controlled; each clone must install it manually or use a post‑clone script.
• Users can bypass hooks with --no-verify, but this flag is rarely used in the TortoiseGit GUI.
• Hook scripts must be compatible with the shell provided by Git for Windows (typically Git Bash).

Next Steps

1. Decide which hostnames should trigger the block (e.g., "github.com", "gitlab.com").
2. Create or update the pre-push script with the list.
3. Test by attempting to push to a public remote; the operation should abort with the hook’s message.
4. Distribute the hook to all team members or embed it in a setup script.

Missing Diagnostic Detail

To fine‑tune the hook, it would help to know whether you use SSH or HTTPS URLs for your remotes and whether any custom domain names (e.g., a corporate GitLab instance) should be exempt. If you can share the pattern of URLs you consider “public”, the hook can be adjusted accordingly.