If source line contains fragment, e.g. {{ic|source&#61;("$pkgname::git://path.git#branch&#61;name")}}, offered version will not work correct. User may forget to fix it (from master to specified branch or commit). My version lacks this bug.

−

cd local_repo

+

−

<s>− git rev-list --count HEAD</s>

+

Cons:

−

+ echo $(git rev-list --count master).$(git rev-parse --short master)

+

Don't see. But I'd like this fix to be reviewed if I miss something. Bug in such example may hurt many package maintainers.

−

}

+

−

- [...]

+

== More on git pkgver()'s ==

−

|1142}}

+

−

That's good but you left the title and the sample output intact. Also, the first example still uses {{ic|git describe --always}}.

+

I would also like to see packages use pkgver fucntions like this:

+

+

git describe --always --long | sed -E 's/([^-]*-g)/r\1/;s/-/./g'

+

+

so they are more friendly to vercmp.

+

Current behaviour using git-git as an example:

+

+

current ver: {{ic|1.8.2.210.g123abc-1}}

+

next ver: {{ic|1.8.2.1.50.g123abc-1}}

+

vercmp 1.8.2.210.g123abc 1.8.2.1.50.g123abc

+

1 # the first is greater than the second

+

+

Right now, the current version is actually greater than the new version, causing a downgrade. If {{ic|r}} is appended to the patch level (the numbers just before the g<hex> bit), then vercmp would order the versions correctly.

checking out branches/tags needs clarification

The #fragment part of the VCS source URL has a different meaning for each type of VCS.
This can be confusing for people, especially when they are trying to checkout a specific branch or tag.
Examples would reduce the chance for confusion a lot.

fictional examples for git and svn (don't have experience with bzr or HG)

Pros:
If source line contains fragment, e.g. source=("$pkgname::git://path.git#branch=name"), offered version will not work correct. User may forget to fix it (from master to specified branch or commit). My version lacks this bug.

Cons:
Don't see. But I'd like this fix to be reviewed if I miss something. Bug in such example may hurt many package maintainers.

More on git pkgver()'s

I would also like to see packages use pkgver fucntions like this:

git describe --always --long | sed -E 's/([^-]*-g)/r\1/;s/-/./g'

so they are more friendly to vercmp.
Current behaviour using git-git as an example:

current ver: 1.8.2.210.g123abc-1
next ver: 1.8.2.1.50.g123abc-1

vercmp 1.8.2.210.g123abc 1.8.2.1.50.g123abc
1 # the first is greater than the second

Right now, the current version is actually greater than the new version, causing a downgrade. If r is appended to the patch level (the numbers just before the g<hex> bit), then vercmp would order the versions correctly.

current ver: 1.8.2.r210.g123abc-1
next ver: 1.8.2.1.r50.g123abc-1

vercmp 1.8.2.r210.g123abc 1.8.2.1.r50.g123abc
-1 # the first is less than the second