Use a proper fallback when git describe fails

[wilzbach]

#6935 broke CircleCi on Phobos, because now git describe failures lead to hard errors and abortion of the build process.
The fix even removes two lines :)

CC @CyberShadow @MartinNowak

[dlang-bot]

Thanks for your pull request, @wilzbach! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.

Some tips to help speed things up:

• smaller, focused PRs are easier to review than big ones

• try not to mix up refactoring or style changes with bug fixes or feature enhancements

• provide helpful commit messages explaining the rationale behind each change

Bear in mind that large or tricky changes may require multiple rounds of review and revision.

Please see CONTRIBUTING.md for more information.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

[wilzbach]

How to reproduce:

git clone --depth 1 -b stable https://github.com/dlang/dmd 
cd dmd && make -f posix.mak all

[CyberShadow]

How about using --always?

[MartinNowak]

How about using --always?

That's only the commit hash.

[CyberShadow]

That's only the commit hash.

Err, no it's not? I mean it is if it's a shallow clone, but you could still combine it with VERSION if you wanted to. Using VERSION without anything else seems a bit more misleading as it can then be confused with a tagged release.

[wilzbach]

Eww due to #6940 the version change is now also in master and breaks new CircleCi builds :(
-> #6942

[MartinNowak]

Using VERSION without anything else seems a bit more misleading as it can then be confused with a tagged release.

That's our fallback, e.g. for non-git repos, is it really worth having another fallback (e.g. v2.074.1-ddd-722b169) for shallow git clones? Also would require extra fiddling to distinguish different git describe failures.