Eric Blake <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]:/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.
