Hi > The sha1 is useful to people who need to quickly tell developers which > version they are running when they're from git. Removing it is a bad > idea.
You can get the commit from the version number even without the SHA1, something like: git log --oneline $VERSION..$BRANCH | tail -n $REVISION | head -n 1 Where $BRANCH is the one used in PKGBUILD (usually it is HEAD). Anyway VCS-package users suppose to follow HEAD version closely. In those rare cases when a user sees problem in no-release non-HEAD version and tries to contact upstream developers I bet the first question from the developers will be "Could you please update to HEAD and see if the problem still exists?". > The main issue with -git versioning is the inconsistency. The proto > file for it is terribly out of date, not everyone respects whatever > flavour of the recommended way is current, and not every git > repository has tags (creating a need for two different functions, the > need of which cannot be told until build time). A further issue arises > from that, which is that repositories without tags may get tags later > on and the package maintainer may not know about that (leaving the old > versioning in), or using the new versioning may break versioning for > other packages. > > I'm not suggesting we drop the pkgver function (nobody is). I'm saying > we need a standardized pkgver script that outputs consistent, > compatible results between tagged and non-tagged git repos, and > recommend that as the proto. To that end, I liked the proposal of > 0.7.r19.ge4e6e20 vs 0.r19.ge4e6e20. > > J. Leclanche
