On Fri, Jul 02 2021, Felipe Contreras wrote: > Ævar Arnfjörð Bjarmason wrote: >> Since 9a71722b4df (Doc: auto-detect changed build flags, 2019-03-17) >> we've been eagerly re-building the documentation whenever the output >> of "git version" (via the GIT-VERSION file) changed. This was never >> the intention, and was a regression on what we intended in >> 7b8a74f39cb (Documentation: Replace @@GIT_VERSION@@ in documentation, >> 2007-03-25). >> >> So let's add an ASCIIDOC_MANVERSION variable that we exclude from >> ASCIIDOC_COMMON. The change in 9a71722b4df was only intending to catch >> cases where we e.g. switched between asciidoc and asciidoctor, not to >> undo the logic in 7b8a74f39cb and force a re-build every time our HEAD >> changed in the repository. > > Once again, why do we care that the version is 2.32.0.98.gcfb60a24d6 and > not 2.32.0.97.g949e814b27? > > Not just in the documentation, but everywhere. It's useful e.g. on my Debian system to see that the "next" Debian packaged is 2.31.0.291.g576ba9dcdaf in docs & "git version", arguably less so for documentation. But yeah, I think we should at least have some opt-out for sticking the exact version everywhere, given the mostly unless re-building it does during development. > Maybe we can add a GIT_RELEASE variable that unlike GIT_VERSION it > doesn't contain the precise commit. For example GIT_RELEASE = 2.33-dev. I just added this to my pre-make script: grep -q ^/version .git/info/exclude || echo /version >>.git/info/exclude echo $(grep -o -P '(?<=^DEF_VER=v).*' GIT-VERSION-GEN)-dev >version It makes use of GIT-VERSION-GEN picking up a tarball "version" file. So far it seems like Junio isn't interested in the patch, and in any case it doesn't fix the more general over-rebuilding due to version changes noted upthread when it comes to *.o and libgit. Doing this fixes both for me. Then when I build an installed version I don't use that trick.
