The current code for VERSION.cache results in output like
$ go version
go version devel +2937d88 2014-12-09 22:08:45 +0000 linux/amd64
Many git projects use git describe for this. For example, Git itself has https://github.com/git/git/blob/master/GIT-VERSION-GEN#L15 which, adjusted to lightweight tags and a different naming convention, would lead to:
$ git describe --tags --match "go[0-9]*" --abbrev=7 HEAD 2>/dev/null
go1.4beta1-394-g2937d88
Or even noting uncommitted changes:
$ git describe --tags --match "go[0-9]*" --abbrev=7 --dirty=+ 2>/dev/null
go1.4beta1-394-g2937d88+
As part of cmd/dist, it could look something like this:
$ go version
go version devel go1.4beta1-394-g2937d88+ linux/amd64
and this would also seem to make the explicit branch logic in src/cmd/dist/build.c unnecessary, as "git describe" can already look for tags.
This is useful (to me, at least) because it immediately communicates more than just that sha1 in the original; it tells me what tag I'm near, how far away from it I am, it includes the sha1 from earlier, and then can even mark dirty working trees so I know to suspect my build to be tainted.
The current code for VERSION.cache results in output like
Many git projects use
git describefor this. For example, Git itself has https://github.com/git/git/blob/master/GIT-VERSION-GEN#L15 which, adjusted to lightweight tags and a different naming convention, would lead to:Or even noting uncommitted changes:
As part of cmd/dist, it could look something like this:
and this would also seem to make the explicit branch logic in src/cmd/dist/build.c unnecessary, as "git describe" can already look for tags.
This is useful (to me, at least) because it immediately communicates more than just that sha1 in the original; it tells me what tag I'm near, how far away from it I am, it includes the sha1 from earlier, and then can even mark dirty working trees so I know to suspect my build to be tainted.