Jan Engelhardt (jengelh@inai.de) wrote:
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?)
Nope, I'm an XFCE guy these days ;-)
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.
Sure, but that's a very brittle design. It just takes a single non-release tag to break the mechanism.
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".
Heh :-)
You won't see it everyday, but it is possible.
Sure - but when would it *ever* happen in the real world? Let's focus on scenarios which are relevant.
Tag offsets are resistant to this (though there are other constructible cases where they become useless).
Right. Like I said above, someone creating a non-release tag without realising it would break the packaging mechanism is a very likely scenario. Someone explicitly setting GIT_COMMITTER_DATE is somewhat less likely :-)
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)."""
That's not a bad idea. Pull requests to tar_scm are welcome.
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.
That's like saying cars are a bandaid for ensuring quicker transport.
Move the hash from Version to Description, and you will no longer need the bandaid.
That doesn't make any sense. Moving the hash to %description wouldn't affect the ordering at all. You still need something to order versions.
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
They're not bandaids, because they're not fixing anything which is broken. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org