git_describe() and --dirty
Zeex opened this issue · 10 comments
It seems that git_describe() can't be used with --dirty - it will always return -128-NOTFOUND. When running the same command from the command line yields this:
$git describe HEAD --dirty
fatal: --dirty is incompatible with commit-ishes
So basically git doesn't like that we're passing both hash and --dirty. I don't see why we have to pass commit hash to git describe in git_describe(), by default git will just assume HEAD.
Or is it because cmake is re-run only after a commit is done and that makes --dirty basically useless?
Well, the script is set up to trigger a CMake re-run if a commit is done. Not sure about --dirty, haven't used it myself, though it does seem useful: is that a feature of only newer git versions? I could see changing the logic so that if we are just looking at head, we omit the commit and pass --dirty.
No it's not new, I remember using git describe --tags --dirty for years.
Would like to see this supported as well. Preferably it would also automatically re-run CMake if the repo changes from dirty to clean state and vice versa.
Hi, seems that this issue is still present. Maybe some more information here about this modification: https://stackoverflow.com/questions/16035240/why-is-git-describe-dirty-adding-a-dirty-suffix-when-describing-a-clean-ch
I'll try to fix this.
The issue is still happening. If I prepare a patch just removing the hash from the call to git_describe would you merge it? I don't see a use-case for calling git-describe with anothe parameter than HEAD.
Something like this works for my use-case:
0001-cmake-fix-git_describe-not-working-with-dirty.txt
Edit: this does NOT work. Removing the hash from the list of parameters has the side-effect that cmake does not re-generate the version string when the git commit changes.
I also recommend removing "ERROR_QUIET". Failing the build with the git error visible in the logs is better than silently printing "128-NOTFOUND" as a version string in my opinion.
agreed on ERROR_QUIET
There is now a git_describe_working_tree that does a git describe --dirty without the fancy commit-ish magic of the normal function. I think this should solve things.