Tower Git version gate behavior when configured binary falls below minimum
0 reputation · 27 Nov 2024, 09:37 UTC
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?