This is purely cosmetic, but I've found it has a rather profound user experience impact.
When determining which environment variable to use, non-github clients still get prefixed with GITHUB_PAT. When using codeberg or GitLab, generating a GITHUB_PAT_ENTERPRISE_COM is sort of misleading.
Although just cosmetic, this is often a huge point of confusion when onboarding more junior developers, who might be encountering private git authentication and their first non-GitHub service for the first time. At my place of work this is exacerbated by having both enterprise GitHub and its competitors serving different parts of the organization, adding to confusion about which services are for which purposes.
Using a more generic GIT_PAT_ENTERPRISE_COM would go a long way toward easing adoption.
For specific hosts, having fallbacks that reflect individual providers' recommendations could always remain as special cases.
This is purely cosmetic, but I've found it has a rather profound user experience impact.
When determining which environment variable to use, non-github clients still get prefixed with
GITHUB_PAT. When using codeberg or GitLab, generating aGITHUB_PAT_ENTERPRISE_COMis sort of misleading.Although just cosmetic, this is often a huge point of confusion when onboarding more junior developers, who might be encountering private git authentication and their first non-GitHub service for the first time. At my place of work this is exacerbated by having both enterprise GitHub and its competitors serving different parts of the organization, adding to confusion about which services are for which purposes.
Using a more generic
GIT_PAT_ENTERPRISE_COMwould go a long way toward easing adoption.For specific hosts, having fallbacks that reflect individual providers' recommendations could always remain as special cases.