GitLab

In tor_version_compare, the git logic is a bit weird, because git tags are hashes: the ordering we apply isn't their true order. So the function comment should probably become:

/** Compare two tor versions; Return <0 if a < b; 0 if a ==b, >0 if a >
* b. Git tags are sorted by length, then value. */

But this doesn't match version-spec.txt:

The EXTRA_INFO is also purely informational, often containing information
about the SCM commit this version came from. It is surrounded by parentheses
and can't contain whitespace. Unlike the STATUS_TAG this never impacts the way
that versions should be compared.

We should try to ignore the git tag, or at least be very careful how we compare it. Due to bugs like legacy/trac#20492 (moved), the following versions are equivalent:

Tor 0.2.9.9 (git-56788a2489127072)
Tor 0.2.9.9

(But these are not equivalent to any other git tag on Tor 0.2.9.9, which should never happen anyway.)

This is important when we try to exclude versions, like in legacy/trac#20509 (moved), because we need to exclude the version with and without the git tag.

This fix might require a new consensus method.