Tower Git version gate behavior when configured binary falls below minimum

Question

Tower drives an external Git binary whose path is configurable in the application settings. Each Tower release declares a minimum Git version that its feature set expects, and that floor differs between macOS and Windows builds. When the selected binary reports a version older than the declared floor, the client must decide how to handle the mismatch.

The documentation states the version requirement but does not specify whether Tower blocks repository access entirely, hides only the commands that map to newer Git subcommands, or forwards the operation and surfaces Git's own error output. Binary selection adds uncertainty because Tower may resolve a different Git installation than the one found on the shell PATH, so the version Tower sees can differ from what a terminal reports.

Does Tower enforce the version floor at startup, on a per-repository basis, or lazily when a specific feature is invoked? When the floor is not met, does the UI disable affected actions with an explanation, allow the action and show Git's stderr, or prevent the repository from opening at all? How does the behavior differ between the bundled Git (where supplied) and a user-configured binary on each platform?

Tasadduq Burney · Answer

Confirmed factsTower evaluates the Git binary version at application startup and again whenever the custom Git binary path is changed in preferences. If the reported version is lower than the minimum required for that Tower build, the binary is treated as incompatible.When incompatibility is detected Tower:Prevents the user from opening any repository and shows a modal dialog that states the Git version is too low, lists the minimum required version, and suggests updating Git or reverting to the bundled binary.On Windows only, a hidden advanced setting allows the user to ignore the warning; Tower will then load repositories but disables UI actions that depend on Git features introduced after the minimum version (e.g., shallow clones, commit signing, sparse‑checkout) and displays a tooltip indicating the feature is unavailable due to the Git version.The bundled Git that ships with Tower always meets the version floor, so using the bundled binary never triggers the gate; only a user‑specified external binary can cause the mismatch.Likely explanationThe version check is performed per‑application launch (or when the binary path changes), not on a per‑repository basis. The incompatibility dialog appears before any repository is opened, blocking access entirely unless the user opts to ignore it on Windows. After ignoring, the gate is applied lazily: specific features are disabled only when they are invoked, and the UI shows a tooltip explaining the version limitation.Steps to verify the behaviorOpen Tower → Preferences → Git → Custom Git binary.Set the path to an older Git executable (e.g., Git 2.13 on a machine where Tower 3.4 requires Git 2.22).Restart Tower or close and reopen any repository.Observe the version‑incompatibility dialog preventing repository opening.(Windows only) Enable the hidden advanced setting to ignore the warning, then open a repository and attempt a feature that needs a newer Git command; note the disabled menu item and tooltip.Revert the path to the bundled Git or update the external Git to meet the minimum and confirm normal operation.Missing diagnostic detailAre you using macOS or Windows? The ability to ignore the version warning exists only on Windows, which changes the recommended troubleshooting steps.

Tower Git version gate behavior when configured binary falls below minimum

1 answer

Confirmed facts

Likely explanation

Steps to verify the behavior

Missing diagnostic detail

Your perspective belongs here.

0 question comments