Re: gnulib-tool --version

[Jim Meyering]

Eric Blake <address@hidden> wrote:
> According to Bruno Haible on 3/14/2008 5:52 PM:
> |   This does not tell me anything. If in 6 months sometimes says "my gnulib
> |   is version 0.0.430-8915-dirty", how do I find out what date it is?
>
> git log 8915

If that is ambiguous, find the SHA1s with that prefix and
run git-describe on each of those, then choose the one
that is nearest-to-but-preceding 0.0.430.

> |   Also, the suffix "-dirty" is a bit offensive. How about "-unreleased" or
> |   "-dev", or "-alpha" or "-cuttingedge", or "-mm" (for Linux fans :-)?
>
> That's something for Jim to decide, with the git-version-gen script.  But
> given those options, I like '-dev'.  At any rate, the '-dirty' suffix is
> only present if you have uncommitted changes still in your tree.

I agree that "-dirty" is a little annoying, but think of that as a feature ;-)
It might encourage people not to use a version labeled "-dirty".
Besides, it's shorter than "-modified".  "-dev" sounds too much like
it could be something legitimate or reproducible, like a version from
a public development branch.

> | - In a cvs checkout
> |     $ cvs -d :pserver:address@hidden:/gnulib.git co -d
> gnulib HEAD
> |   I get
> |
> |     $ ./gnulib-tool --version
> |     ./gnulib-tool (GNU gnulib) UNKNOWN
>
> Again, the git-version-gen script could probably be made smarter in a CVS
> checkout, and it would benefit more than just gnulib-tool.

I won't disagree.
Maybe someone who uses cvs a lot would be interested will
propose a patch.  However, I hesitate to make the existing
script VC-agnostic.  The next requests will be for mercurial,
svn, and bzr support.  For now, it's small and simple...
it may be best to keep it that way, unless there's a strong
argument to the contrary.