Open bcmills opened 6 years ago
Marking NeedsDecision to determine:
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?
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
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.
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:
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.)
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?
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.
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.
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:
Anything else?
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.)
@ianlancetaylor, do you have any sense for whether people develop on CentOS vs just deploying to CentOS?
If we only care that resulting binaries work well on CentOS 6, that's easier than making sure "go get" and friends work with old git versions.
@bradfitz Yeah, I forgot about that question. I don't know.
Maybe we should define which Linux distros we support and then it's implied which git versions we need to support.
This feels like the most practical thing to do, not least because we can use a number of Docker/other images as test rigs, e.g. https://github.com/golang/go/issues/26988#issuecomment-412939699.
oldest Ubuntu LTS still supported by Ubuntu
I think this covers Travis and CircleCI. Put another way, I think it's worth making sure we have coverage of the major (to be defined) CI systems out there to ensure they are covered, and add their images/base images to the list if not.
Even if there was to be a list of Linux distros enumerated, it seems there would still be a need to pick a minimum supported git version to handle Windows, Macs, etc.?
It seems picking a git version would be more direct than picking a list of distros, including given the most immediate triggering event here seems to variability in git behavior across old versions.
For a developer who is "stuck" with an older environment for whatever reason, it is probably easier to upgrade git than to switch distros or upgrade their OS, which means having the restriction based on git might be friendlier to Go users.
That said, perhaps the conclusion ends up being both a git version and a list of distros get selected?
If there is a list of Linux distros enumerated, I would hope it would be made extremely clear that it is not a contraction of where Go code can run once compiled but rather a contraction of where the Go tooling is supported.
In terms of CentOS, I've definitely seen a common pattern of RHEL for production with CentOS for dev/QA (because very close to RHEL).
However things are end up being characterized in terms of what is officially supported, a related question would be whether or not anything is validated, and if so, whether a failing result is a warning vs. error vs. ___.
@bcmills can you describe what sorts of things break when using an older version of a VCS tool?
Also would the go tool enforce or otherwise check the version and give a helpful error message?
can you describe what sorts of things break when using an older version of a VCS tool?
The typical failure mode is that we add some flag (e.g. to disable one of the many ways that user settings can leak in to the behavior of git archive
) and it turns out that the flag isn't present in some older version still in use. Then that whole command fails, or (less frequently) git
ignores the flag and our fix is ineffective on that version.
Also would the go tool enforce or otherwise check the version and give a helpful error message?
If we know some version that we definitely don't support, we could emit a helpful error. If we know what version we do support, then perhaps we could emit a helpful message only if the command fails (analogous to the behavior for #28221).
As far as proposal process, everyone seems to agree we should do this - define which VCS we support. The exact details can be worked out as a regular issue. (See also https://github.com/golang/go/issues/26746#issuecomment-412652354 above.)
I have no idea if we use - from the go command - git options added since Git 1.7.1. One option is to say that CentOS 6 can be a deploy target but not a development target (at least for 'go get').
Can someone find out whether 'go test cmd/go/...' succeeds on CentOS 6 with git installed? (If there's no git at all, the tests will be skipped entirely.)
Can someone find out whether 'go test cmd/go/...' succeeds on CentOS 6 with git installed?
I'll take a look.
I spun up a CentOS 6 image and installed git
and gcc
at the default versions using yum install
, then installed go1.11.2
from the pre-packaged binaries on golang.org and ran go test cmd/go/...
.
There were many failures, mostly related to Git commands.
I'm doing to try from HEAD
next; I expect about the same number of failures but perhaps more-useful error messages.
At go version devel +d1882c9 Wed Dec 12 19:33:05 2018 +0000 linux/amd64
, it's about equally dire.
I wanted to get a view of what might be a sensible cut-off for a minimum supported git version based on what modules users are using in practice.
Based on spending a couple of hours on this today, my observations included:
A large number of complaints about git versions >= 2.7.4
not working.
A small number of complaints about 1.x git versions not working, such as 1.7.1
, 1.7.2
, 1.7.x
, 1.9.1
.
No complaints about git versions in the range > 1.9.1
and < 2.7.4
.
Just because I found no complaints for a version range does not mean there were no complaints, but that sampling of results might suggest where the largest weight might be.
I ended up reading a small number of older issues carefully, and skimming comments from a larger set of issues:
Here is a programatically generated list of mentions of git versions from comments in issues with the modules
tag. This is surely an incomplete view, but might at least give a flavor:
While I am sure you don't want a bunch of people saying which distro they use, I will call out mine since it was questioned above. My company currently is developing and deploying on CentOS/Redhat 6, because of its long term stability.
Also from a developers perspective, It would be a lot easier to see which OSes are supported period, rather than which is supported for development vs deployment.
Change https://golang.org/cl/191978 mentions this issue: cmd/go/internal/get: remove '--' separator from 'git ls-remote' command
Maybe we should define which Linux distros we support and then it's implied which git versions we need to support.
I've been thinking about this some more (in the context of #51253). Our own release policy doesn't determine which Go releases we support based on the (much older) versions that Linux distros choose to ship; we expect users to upgrade to a supported Go version if they run into trouble.
Why should we not expect the same of the rest of their development environment? If users are running ancient versions of other parts of the development toolchain — perhaps with third-party security patches — can't they also run third-party-patched ancient versions of the Go toolchain to match?
According to the table at https://en.wikipedia.org/wiki/Git#Releases (and supported by the tags shown at https://github.com/git/git), Git 2.17 received a patch release last year (2.17.6, tagged 2021-03-09), whereas Git 2.16 was last tagged over two years ago (2.16.6, tagged 2019-12-07). The 2.17.6 release was presumably for CVE-2021-21300, for which “the earliest impacted version is 2.14.2”. Since there were no mainline patch releases tagged for that issue for Git 2.14 through 2.16, I infer that those minor releases are no longer supported upstream.
It has been suggested above that we use CentOS as the baseline for supported development environments, but it's not even clear to me which CentOS versions we should be considering. According to the CentOS wiki page, CentOS 7 stopped receiving “full updates” in August 2020, although it continues to receive “maintenance updates” through June 2024. And although @bradfitz filed #29114 to add a CentOS builder in December 2018, that still hasn't happened either — so actually supporting Go on CentOS 7 would require additional development overhead, since we can't just spin up a gomote
to test a potential fix.
We do not currently have a builder with Git version 1, and the documentation at https://git-scm.com/docs seems to only go back as far as 2.10.5.
Lacking both a builder and documentation, I plan to adhere to the following policy:
git
version that we will actively support in cmd/go
is the oldest version for which the Go project has a builder, but we will accept changes to fix older versions provided that those changes can refer to reliable documentation for the version being fixed.
gomote
), new Go builders that have a git
binary should be upgraded to at least Git 2.17.6.
cmd/go
support in #47308.just to note, go
tool no longer works on RHEL7 / CentOS7 because it has git version 1.8.3.1
by default. RHEL7 is on the "Maintenance Support 2 Phase" by RedHat until June 30, 2024. Probably some Go users in some corporate environments would love to be able to use go
until that date without having to take extra steps to install git-2.x from RHSCL [3] 😄 .
[1] https://access.redhat.com/support/policy/updates/errata#Maintenance_Support_2_Phase [2] https://access.redhat.com/support/policy/updates/errata#Life_Cycle_Dates [3] https://access.redhat.com/solutions/2075603
cmd/go
shells out to version control binaries to implementgo 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 (https://github.com/golang/go/issues/26653).We should be explicit about which versions are supported for use with the
go
command.(CC: @rsc @ianlancetaylor @bradfitz @myitcv @rogpeppe @trashhalo)