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