For what it's worth, I don't favor changing any of what's currently in
the version string, but I would consider extending it to be a good
idea, provided that adding the commit-ish doesn't make it unreasonably
long. I think the initial rNNNNNNN-DDDDDD should be extended with a
-<extra>, which could include the git commit-ish if building from git,
and perhaps just "-custom" if building from an svn checkout with local
changes. I don't think adding the "-dirty" is very useful for git,
since it doesn't let the developer who built it "find" those
uncommitted changes - they may have since been committed, or edited
further, but git can't tell you what commit object they might
correspond to, so there's not really anything useful to say about
them.

There was also some talk on IRC about generating, and including in
archive builds, a build-info.txt. This could contain a diff-stat for
the changes vs svn, the git commit-ish if building from git, and
whatever else might be helpful. Even if the commit-ish goes in an
extra file, I'm still inclined to favor commit-ish in version string,
because it allows a dev talking to a user with a test build to very
easily get information about that test build from them, just by asking
for the displayed version string. Assuming it's their build, or built
from a public repository, they can then find the exact set of changes
made to the svn revision on which the build was based.

-- 
Andrew Mahone
andrew DOT mahone AT gmail DOT com
Q: How many voters does it take to change a lightbulb?
A: None - if voting could change anything they'd make it illegal