github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-14 20:07:40 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

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

New Issue
Closed
opened 2025-11-02 06:45:27 -06:00 by GiteaMirror · 12 comments
GiteaMirror commented 2025-11-02 06:45:27 -06:00
Owner
Copy Link

Originally created by @wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf on GitHub (Oct 7, 2020).

Originally assigned to: @6543 on GitHub.

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.

Originally created by @wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf on GitHub (Oct 7, 2020). Originally assigned to: @6543 on GitHub. - 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`](https://github.com/go-gitea/gitea/commit/e0b772780) - Git version: `2.29.0.rc0.261.g7178c9af9c` - Operating system: Arch Linux and Fedora 33 - Database: - [x] SQLite - Can you reproduce the bug at https://try.gitea.io: - [x] Not relevant - Log gist: ```log 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.
GiteaMirror added the type/bugtype/upstream labels 2025-11-02 06:45:27 -06:00
GiteaMirror commented 2025-11-02 06:45:28 -06:00
Author
Owner
Copy Link

@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf commented on GitHub (Oct 7, 2020):

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

@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf commented on GitHub (Oct 7, 2020): Also, we have already seen something similar in #12731 before.
GiteaMirror commented 2025-11-02 06:45:28 -06:00
Author
Owner
Copy Link

@6543 commented on GitHub (Oct 13, 2020):

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

@6543 commented on GitHub (Oct 13, 2020): I tryed to enhance the regex again, didnt found a good soultion for now :(
GiteaMirror commented 2025-11-02 06:45:28 -06:00
Author
Owner
Copy Link

@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf commented on GitHub (Oct 14, 2020):

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

I'm trying something, too.

@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf commented on GitHub (Oct 14, 2020): > I tryed to enhance the regex again, didnt found a good soultion for now :( I'm trying something, too.
GiteaMirror commented 2025-11-02 06:45:28 -06:00
Author
Owner
Copy Link

@eneuschild commented on GitHub (Oct 15, 2020):

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

Sorry for the confusion. :-|

@eneuschild commented on GitHub (Oct 15, 2020): Please ignore that PR from me for this issue. Some autocomplete feature ran amok and linked the wrong issue. Sorry for the confusion. :-|
GiteaMirror commented 2025-11-02 06:45:28 -06:00
Author
Owner
Copy Link

@eneuschild commented on GitHub (Oct 15, 2020):

... 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".
@eneuschild commented on GitHub (Oct 15, 2020): ... 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](https://github.com/hashicorp/go-version) insists that versions validated with it follow [SemVer](https://semver.org/), 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](https://github.com/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".
GiteaMirror commented 2025-11-02 06:45:29 -06:00
Author
Owner
Copy Link

@6543 commented on GitHub (Oct 15, 2020):

@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?

@6543 commented on GitHub (Oct 15, 2020): @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?
GiteaMirror commented 2025-11-02 06:45:29 -06:00
Author
Owner
Copy Link

@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf commented on GitHub (Oct 15, 2020):

... 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 commented on GitHub (Oct 15, 2020): > ... 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](https://github.com/hashicorp/go-version) insists that versions validated with it follow [SemVer](https://semver.org/), 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](https://github.com/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.
GiteaMirror commented 2025-11-02 06:45:29 -06:00
Author
Owner
Copy Link

@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf commented on GitHub (Oct 15, 2020):

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)..

@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf commented on GitHub (Oct 15, 2020): 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)..
GiteaMirror commented 2025-11-02 06:45:29 -06:00
Author
Owner
Copy Link

@eneuschild commented on GitHub (Oct 15, 2020):

@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. :)

@eneuschild commented on GitHub (Oct 15, 2020): > @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. :)
GiteaMirror commented 2025-11-02 06:45:30 -06:00
Author
Owner
Copy Link

@6543 commented on GitHub (Oct 16, 2020):

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

@6543 commented on GitHub (Oct 16, 2020): ok first pull got merged, waiting for second one ... will release new version after this :)
GiteaMirror commented 2025-11-02 06:45:30 -06:00
Author
Owner
Copy Link

@6543 commented on GitHub (Oct 16, 2020):

-> #13169

@6543 commented on GitHub (Oct 16, 2020): -> #13169
GiteaMirror commented 2025-11-02 06:45:30 -06:00
Author
Owner
Copy Link

@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf commented on GitHub (Oct 16, 2020):

-> #13169

works like a charm, thanks! @6543 @eneuschild 🎉

@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf commented on GitHub (Oct 16, 2020): > -> #13169 works like a charm, thanks! @6543 @eneuschild 🎉
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label type/bug type/upstream
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#6113
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?