doc/install: define minimum supported VCS versions

[bcmills]

cmd/go shells out to version control binaries to implement go get.

doc/install currently declares minimum supported OS versions for FreeBSD, macOS, and Windows, but only a minimum kernel version for Linux. Those requirements do not imply any particular version of the supported version control binaries, and those versions do matter in practice: in particular, git accrued a large number of flags in between 2.7 and 2.18 (#26653).

We should be explicit about which versions are supported for use with the go command.

(CC: @rsc @ianlancetaylor @bradfitz @myitcv @rogpeppe @trashhalo)

[bcmills]

Marking NeedsDecision to determine:

• whether we want to specify versions, and
• if so, what criteria to use to determine them.

[mostynb]

Maybe it would be sufficient to say "git version X or later is known to work" (taken from the oldest git version commonly used in tests), instead of figuring out and keeping track of the oldest suitable version?

[bradfitz]

I would really hope that we work with whatever's in Debian Stable at least, which is currently 2.11.0: https://packages.debian.org/stretch/git

[rsc]

Re @mostynb's point it's fine to say we need 2.5 even if 2.4 appears to work too.

I also agree with Brad that essentially every git that's on a supported OS by default needs to work. That's been our practice to date.

[bcmills]

essentially every git that's on a supported OS by default needs to work.

I think we all agree with that, but what does “supported OS” mean in this context?

Our current definition for Go on Linux, according to the install page, is just a kernel version and a specific exclusion for CentOS/RHEL 5.x. That doesn't tell us which distros (and which versions of which distros) we should use to determine “every git that's on a supported OS”.

To pick some examples:

• Debian 8 “Jessie” is in its LTS phase. It shipped with Git 2.1.4, but has a backport of 2.11.0 available. Does that mean we need to support 2.1.4, or just 2.11.0?
  • Debian “Jessie” shipped with Go 1.3.
• Ubuntu still supports Ubuntu 14.04 LTS, which shipped with Git 1.9.1. Does that mean we need to support Git 1.9.1?
  • From what I can tell, Ubuntu 14.04 LTS is ~9 Ubuntu releases ago. It shipped with Go 1.2, with a backport to Go 1.3.
• Slackware 14.0 has not been EOL'd yet, and it shipped with kernel 3.2.29 and Git 1.7.12. Does that mean that we need to support Git 1.7.12?

[bcmills]

The table at https://en.wikipedia.org/wiki/Git#Release says that Git 2.12 and older are themselves no longer maintained. (However, I'm having trouble finding any supporting documentation in the Git release notes or mailing list.)

[ianlancetaylor]

I suppose we could always vendor something like https://github.com/src-d/go-git . Not that I'm seriously suggesting that.

When it comes to GNU/Linux distros, I suggest that we can plausibly take CentOS as the trailing edge. CentOS is specifically adopted by people who want long term stability and who don't want to hack on their systems. We have decided that CentOS 5 is too old, so let's take CentOS 6 as the oldest version we want to support. CentOS 6 comes with git 1.7.1. I have no idea what is involved here: can we support git 1.7.1 and later without unreasonable effort?

[bradfitz]

I suppose we could always vendor something like https://github.com/src-d/go-git . Not that I'm seriously suggesting that.

It's probably inevitable that we go that route at some point. Maybe we should've from the beginning, in retrospect.

If CentOS is an OS that people deploy to but don't develop on, perhaps we don't need to care about its git version, assuming they just get their packaged binaries via Docker or scp or whatever.

But then one could make the same (incorrect?) assumption for Debian Jessie and Ubuntu 14.04 LTS, that people are more likely to deploy there than hack there themselves. But I just don't know if that's true.

I wish we had an opt-in mechanism like Debian's popcon (https://popcon.debian.org/) to let us collect statistics from Go users on their OS/versions/tool versions.

[mostynb]

GitHub suggests using 1.7.10 in their help[*]:
"There's no minimum Git version necessary to interact with GitHub, but we've found version 1.7.10 to be a comfortable stable version that's available on many platforms."

[*] https://help.github.com/articles/https-cloning-errors/

If a particular minimum tested git version is selected, perhaps it could be tested on a bot without distribution-specific git packages installed? That way the test would not be tied to a specific distribution, and any git version requirement changes would at least need to be made consciously from that point onward.

I wish we had an opt-in mechanism like Debian's popcon (https://popcon.debian.org/) to let us collect statistics from Go users on their OS/versions/tool versions.

Sounds like an interesting side project, but would require some thought to avoid privacy/GDPR/etc issues.

[rsc]

FWIW I don't think vendoring go-git is a good idea at all and I don't think it's inevitable we end up there. We should use the same VCS tools our users are, not ship our own slightly different tools with different bugs. Back before we started invoking git again we had a whole bunch of "git works why doesn't your tool?" kinds of bugs. I like that those are by definition gone.

Maybe this thread is not really focused on the right thing. Maybe we should define which Linux distros we support and then it's implied which git versions we need to support. (And someone could figure out the exact implication.)

Brad suggests:

• latest Ubuntu
• latest Debian stable
• latest RedHat Fedora
• oldest Ubuntu LTS still supported by Ubuntu

Anything else?

[ianlancetaylor]

CentOS, as mentioned above. We have already chosen to not support CentOS 5, because the kernel is too old. What about CentOS 6? (It's clear from the number of bug reports we get about CentOS 5 that people who use CentOS do care about Go.)