Gitea fails to start with git 2.29.0.rc0.261.g7178c9af9c

[wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf]

• Gitea version (or commit ref): Gitea version 1.13.0+dev-743-ge0b772780 built with GNU Make 4.3, go1.15.2 : bindata, sqlite, sqlite_unlock_notify
• Git version: 2.29.0.rc0.261.g7178c9af9c
• Operating system: Arch Linux and Fedora 33
• Database:
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Not relevant
• Log gist:

Oct 07 19:24:10 nebula gitea[27964]: 2020/10/07 19:24:10 cmd/web.go:108:runWeb() [I] Starting Gitea on PID: 27964
Oct 07 19:24:10 nebula gitea[27964]: 2020/10/07 19:24:10 ...s/setting/setting.go:804:NewContext() [I] Default UI Location is Europe/Vienna
Oct 07 19:24:10 nebula gitea[27964]: 2020/10/07 19:24:10 ...dules/setting/git.go:68:newGit() [F] Failed to initialize Git settings%!(EXTRA *log.ColoredValue=Git version missing: Malformed version: 2.29.0.rc0.261.g7178c9af9c)
Oct 07 19:24:10 nebula systemd[1]: gitea.service: Main process exited, code=exited, status=1/FAILURE

Description

Gitea fails to start after a recent update, I suppose the reason might be an error in parsing of the git version string, as it recently moved on to an rc for 2.29.0 (see git version above) and changed the format a little - note the added rc0.
A rollback to an earlier version of git (git version 2.28.0.788.g542b3c2573 - which has been working just fine before) as well as to a previous release version (such as 2.28.0) solves this for me momentarily and Gitea starts without issues.

[wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf]

Also, we have already seen something similar in #12731 before.

[6543]

I tryed to enhance the regex again, didnt found a good soultion for now :(

[wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf]

I tryed to enhance the regex again, didnt found a good soultion for now :(

I'm trying something, too.

[eneuschild]

Please ignore that PR from me for this issue. Some autocomplete feature ran amok and linked the wrong issue.

Sorry for the confusion. :-|

[eneuschild]

... but now that I'm here, I might as well look into the issue.

I did some tweaking of the RegEx myself and actually quickly found one that worked.
But: the upstream project insists that versions validated with it follow SemVer, which, unfortunately, 2.29.0.rc0.261.g7178c9af9c doesn't.

SemVer demands the following:

<valid semver> ::= <version core>
                 | <version core> "-" <pre-release>
                 | <version core> "+" <build>
                 | <version core> "-" <pre-release> "+" <build>

<version core> ::= <major> "." <minor> "." <patch>

In prose: the version core, in the case of our offending git version 2.29.0, must be followed by either a + or a -.

What we have instead is a ..

In conclusion, as long as gitea uses hashicorp/go-version with its demand for correct Semantic Versioning, I don't see how it can support git version 2.29.0.rc0.261.g7178c9af9c. So we can

• either look for different version parsing
• or declare this a "Won't Fix".

[6543]

@eneuschild go-version has two functions ... one who explicit only parse SemVers and one who try to parse Versions at all (second one is used and should know what to do with the string ...)

PS: until hashicorp do not act at all, can you send pulls to my fork & upstream?

[wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf]

... but now that I'm here, I might as well look into the issue.

I did some tweaking of the RegEx myself and actually quickly found one that worked.
But: the upstream project insists that versions validated with it follow SemVer, which, unfortunately, 2.29.0.rc0.261.g7178c9af9c doesn't.

SemVer demands the following:

<valid semver> ::= <version core>
                 | <version core> "-" <pre-release>
                 | <version core> "+" <build>
                 | <version core> "-" <pre-release> "+" <build>

<version core> ::= <major> "." <minor> "." <patch>

In prose: the version core, in the case of our offending git version 2.29.0, must be followed by either a + or a -.

What we have instead is a ..

In conclusion, as long as gitea uses hashicorp/go-version with its demand for correct Semantic Versioning, I don't see how it can support git version 2.29.0.rc0.261.g7178c9af9c. So we can

• either look for different version parsing
• or declare this a "Won't Fix".

whoa, this was fast!
well that is bad news, really, at least until git moves from rc to regular dev (semver compatible) version naming.
I don't see into as to why they opted for the current one, but I'd vouch for rather following whatever git folks are doing than rigidly proper semver - as that may in turn leave us with Gitea failing to start for users with git present on the system - be it a pre-release version - and the error saying it's not present.

[wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf]

Or we should advise users not to use pre-release git because of the above mentioned issue (possibly until it's resolved, either on our side or upstream)..

[eneuschild]

@eneuschild go-version has two functions ... one who explicit only parse SemVers and one who try to parse Versions at all (second one is used and should know what to do with the string ...)

PS: until hashicorp do not act at all, can you send pulls to my fork & upstream?

On it. :)

[6543]

ok first pull got merged, waiting for second one ... will release new version after this :)