cmd/go/internal/get, x/tools/go/vcs: sync vcs package

[adg]

Now that we have internal packages we should make the go tool use an internal copy of the vcs package from the tools repo, so that we can keep the two in sync.

[bradfitz]

Totally.

[rsc]

I will leave this open but please don't. Code duplication is not the end of the world. In particular the minimal duplication here seems preferable to more complexity in the build. I don't even think the public package vcs API is enough for the go command, but that's a separate issue.

[nightlyone]

At the moment they drift apart already. E.g. the version distributed with the go binary has quite sophisticated git support, which is missing (and thus a subtle broken) in every tool using tools/go/vcs.

[lrewega]

I think there are two separate issues:

1. The behaviour of go's internal vcs and the vcs in tools differ, especially with git. This makes it difficult for the authours of 3rd-party tools to match the behaviour of the go command.
2. The go tool could use an internal copy of vcs from tools to avoid duplication and future drift issues.

I think the first issue has a simple solution: update tools by applying the relevant changes made to go's internal vcs.

The second issue may be worth debating. @rsc already indicated that he'd rather not add more complexity to the build. Looking briefly, it doesn't appear too difficult to have the go command use the public API, though some breaking changes would likely have to be made. I am not sure what the policy is for x/tools. Then x/tools/go/vcs could be bundle'd into internal/. This approach definitely feels pretty kludgey over all. I am also unsure of the long-term vision for breaking out useful functionality from go tools.

Can we split this issue? I would at least like to see/make headway on the first part, and cannot think of any reasons to object.

[gopherbot]

CL https://golang.org/cl/21342 mentions this issue.

[gopherbot]

CL https://golang.org/cl/21345 mentions this issue.

[gopherbot]

CL https://golang.org/cl/21795 mentions this issue.