cmake: more deterministic git describe --abbrev=12

[marc-hb]

Hardcode --abbrev=12 not to depend on personal git config preference.
12 is deemed large enough for the Linux kernel which should leave some
room:
https://public-inbox.org/git/[email protected]/

Add --dirty because it should be the default: who likes to be duped into
thinking they're debugging an exact version when they're not?

Signed-off-by: Marc Herbert [email protected]

[codecov-io]

Codecov Report

Merging #13608 into master will decrease coverage by 0.03%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master   #13608      +/-   ##
==========================================
- Coverage   52.34%    52.3%   -0.04%     
==========================================
  Files         307      307              
  Lines       45350    45350              
  Branches    10464    10464              
==========================================
- Hits        23737    23721      -16     
- Misses      16865    16877      +12     
- Partials     4748     4752       +4

Impacted Files	Coverage Δ
subsys/testsuite/ztest/include/ztest_assert.h	35% <0%> (-35%)	⬇️
subsys/testsuite/ztest/src/ztest.c	65.28% <0%> (-7.44%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 992f29a...b40d6d0. Read the comment docs.

[SebastianBoe]

+1 to --abbrev=12, the build should be system-independent.

-1 to --dirty

I often test patches that I expect will not have an affect on the hex file by doing:

build --build-dir=b_0
git stash
build --build-dir=b_1
kdiff b_0 b_1

without --dirty I can verify that my stashed patch did not corrupt the build, but with --dirty I can not.

Presumably, the BUILD_VERSION exists for non-developers to be able to identify their build, any developer worth his salt will not distribute a build with a dirty working directory, so the --dirty flag is not needed in production, and harmful for developers that test like me.

[marc-hb]

Thanks everyone for the review.

build --build-dir=b_0
git stash
build --build-dir=b_1
kdiff b_0 b_1

without --dirty I can verify that my stashed patch did not corrupt the build, but with --dirty I can not.

Interesting, I didn't think of that use case. Making a whitespace change after the git stash would be a simple workaround but I get your point.

To solve the same problem I typically do something "git add builddir/" and revert / comment out the source changes "manually" instead of using git stash. Then I can keep using all the same and usual set of git diff options than for source code. For non-trivial commits I tend to want finer-grained "revert" abilities anyway, git stash is too coarse and wouldn't work. For coarse reverts I git checkout HEAD~

any developer worth his salt will not distribute a build with a dirty working directory,

Depending on what you mean by "distribute" this is actually quite frequent, for instance when several people debug the same hardware and change the code (debug statements, others) frequently. Or even just one person interrupted by meetings or other context switches.

Anyway --dirty is unrelated to the this topic so I'll remove it. Maybe I'll try to make it optional in another PR.

[marc-hb]

The last force push doesn't show any difference because github can apparently not compare commit messages. Doh.

[SebastianBoe]

@carlescufi : This is ready to be merged.