proposal: support specifying a commit ref instead of master

[myitcv]

Have the ability to build go tip is great, but building against the current master commit is not particularly useful because that's a moving feast.

Instead it would be useful to be able to specify (in .travis.yml files) a specific commit.

[philpennock]

This is supported in master already, will be part of the upcoming 1.5.0 release, whenever Travis decides to cut that.

[philpennock]

% eval "$(./gimme 0dcdbc772e62)"
go version devel +0dcdbc772e Wed May 2 17:36:17 2018 +0000 darwin/amd64
%

[myitcv]

Thanks @philpennock - look forward to this landing in Travis.

[myitcv]

Quick question: will this effectively pull a cached build, or will it rebuild from commit X each time?

[philpennock]

gimme only pulls builds when doing binary installs. Gimme will locally cache builds but has no distributed caching support. We do not currently support re-using a cached build of a git revision, here's the comment I wrote at the time:

# We do _not_ try to use any version caching with _try_existing(), but instead
# build afresh each time.  We don't want to deal with someone moving the repo
# to other-version, doing an install, then resetting it back to
# last-version-we-saw and thus introducing conflicts.
#
# If you want to re-use a built-at-spec version, then avoid moving the repo
# and source the generated .env manually.
# Note that the env will just refer to the 'go' directory, so it's not safe
# to reuse anyway.

We use one common directory ~/.gimme/versions/go for all these builds and there's no way to guarantee the status. There are things we can do to improve this, but we don't have them yet.

[philpennock]

Filed issue #147 to ask for feedback on level of interest in reusable revision-specific builds, and propose one solution.