Use official GitLab cloning locations

[ssbarnea]

Avoid failure to clone repository with older versions of git by using
official cloning url (as exposed by GitLab itself in their web
interface).

References:

• https://stackoverflow.com/questions/32533379
• https://gitlab.com/gitlab-org/gitlab/issues/29629

Fixes: #1206

[javierpena]

I can confirm this fixes issues when running on CentOS 7.

[ssbarnea]

I also made a request to fix flake8 documentation, so we can avoid confusing other users https://gitlab.com/pycqa/flake8/merge_requests/381

[asottile]

sorry, we don't use centos 7 so we don't need to work around this bug in git

[webknjaz]

@asottile would you mind listing the runtime requirements somewhere in docs? And maybe having an assertion in the beginning of pre-commit execution pointing out if some prerequisites are missing could be a good idea.

[asottile]

it's... complicated. there's a list in CONTRIBUTING.md, but there are features which are version dependent and generally graceful degregation otherwise (for example pre-push was not always a thing, this gitlab+git bug only affects really old git, intent to add is buggy or absent in old git, etc.etc.)

[ssbarnea]

Was someone who advocated the pre-commit tool in the past years to many teams, I am upset about this direction. I am curious to whom does the we from we don't use centos 7 sentence refers to? Who is behind pre-commit tool? The documentation does not mention anything about project governance or what platforms are supported or not.

Does the future of pre-commit depend only on your decisions? Are your decisions set in stone? I am asking because I would be happy to offer to help with maintenance burden, especially around packaging and cross platform testing/deployment which are usually boring but also a primary source of frustration for the end-users.

To be back at the original PR: we all agree that it does avoid the mentioned error with old-git versions. The big question is what is the downside of adding .git to that url? I guess that adding 4 bytes to the size of the file does not count as a real downside, especially as this url is the one exposed by gitlab itself.

[asottile]

I am curious to whom does the we from we don't use centos 7 sentence refers to?

me, the core contributors, our CI

The documentation does not mention anything about project governance

it's primarily me, but there are other members in the organization

or what platforms are supported or not.

the docs do have **Support:** call outs. These cover "general" platforms such as "windows", "macos", "linux", "cygwin", etc. as enumerating every possible platform and combination is impossible (just with linux alone there are thousands of flavors shipping various combinations of software and patches)

Does the future of pre-commit depend only on your decisions? Are your decisions set in stone?

largely yes and yes -- as it always has

I would be happy to offer to help with maintenance burden

if you want to submit patches to fix actual bugs in the software (python files) please do so -- but this patch is not productive (pre-commit is not developed or tested on ancient distributions such as centos 7)

what is the downside of adding .git to that url?

this patch is "noise", it doesn't actually fix anything. additionally, .git is unnecessary cargo cult that I'd rather not promote