[x]
):I'm able to create a feature/nameoffeature branch but when I try to load it on gitea it throws 500 errors
...
@ThierryBegin Could you confirm v1.10.3 still has the problem?
hard to tell, Ill have to find a way to update it in the jail I guess, which isn't simple.
@ThierryBegin updating gitea should be easy - do you have custom modifications ?!?
@ThierryBegin Did you create the branch from Gitea UI or Git CLI?
@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
Finally got back home and I was able to update to 1.10.3, unfortunately, the problem is still there.
can you enable develop mode and give us some logs?
sure,
here it goes:
gitea.log
and thx for the help
I have, the same issue:
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, @greg-ch could please confirm that:
master
, dev
, etc.)? (So we know we need to focus on the sub-branches).For these test try to use only the UI (you can create files and branches from the UI no problem).
@guillep2k
Yes,
Have you deleted that branch? Cannot reproduce that on my local instance.
@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.
Could it be FreeBSD related issue?
@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?
Maybe it's a git version problem? Which version of git are you running?
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.
>
>
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?
there you go:
again, thx for the help
By any chance your default branch for that repo is _not_ master
?
Default is Master,
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).
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
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?
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...
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.
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 ^^) ...
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
@Fredoo404 are you running on Mac?
@zeripath Nop, Gitea is hosted on my rasperry (Raspbian stretch).
._files are a feature of Macs - in particular directories viewed through Finder - neither Git nor Gitea makes them.
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 ;)
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.
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.
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 Since go-git/go-git#39 merged, could you send a PR and confirm this bug is fixed in FreeBSD?
@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.
So I believe that go-git 5.10 has this fix.
yes I saw the upgraded version in freenas too . we can close this, thx guys!
Will do once the pr above is merged.