sub-branches throw 500 #9938

ThierryBegin · 2020-01-22T15:36:16Z

Gitea version (or commit ref): 1.9.3 built with go1.13.1
Git version: 2.23.0
Operating system: FreeBSD (Freenas)
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist:

Description

I'm able to create a feature/nameoffeature branch but when I try to load it on gitea it throws 500 errors
...

Screenshots

The text was updated successfully, but these errors were encountered:

lunny · 2020-01-22T15:46:08Z

@ThierryBegin Could you confirm v1.10.3 still has the problem?

ThierryBegin · 2020-01-22T18:07:28Z

hard to tell, Ill have to find a way to update it in the jail I guess, which isn't simple.

zeripath · 2020-01-22T20:02:45Z

https://try.gitea.io/arandomer/test-9938/src/branch/subfile/subbranch

https://try.gitea.io/arandomer/test-9938/src/branch/subfile/subbranch/subfile

Appears to work on try

6543 · 2020-01-23T11:05:29Z

@ThierryBegin updating gitea should be easy - do you have custom modifications ?!?

bagasme · 2020-01-25T02:20:54Z

@ThierryBegin Did you create the branch from Gitea UI or Git CLI?

ThierryBegin · 2020-01-25T14:45:10Z

@6543 I'm yusing freenas 11.2, the package is outdated for some reason, ill have to figure out something I suppose...
@bagasme both, the result is the same

ThierryBegin · 2020-02-14T00:34:22Z

Finally got back home and I was able to update to 1.10.3, unfortunately, the problem is still there.

6543 · 2020-02-14T02:23:41Z

can you enable develop mode and give us some logs?

ThierryBegin · 2020-02-14T14:15:32Z

sure,
here it goes:
gitea.log
and thx for the help

greg-ch · 2020-02-16T13:00:14Z

I have, the same issue:

ThierryBegin · 2020-02-16T20:13:26Z

I updated Freenas to 11.3 today and decided to try with the community plugin. I couldn't even create a repo until I added
SCRIPT_TYPE=sh
to my app.ini
unfortunately the 500 error is also still there when I try to use sub-branches

guillep2k · 2020-02-17T04:49:26Z

@ThierryBegin, @greg-ch could please confirm that:

Will a new repository, created from scratch, work properly in your setup if you stick to single-word branches (master, dev, etc.)? (So we know we need to focus on the sub-branches).
Will a new repository, created from scratch, also present this sub-branches problem? (I know some of you upgraded, so I want to discard an upgrade omission).

For these test try to use only the UI (you can create files and branches from the UI no problem).

ThierryBegin · 2020-02-17T14:04:07Z

@guillep2k
Yes,

it's a fresh install of gitea on freenas 11.3 plugin so no upgrade there
fresh repo created from gitea webui works with single words but not sub-branches (the branch seem to be created but selecting it in the ui throw the 500 error)
also tried to create a branch from local git but and push and same result.

lunny · 2020-02-17T14:27:09Z

Have you deleted that branch? Cannot reproduce that on my local instance.

ThierryBegin · 2020-02-17T14:43:18Z

@lunny not sure I understand the question. its a fresh new branch on a fresh new repo @greg-ch have 2 screenshots that show exactly what is happening too.

lafriks · 2020-02-17T19:08:05Z

Could it be FreeBSD related issue?

ThierryBegin · 2020-02-17T22:00:03Z

@lafriks it could be, still need to be fixed tho. especially if the plugin is that easily available to install.
@greg-ch did you had the issue on freebsd too?

guillep2k · 2020-02-18T04:25:14Z

Maybe it's a git version problem? Which version of git are you running?

greg-ch · 2020-02-18T06:18:05Z

I will add that the sub-branch which is on my screenshots and which opens with 500. I created using git flow release .... on FreeBSD 12.1.

guillep2k · 2020-02-18T13:03:56Z

I created using git flow release .... on FreeBSD 12.1.

I have no idea what version of git that is. Can you do a git --version or go into /admin/config and write down the value?

ThierryBegin · 2020-02-18T15:28:23Z

there you go:

again, thx for the help

guillep2k · 2020-02-19T04:54:28Z

By any chance your default branch for that repo is not master?

ThierryBegin · 2020-02-20T01:54:36Z

Default is Master,

mrsdizzie · 2020-02-20T16:09:16Z

The actual error from the log posted above is:

2020/02/14 06:13:24 ...ules/context/repo.go:648:func1() [E] GetBranchCommit: object not found
2020/02/14 06:13:24 ...s/context/context.go:139:HTML() [D] Template: status/500

Could be an issue with the local git configuration if there is any (I also can't reproduce this but anybody should at least focus on the real error it's giving).

ThierryBegin · 2020-02-20T16:45:43Z

if it helps, I think this is the git repo with all the install instructions that freebsd need to install the plugin afaik https://github.com/jaf-iocage-plugins/iocage-plugin-gitea

guillep2k · 2020-02-21T03:58:21Z

Yet another question... 😄

You're trying to get branch releases/xxx1. Is it possible that there also exists a branch or tag named just releases? Could you please clone the repo and post the results of running...:

git show-ref

?

Also, I get that you were able to reproduce with a repo from scratch. Could you please push that repo to try.gitea.io to see if it behaves differently over there?

zeripath · 2020-03-05T09:14:56Z

._files are a feature of Macs - in particular directories viewed through Finder - neither Git nor Gitea makes them.

fbentouati · 2020-03-05T10:57:42Z

Hmm, my workstation is under mac. I have no memories to open gitea data with mac Finder, but it's not impossible because in the past I did many test with docker in local with my gitea data (currently on my rasperry).

thank you for your feedback ;)

kevans91 · 2020-04-23T19:33:52Z

I can confirm seeing this in a fresh FreeBSD 12.1 jail with Gitea 1.11.3/Go 1.14.1/Git 2.26.1 -- I'll see if I can dig into it and figure out what's going on.

ThierryBegin · 2020-04-23T20:47:29Z

Thx, keep us posted, in the meantime I switched to gitlab and it does works flawlessly except for the insane amount of memory it's taking even in idle.

kevans91 · 2020-04-23T23:28:27Z

I've opened go-git/go-git#39, which resolves the underlying problem: given a branch name like feature/blah, Gitea would attempt to readReferenceFile('.', 'feature') first. go-git was implicitly relying on the read() of the opened file to fail if it had actually opened a directory, so Gitea would get a false-positive that feature is a branch when it's really not; leading it to stop the search. It would later come to realize that feature is in-fact not the name of a branch.

I suspect this can be closed, as the problem lies elsewhere. edit: after-thought, unless Gitea maintainers can be convinced to import the fix if upstream accepts it.

This fix has been accepted and merged upstream; the gist of the problem is that readReferenceFile() must check that what it's been requested to read isn't a directory. read() on a directory fd may work on some platforms (e.g. FreeBSD), so readReferenceFile() would previously succeed at the earliest point in a branch name (e.g. "feature" in "feature/myfeature") despite the fact that this isn't a branch ref but a directory. Fixes issue go-gitea#9938 Signed-off-by: Kyle Evans <[email protected]>

lunny · 2020-04-25T12:44:52Z

@kevans91 Since go-git/go-git#39 merged, could you send a PR and confirm this bug is fixed in FreeBSD?

kevans91 · 2020-04-25T14:11:18Z

@kevans91 Since go-git/go-git#39 merged, could you send a PR and confirm this bug is fixed in FreeBSD?

Hi,

I sent a PR and was told it can't be merged until a release of go-git is cut that includes it. =( #11208

It does fix the problem on FreeBSD and I've got a patch for our ports system that we can carry locally with no real problem until a new release is made.

An issue[0] was filed upstream in January that branches with a slash in their name (e.g. stable/11) result in a 500 error when attempting to view them. I tracked down the issue to the fact that read(2) on a directory fd in FreeBSD will actually succeed, while it will not on Linux/other OS. I have filed a PR[1] with go-git to remedy the problem there, and then we (hopefully) convince gitea maintainers to accept the patch as well once it's upstreamed. The attached patch brings it into the ports tree as well, so that FreeBSD users can more immediately get the fix. It should still apply to the version in 2020Q2, more or less, with version numbers changed to protect the innocent. [0] go-gitea/gitea#9938 [1] go-git/go-git#39 PR: 245863 Approved by: <stb lassitu de> (maintainer) Aoorived by: koobs (mentor, ports) MFH: 2020Q2 (minor bugfix patch) git-svn-id: svn+ssh://svn.freebsd.org/ports/head@534921 35697150-7ecd-e111-bb59-0022644237b5

An issue[0] was filed upstream in January that branches with a slash in their name (e.g. stable/11) result in a 500 error when attempting to view them. I tracked down the issue to the fact that read(2) on a directory fd in FreeBSD will actually succeed, while it will not on Linux/other OS. I have filed a PR[1] with go-git to remedy the problem there, and then we (hopefully) convince gitea maintainers to accept the patch as well once it's upstreamed. The attached patch brings it into the ports tree as well, so that FreeBSD users can more immediately get the fix. It should still apply to the version in 2020Q2, more or less, with version numbers changed to protect the innocent. [0] go-gitea/gitea#9938 [1] go-git/go-git#39 PR: 245863 Approved by: <stb lassitu de> (maintainer) Aoorived by: koobs (mentor, ports) MFH: 2020Q2 (minor bugfix patch)

www/gitea: Fix viewing of branches with a slash in the name An issue[0] was filed upstream in January that branches with a slash in their name (e.g. stable/11) result in a 500 error when attempting to view them. I tracked down the issue to the fact that read(2) on a directory fd in FreeBSD will actually succeed, while it will not on Linux/other OS. I have filed a PR[1] with go-git to remedy the problem there, and then we (hopefully) convince gitea maintainers to accept the patch as well once it's upstreamed. The attached patch brings it into the ports tree as well, so that FreeBSD users can more immediately get the fix. It should still apply to the version in 2020Q2, more or less, with version numbers changed to protect the innocent. [0] go-gitea/gitea#9938 [1] go-git/go-git#39 PR: 245863 Approved by: <stb lassitu de> (maintainer) Aoorived by: koobs (mentor, ports) Approved by: ports-secteam (blanket: minor bugfix patch)

An issue[0] was filed upstream in January that branches with a slash in their name (e.g. stable/11) result in a 500 error when attempting to view them. I tracked down the issue to the fact that read(2) on a directory fd in FreeBSD will actually succeed, while it will not on Linux/other OS. I have filed a PR[1] with go-git to remedy the problem there, and then we (hopefully) convince gitea maintainers to accept the patch as well once it's upstreamed. The attached patch brings it into the ports tree as well, so that FreeBSD users can more immediately get the fix. It should still apply to the version in 2020Q2, more or less, with version numbers changed to protect the innocent. [0] go-gitea/gitea#9938 [1] go-git/go-git#39 PR: 245863 Approved by: <stb lassitu de> (maintainer) Aoorived by: koobs (mentor, ports) MFH: 2020Q2 (minor bugfix patch) git-svn-id: svn+ssh://svn.freebsd.org/ports/head@534921 35697150-7ecd-e111-bb59-0022644237b5

zeripath · 2020-06-17T19:57:20Z

So I believe that go-git 5.10 has this fix.

ThierryBegin · 2020-06-17T20:36:31Z

yes I saw the upgraded version in freenas too . we can close this, thx guys!

zeripath · 2020-06-17T21:28:01Z

Will do once the pr above is merged.

lunny added the issue/needs-feedback For bugs, we need more details. For features, the feature must be described in more detail label Jan 22, 2020

lunny added type/bug and removed issue/needs-feedback For bugs, we need more details. For features, the feature must be described in more detail labels Feb 17, 2020

lunny added this to the 1.11.2 milestone Feb 17, 2020

lunny modified the milestones: 1.11.3, 1.11.4 Mar 10, 2020

lafriks modified the milestones: 1.11.4, 1.11.5 Apr 1, 2020

kevans91 mentioned this issue Apr 24, 2020

vendor: go-git: import IsDir() check for readReferenceFile() #11208

Closed

guillep2k added the type/upstream This is an issue in one of Gitea's dependencies and should be reported there label Apr 25, 2020

lunny modified the milestones: 1.11.5, 1.11.6 May 1, 2020

techknowlogick modified the milestones: 1.11.6, 1.11.7 Jun 3, 2020

zeripath mentioned this issue Jun 17, 2020

Update to go-git v5.1.0 #11936

Merged

techknowlogick closed this as completed in #11936 Jun 17, 2020

go-gitea locked and limited conversation to collaborators Nov 24, 2020

sub-branches throw 500 #9938

sub-branches throw 500 #9938

Comments

ThierryBegin commented Jan 22, 2020

Description

Screenshots

lunny commented Jan 22, 2020

ThierryBegin commented Jan 22, 2020

zeripath commented Jan 22, 2020 • edited Loading

6543 commented Jan 23, 2020

bagasme commented Jan 25, 2020

ThierryBegin commented Jan 25, 2020

ThierryBegin commented Feb 14, 2020

6543 commented Feb 14, 2020

ThierryBegin commented Feb 14, 2020

greg-ch commented Feb 16, 2020

ThierryBegin commented Feb 16, 2020

guillep2k commented Feb 17, 2020

ThierryBegin commented Feb 17, 2020

lunny commented Feb 17, 2020

ThierryBegin commented Feb 17, 2020

lafriks commented Feb 17, 2020

ThierryBegin commented Feb 17, 2020

guillep2k commented Feb 18, 2020

greg-ch commented Feb 18, 2020 • edited Loading

guillep2k commented Feb 18, 2020

ThierryBegin commented Feb 18, 2020

guillep2k commented Feb 19, 2020

ThierryBegin commented Feb 20, 2020

mrsdizzie commented Feb 20, 2020

ThierryBegin commented Feb 20, 2020

guillep2k commented Feb 21, 2020

zeripath commented Mar 5, 2020

fbentouati commented Mar 5, 2020

kevans91 commented Apr 23, 2020

ThierryBegin commented Apr 23, 2020

kevans91 commented Apr 23, 2020 • edited Loading

lunny commented Apr 25, 2020

kevans91 commented Apr 25, 2020

zeripath commented Jun 17, 2020

ThierryBegin commented Jun 17, 2020 via email • edited Loading

zeripath commented Jun 17, 2020

zeripath commented Jan 22, 2020 •

edited

Loading

greg-ch commented Feb 18, 2020 •

edited

Loading

kevans91 commented Apr 23, 2020 •

edited

Loading

ThierryBegin commented Jun 17, 2020 via email •

edited

Loading