Feature Request: Native Git Client Version Control for GitLab Admins
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Background
GitLab administrators currently lack a reliable, performant way to enforce minimum Git client versions across their instances. While older Git clients (particularly v1.x) can cause issues with newer GitLab versions, the available solutions for blocking outdated clients are problematic:
- Using nginx rules to block based on user agent is unreliable as it can be circumvented and may incorrectly block valid Git versions (for example, a customer attempting to block Git v1.x encountered significant challenges when working with tools like ArgoCD and Flux helm charts, where Git 2.x requests were incorrectly blocked due to header identification issues)
- Implementing pre-receive hooks creates significant performance overhead as it requires checking every Git operation
Problem to Solve
Provide GitLab administrators with a native, efficient mechanism to:
- Detect and validate Git client versions reliably without impacting performance
- Configure and enforce minimum Git client version requirements at the instance, group, or project level
- Prevent connection attempts from non-compliant Git clients before operations begin
- Communicate version requirements clearly to users
Proposed Solution
Implement native, application-level Git client version control with the following capabilities:
-
Admin Configuration
- Set minimum required Git client version
- Define actions for non-compliant clients (block, warn, allow)
- Customize error messages for blocked clients
-
Version Detection & Enforcement
- Built-in, reliable Git client version detection that doesn't rely solely on HTTP headers
- Efficient validation that properly handles automated tools and CI/CD systems
- Version checking implementation that doesn't impact performance like pre-receive hooks do
- Clear communication of version requirements to users
Edited by 🤖 GitLab Bot 🤖