Jan Engelhardt (jengelh@inai.de) wrote:
On Saturday 2014-01-11 12:56, Adam Spiers wrote:
No need to grab the base separately, just use --long:
Grabbing the base separately is necessary to catch the (braindead) case that you have a tag called "v3.4-5-g1234567". If you just run git describe, you therefore could not determine whether your current HEAD is (v3.4-5-g1234567)-0-g9876543 or (v3.4)-5-g1234567.
Like I said, --long solves that case, because it *always* outputs the long format, so there is no ambiguity.
For example, if a non-release tag is introduced into the repository, how would you ensure that the tag-offset doesn't suddenly drop back to zero?
git describe --match=
One would at least hope you name your release tags reasonably unique that they are programmatically distinguishable from nonrel tags (that would also be worthwhile from a human perspective).
So to be clear, you are suggesting a generally applicable technical solution based on hope?
I am suggesting that people not turn off their brains.
You don't just make a non-release tag and give it a name like a release tag.
OK, so let's assume I have a bunch of tags like: v1.0.1 v1.0.2 etc. We are looking for a programmatic solution which can be automated by tools such as tar_scm. You are presumably suggesting to use something like git describe --match='v[0-9]*.[0-9]' right? But there is no pattern which for release tags, and non-release tags, therefore you are introducing the requirement for a custom glob per project. And this glob is necessarily brittle, because very often the person maintaining the upstream repository containing the tags is different to the person maintaining the downstream package, and will have zero awareness that someone else is hoping they will ensure that a) all their release tags match this glob, and b) none of their non-release tags match this glob. Furthermore, this would mean that the tar_scm source service would require an extra parameter (which only applies in the git case). It also would require a patch to tar_scm to add support for your tag offset mechanism. I believe in freedom of choice, so I would gladly accept a pull request from you which supports that scheme, in order that people like yourself can use it. However, in contrast, the timestamp approach already works out of the box with tar_scm, and has none of the brittleness described above. So IMHO it's a better scheme to recommend in the guidelines wiki page.
Regardless, that is not a valid solution, because it breaks instantly when the first tag is introduced to the repository.
And why would that be?
Because the tag offset will reset to zero, violating the requirement that it increases strictly monotonically. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org