sub-branches throw 500 #4705

@lunny commented on GitHub (Jan 22, 2020):

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

@lunny commented on GitHub (Jan 22, 2020): @ThierryBegin Could you confirm v1.10.3 still has the problem?

GiteaMirror commented

@ThierryBegin commented on GitHub (Jan 22, 2020):

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

@ThierryBegin commented on GitHub (Jan 22, 2020): hard to tell, Ill have to find a way to update it in the jail I guess, which isn't simple.

GiteaMirror commented

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

@zeripath commented on GitHub (Jan 22, 2020):

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

Appears to work on try

@zeripath commented on GitHub (Jan 22, 2020): 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

GiteaMirror commented

@6543 commented on GitHub (Jan 23, 2020):

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

@6543 commented on GitHub (Jan 23, 2020): @ThierryBegin updating gitea should be easy - do you have custom modifications ?!?

GiteaMirror commented

@bagasme commented on GitHub (Jan 25, 2020):

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

@bagasme commented on GitHub (Jan 25, 2020): @ThierryBegin Did you create the branch from Gitea UI or Git CLI?

GiteaMirror commented

@ThierryBegin commented on GitHub (Jan 25, 2020):

@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 commented on GitHub (Jan 25, 2020): @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

GiteaMirror commented

@ThierryBegin commented on GitHub (Feb 14, 2020):

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

@ThierryBegin commented on GitHub (Feb 14, 2020): Finally got back home and I was able to update to 1.10.3, unfortunately, the problem is still there. ![image](https://user-images.githubusercontent.com/2735823/74490833-d3e12f80-4e97-11ea-8e84-5ca1f767ba3c.png)

GiteaMirror commented

2025-11-02 06:00:09 -06:00

@6543 commented on GitHub (Feb 14, 2020):

can you enable develop mode and give us some logs?

@6543 commented on GitHub (Feb 14, 2020): can you enable develop mode and give us some logs?

GiteaMirror commented

@ThierryBegin commented on GitHub (Feb 14, 2020):

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

@ThierryBegin commented on GitHub (Feb 14, 2020): sure, here it goes: [gitea.log](https://github.com/go-gitea/gitea/files/4204793/gitea.log) and thx for the help

GiteaMirror commented

2025-11-02 06:00:09 -06:00

@greg-ch commented on GitHub (Feb 16, 2020):

I have, the same issue:

@greg-ch commented on GitHub (Feb 16, 2020): I have, the same issue: ![image](https://user-images.githubusercontent.com/61112843/74605050-8564a880-50c4-11ea-867b-5b9dd0bd10b4.png) ![image](https://user-images.githubusercontent.com/61112843/74605068-a4633a80-50c4-11ea-8bf3-4cbc2584fe46.png)

GiteaMirror commented

@ThierryBegin commented on GitHub (Feb 16, 2020):

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

@ThierryBegin commented on GitHub (Feb 16, 2020): 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

GiteaMirror commented

@guillep2k commented on GitHub (Feb 17, 2020):

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

@guillep2k commented on GitHub (Feb 17, 2020): @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).

GiteaMirror commented

@ThierryBegin commented on GitHub (Feb 17, 2020):

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

@ThierryBegin commented on GitHub (Feb 17, 2020): @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.

GiteaMirror commented

@lunny commented on GitHub (Feb 17, 2020):

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

@lunny commented on GitHub (Feb 17, 2020): Have you deleted that branch? Cannot reproduce that on my local instance.

GiteaMirror commented

@ThierryBegin commented on GitHub (Feb 17, 2020):

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

@ThierryBegin commented on GitHub (Feb 17, 2020): @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.

GiteaMirror commented

@lafriks commented on GitHub (Feb 17, 2020):

Could it be FreeBSD related issue?

@lafriks commented on GitHub (Feb 17, 2020): Could it be FreeBSD related issue?

GiteaMirror commented

@ThierryBegin commented on GitHub (Feb 17, 2020):

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

@ThierryBegin commented on GitHub (Feb 17, 2020): @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?

GiteaMirror commented

@guillep2k commented on GitHub (Feb 18, 2020):

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

@guillep2k commented on GitHub (Feb 18, 2020): Maybe it's a git version problem? Which version of git are you running?

GiteaMirror commented

@greg-ch commented on GitHub (Feb 18, 2020):

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.

@greg-ch commented on GitHub (Feb 18, 2020): 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.

GiteaMirror commented

@guillep2k commented on GitHub (Feb 18, 2020):

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?

@guillep2k commented on GitHub (Feb 18, 2020): > > > 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? ![image](https://user-images.githubusercontent.com/18600385/74738552-eb247200-5235-11ea-95a7-112b423f6c70.png)

GiteaMirror commented

@ThierryBegin commented on GitHub (Feb 18, 2020):

there you go:

again, thx for the help

@ThierryBegin commented on GitHub (Feb 18, 2020): there you go: ![image](https://user-images.githubusercontent.com/2735823/74750195-56bc0e80-5239-11ea-84f3-02f46dbf7f73.png) again, thx for the help

GiteaMirror commented

@guillep2k commented on GitHub (Feb 19, 2020):

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

@guillep2k commented on GitHub (Feb 19, 2020): By any chance your default branch for that repo is _not_ `master`?

GiteaMirror commented

@ThierryBegin commented on GitHub (Feb 20, 2020):

Default is Master,

@ThierryBegin commented on GitHub (Feb 20, 2020): Default is Master, ![image](https://user-images.githubusercontent.com/2735823/74893270-f7095480-5359-11ea-81b0-e74ee77de2ee.png) ![image](https://user-images.githubusercontent.com/2735823/74893291-07b9ca80-535a-11ea-93c5-66dbd1979262.png)

GiteaMirror commented

@mrsdizzie commented on GitHub (Feb 20, 2020):

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

@mrsdizzie commented on GitHub (Feb 20, 2020): 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).

GiteaMirror commented

@ThierryBegin commented on GitHub (Feb 20, 2020):

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

@ThierryBegin commented on GitHub (Feb 20, 2020): 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

GiteaMirror commented

@guillep2k commented on GitHub (Feb 21, 2020):

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?

@guillep2k commented on GitHub (Feb 21, 2020): 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?

GiteaMirror commented

@ThierryBegin commented on GitHub (Feb 21, 2020):

git show-ref gave me this:
8b6cf726a1d1a45ebe2394e32290ce513f9b776a refs/heads/master 8b6cf726a1d1a45ebe2394e32290ce513f9b776a refs/remotes/origin/HEAD 8b6cf726a1d1a45ebe2394e32290ce513f9b776a refs/remotes/origin/master 8b6cf726a1d1a45ebe2394e32290ce513f9b776a refs/remotes/origin/test/tas

I pushed on gitea.io

seems to be working there...

@ThierryBegin commented on GitHub (Feb 21, 2020): git show-ref gave me this: `8b6cf726a1d1a45ebe2394e32290ce513f9b776a refs/heads/master 8b6cf726a1d1a45ebe2394e32290ce513f9b776a refs/remotes/origin/HEAD 8b6cf726a1d1a45ebe2394e32290ce513f9b776a refs/remotes/origin/master 8b6cf726a1d1a45ebe2394e32290ce513f9b776a refs/remotes/origin/test/tas` I pushed on gitea.io ![image](https://user-images.githubusercontent.com/2735823/75053004-8b7ccf80-549e-11ea-836a-e0a080845051.png) seems to be working there...

GiteaMirror commented

@guillep2k commented on GitHub (Feb 21, 2020):

Some weird local permissions on the file-system? I don't think it's related, but if the repos are on a no-exec filesystem, Gitea won't work because the hooks won't be able to run.

@guillep2k commented on GitHub (Feb 21, 2020): Some weird local permissions on the file-system? I don't think it's related, but if the repos are on a no-exec filesystem, Gitea won't work because the hooks won't be able to run.

GiteaMirror commented

@fbentouati commented on GitHub (Feb 22, 2020):

Hello,

I don't know If my problem is related to this issue, but I got a similar behavior when I want to display the branch page of my repos.

I don't know why but on my branch settings (on the protected branch section) there are an unknown branch named: ._master. When I want select this unknown branch, I got an error 500.

I success to resolve my problem with step below:

On my server, I created the ._master reference file:

/data/git/repositories/frd404/repos.git/refs/heads# cp master ._master

Try to select the ._master branch on the protected section (without validate the forms).

Then remove the ._masterfile previously created:

/data/git/repositories/frd404/repos.git/refs/heads# rm ._master

At this moment, the ._master branch seem be deleted from gitea database.

I hope It's can help (If my problem is related to this issue ^^) ...

@fbentouati commented on GitHub (Feb 22, 2020): Hello, I don't know If my problem is related to this issue, but I got a similar behavior when I want to display the branch page of my repos. I don't know why but on my branch settings (on the protected branch section) there are an unknown branch named: `._master`. When I want select this unknown branch, I got an error 500. I success to resolve my problem with step below: On my server, I created the `._master` reference file: ``` /data/git/repositories/frd404/repos.git/refs/heads# cp master ._master ``` Try to select the `._master` branch on the protected section (without validate the forms). Then remove the `._master`file previously created: ``` /data/git/repositories/frd404/repos.git/refs/heads# rm ._master ``` At this moment, the ._master branch seem be deleted from gitea database. I hope It's can help (If my problem is related to this issue ^^) ...

GiteaMirror commented

@ThierryBegin commented on GitHub (Feb 26, 2020):

Unfortuantely @Fredoo404 's fix isn't the one im looking for ;)
I also wen directly in the server folders and couldn't see any issues with with permissions in the ref/heads

the branch folder seem to be empty, not sure if it should or not be... thing is certain the url it point to is src/branch/test2/testtt so I suppose something is missing there

@ThierryBegin commented on GitHub (Feb 26, 2020): Unfortuantely @Fredoo404 's fix isn't the one im looking for ;) I also wen directly in the server folders and couldn't see any issues with with permissions in the **ref/heads** the **branch** folder seem to be empty, not sure if it should or not be... thing is certain the url it point to is **src/branch/test2/testtt** so I suppose something is missing there

GiteaMirror commented

@zeripath commented on GitHub (Mar 4, 2020):

@Fredoo404 are you running on Mac?

@zeripath commented on GitHub (Mar 4, 2020): @Fredoo404 are you running on Mac?

GiteaMirror commented

@fbentouati commented on GitHub (Mar 5, 2020):

@zeripath Nop, Gitea is hosted on my rasperry (Raspbian stretch).

@fbentouati commented on GitHub (Mar 5, 2020): @zeripath Nop, Gitea is hosted on my rasperry (Raspbian stretch).

GiteaMirror commented

@zeripath commented on GitHub (Mar 5, 2020):

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

@zeripath commented on GitHub (Mar 5, 2020): ._files are a feature of Macs - in particular directories viewed through Finder - neither Git nor Gitea makes them.

GiteaMirror commented

@fbentouati commented on GitHub (Mar 5, 2020):

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

@fbentouati commented on GitHub (Mar 5, 2020): 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 ;)

GiteaMirror commented

@kevans91 commented on GitHub (Apr 23, 2020):

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.

@kevans91 commented on GitHub (Apr 23, 2020): 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.

GiteaMirror commented

@ThierryBegin commented on GitHub (Apr 23, 2020):

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.

@ThierryBegin commented on GitHub (Apr 23, 2020): 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.

GiteaMirror commented

@kevans91 commented on GitHub (Apr 23, 2020):

I've opened https://github.com/go-git/go-git/pull/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.

@kevans91 commented on GitHub (Apr 23, 2020): I've opened https://github.com/go-git/go-git/pull/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.**

GiteaMirror commented

@lunny commented on GitHub (Apr 25, 2020):

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

@lunny commented on GitHub (Apr 25, 2020): @kevans91 Since go-git/go-git#39 merged, could you send a PR and confirm this bug is fixed in FreeBSD?

GiteaMirror commented

@kevans91 commented on GitHub (Apr 25, 2020):

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

@kevans91 commented on GitHub (Apr 25, 2020): > @kevans91 Since [go-git/go-git#39](https://github.com/go-git/go-git/pull/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.

GiteaMirror commented