On Tuesday 2013-09-10 19:05, Adam Spiers wrote:
It's certainly not rare in my usage, and I don't think I'm unusual.
Maybe that is prominent in the projects you look over (GNOME or something?), but it certainly is not the case for what I have on my lookouts. systemd, kmod, "those things", they generally only have release tags in their repos.
There are plenty of good reasons for using tags other than releases.
But it sounds like you are making the same point I already made - git describe output is not a remotely reliable source for version ordering.
It is, if you pay attention or trusting the tags.
If there will never be tags for anything but marking tarballs, then trusting the tags is ok and `git describe` will always output something useful. In case of suse-kernel, one may try `git describe --match="rpm-*" to limit what tags can actually be used for bases.
The timestamp + SHA combination is deterministic and unique, sorts chronologically
Deterministic and unique, yes, but %ct is not strictly guaranteed to be strictly monotonically increasing. That is to say, you can construct a case where %ct is useless.
Interesting - please can you provide an example?
$ GIT_COMMITTER_DATE="1970-01-01 00:00:00" git ci -m \ "Initial commit for Unix :)" [master 7db0cff] Initial commit for Unix :) 1 file changed, 1 insertion(+) Note I how said "constructed case". You won't see it everyday, but it is possible. Tag offsets are resistant to this (though there are other constructible cases where they become useless).
Simiarly, one can construct cases where a tag offset becomes useless. But excluding the cases where {either %ct or tag offset is uselees}, a tag offset is shorter than %ct.
What about the cases where tag offsets cannot be generated at all, due to the lack of any tags?
I'll just quote the thing I recently placed into the wiki and already used in a number of (upstream-)nascent packages: """an alternative monotonically increasing identifier can be obtained by using the history root as a base (`git rev-list 9265358 | wc -l`), useful for when a project is in such an early stage that there have not been any releases yet (Version: 0~git123)."""
and trying to work around it with either %ct or tag offsets is just a bandaid. If the hash is gone from Version, so is the need for the sorting bandaid.
Huh?? The hash is not there to help with sorting.
The hash does not contribute to sortability. %ct is a bandaid for ensuring sorting order. Tag offset is a bandaid for ensuring sorting order. Move the hash from Version to Description, and you will no longer need the bandaid. But I do accept your argument that telling users in a second step to re-run `rpm -qi` may be asking too much of them. So it seems we are to live with sorting bandaids :p -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org