Greg Stark <stark@mit.edu> writes:
> It would also be nice to have a tag or branch name for the development
> branch.
Uh, the branch name is "master". I doubt we want to change that.
And you can't really have a tag on a branch, AFAIK --- a tag names
a specific commit and can't ever be moved. I think the fundamental
difference between tags and branches is exactly that a branch is a
movable commit-pointer while a tag is fixed.
> Right now git-describe --tags on a random revision between 9.4
> and 9.5 will print something like REL9_4_BETA1-1973-g85c25fd or
> something like REL9_5_BETA2-33-g55a2cc8 if it happens to be after a
> beta. It's really hard to tell what release the revision you're on is
> actually between from that.
That command is kinda useless AFAICT :-(
> There's also a git feature I just noticed called "annotations". Tags
> can be "annotated" with a commit message and then git describe will
> only use those and skip other tags that are not annotated. Currently
> we appear to have no annotated tags. (which confuses me because there
> are clearly commit messages for the tags with logs like "Stamp
> 9.5alpha" c.f. f78329d594c2fe893f9174d5b3da7d3fbc6dd8b6)
Those commit messages are for the stamping commits, ie the ones that
put a new version number into configure.in and so on. Tags get applied
to those commits after the fact, once we've verified that tarballs made
from those commits are publishable. That is, the tags are meant to mark
which tree state the published tarballs were actually made from. It has
happened that we've fixed something and re-wrapped after the stamping
commit, in which case the tag would be placed on a later commit.
I was just wondering whether it would be worth starting to use "git tag -a".
It doesn't seem to buy much, and if it would cause git describe to ignore
all non-annotated tags, I should think that that's a misfeature.
> It would be nice if git describe on a random revision between 9.4 and
> 9.5 always printed something like REL_09_05_DEV-* which indicated it
> was some revision committed after 9.4 was branched and before 9.5.0
> was released. (That would sort incorrectly so maybe some further tweak
> is needed?)
I think you need to file a feature request with the git folk.
regards, tom lane
