patchGIT-VERSION-GEN: Use standard versioning suffix

In snapshot builds of git, git-version uses a modified variant of the git-describe output, e.g. 2.51.0.178.g2462961280 instead of 2.51.0-178-g2462961280 for seemingly historical reasons.

This is not semver compliant which makes the output harder to parse in tooling such as b4, which currently errors out when using a snapshot build of git.

For snapshot builds, use as version string the unmodified git-describe output with only the leading v stripped from the tag.

Fixes: 5c7d3c9507f7 ("Allow building of RPM from interim snapshot.")
Signed-off-by: Jonas Rebmann <jre@pengutronix.de>
---
 GIT-VERSION-GEN | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

On 2025-09-05 at 12:14:38, Jonas Rebmann wrote:

Git doesn't follow SemVer. We make breaking and incompatible changes without bumping the major version all the time, so it doesn't make sense to say that we should follow SemVer for version numbers.

I would say that since Git has had this version number format for a long time, b4, which is much newer and should be designed to work with Git, should gracefully handle the Git version number rather than have Git conform to b4.

On 2025-09-05 14:19, brian m. carlson wrote:

I meant the lexical format of semver, rather than its semantics, and the way that snapshot-version suffixes are separated in particular. The output of git-describe already aligns with the semver syntax so it seems reasonable to expect that `git version` of a snapshot build would follow the same syntax, which has become quite common, and for which parsers are ubiquitous.

The change in 2006 (commit 5c7d3c9507f7) aimed to make versions monotonic for RPM packaging but the resulting format doesn't seem to conform to a known version string format, and not to today's RPM-packaging guidelines either looking at [1].

Is this really Git's version format, or just how git-version happens to print in snapshot builds? Is this format used or depended on anywhere else?

I agree that b4 must follow what git-version outputs and I sent a patch for b4 [2] but each tool having to implement custom parsing for only the specifics of the git-version output (as opposed to git-describe which follows a common format) makes integration needlessly difficult.

Regards, Jonas

[1]: https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/ [2]: https://lore.kernel.org/tools/20250905-versionparse-v1-1-48d926da9c10@pengutronix.de

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

Well said.

If somebody cares about the format deeply enough to patch it, it is likely that somebody else cares equally deeply about the current format and depends on it, as Git these days are used by more than a few thousands of people, and "semvar syntax" is too weak a reason to change it for everybody.

If somebody wants to have their own versioning scheme, there is an escape hatch to drop the "version" file in their source material, which does not have to change versioning schemes used by other builders with a patch like this one.

Thanks.

Hi

The following might not be immediately relevant in light of what brian just wrote.

On Fri, Sep 5, 2025, at 14:14, Jonas Rebmann wrote:

For other readers: this can be traced back to from

• `git log -S'VN=$(echo "$VN"' GIT-VERSION-GEN`
• which finds 374dfaa2e39 (Make GIT-VERSION-GEN tolerate missing git
  describe command again, 2006-01-26)
• which in turn references this 5c7d3c9507f (Allow building of RPM from
  interim snapshot., 2006-01-16)

This project doesn’t use this Kernel-style trailer.[1] Also not the commit reference style. (It uses `git show -s --pretty=reference <commit>`)

It’s more common to place it inside the body of the message. Like a replacement for the preceding “historical reasons”.

† 1: It’s almost only trailers which attribute people. (I am having a hard
    time coming up with exceptions; you can find at least 
    one Cherry-picked-from)