Gitea: error 500 when compare branches 

Created on 17 Mar 2018  ·  27Comments  ·  Source: go-gitea/gitea

9b91050417ec4fd168c7b50aa72fbb46
7fde1021ae7b7cd23e180e3e1103bc46

kinui

Most helpful comment

@mckaygerhard. I really don't appreciate this kind of comment. None of the maintainers or owners are paid to work on Gitea. I give up a lot of my free time to work on this project and that kind of comment is unhelpful in the extreme.

You are more than welcome to provide high quality PRs to fix issues you need, or when asked about your bugs to give concise and repeatable testcases.

As I said above, #6527 provided an excellent testcase that I was able to reproduce rapidly and test against to provide a fix in probably less than 30 minutes - although there was a certainly an element of the stars aligning. Good testcases certainly help.

Yes I appreciate the bug has been here for sometime. Yes that's not excellent. But it's a bug that dates from Gogs and is still present in Gogs.

Some appreciation of the hard work that we give you for free and some thanks wouldn't go amiss.

All 27 comments

any log?

could you tell me how to find the log you want ? @lunny

@msongz You will get the location of your logs on startup of gitea:

2018/03/19 12:16:25 [T] AppPath: $GOPATH/src/code.gitea.io/gitea/Unnamed
2018/03/19 12:16:25 [T] AppWorkPath: $GOPATH/src/code.gitea.io/gitea
2018/03/19 12:16:25 [T] Custom path: $GOPATH/src/code.gitea.io/gitea/custom
2018/03/19 12:16:25 [T] Log path: /tmp/gitea/log

Please submit the last lines of the gitea.log after the error 500 occurs.

@JonasFranzDEV @lunny thanks!

2018/03/19 19:49:29 [I] Log Mode: File(Info)
2018/03/19 19:49:29 [I] XORM Log Mode: File(Info)
2018/03/19 19:49:29 [I] Cache Service Enabled
2018/03/19 19:49:29 [I] Session Service Enabled
2018/03/19 19:49:30 [I] Git Version: 2.11.0
2018/03/19 19:49:30 [I] SQLite3 Supported
2018/03/19 19:49:30 [I] Run Mode: Production
2018/03/19 19:49:32 [I] Listen: http://0.0.0.0:3000
2018/03/19 19:49:32 [I] LFS server enabled
2018/03/19 19:51:13 [...routers/repo/pull.go:647 ParseCompareInfo()] [E] GetPullRequestInfo: GetMergeBase: exit status 1

@msongz I could not reproduce your issue. Could you please explain all steps which lead to the error? Please post your git version, gitea version and operating system too.

Do you use docker or binary?

@JonasFranzDEV
I use binary with systemd on raspberry pi 2
gitea: 1.4.0+rc2-5-gc0e0fb7
git: git version 2.11.0

my step is quite simple, I have a repo with 2 branches in small differences,
after I into the compare page ,
left side was pi and right side also pi as the attached photo
then I change the right side pi to zerow and got a 500 error

@msongz I tested it on a raspberry pi 2 with 1.4.0+rc2-5-gc0e0fb7 and cannot reproduce it.

@JonasFranzDEV
how about you clone my git to test again
https://github.com/msongz/dietpi-script.git

pi2 and zerow are entirely different commit histories.

But this should been shown instead of error 500.

@JonasFranzDEV yes, they are separated;
sorry for the unclear situation

seem this only happened in different repositories with differents branchs..

@lunny This issue is not actually a bug because showing an error is the right thing if the users sends an invalid request. We should mark this as kind/ui and move it to 1.6.0 since only a UI change is required to resolve this issue.

please, please why not 1.5.X please!

@mckaygerhard We are currently overdue with the 1.5.0 release. And since we are in feature freeze since a month, we can't add this to 1.5.0. But we're trying to speed up our release cycle. So I hope that we will release 1.6.0 in a month including this improvement.

fixed by #6555

So sorry this took so long to fix.

A number of things had to align to figure out what was the problem:

  • 6527 provided an excellent test case for me to work against and although you had properly described the problem the lack of a testcase makes it difficult.

  • The mainlining of the git module instead of it being a sub project meant there was no cross project change.

  • The improvements in the logging infrastructure meant that it was easier to figure out where the problem was being sent from. (Although it should have been easy to change this in the old infrastructure.)

that's the problem with gitea, was for 1.5 then 1.6 so then was no due date!

too many releases and too few bugfixeds!

@mckaygerhard. I really don't appreciate this kind of comment. None of the maintainers or owners are paid to work on Gitea. I give up a lot of my free time to work on this project and that kind of comment is unhelpful in the extreme.

You are more than welcome to provide high quality PRs to fix issues you need, or when asked about your bugs to give concise and repeatable testcases.

As I said above, #6527 provided an excellent testcase that I was able to reproduce rapidly and test against to provide a fix in probably less than 30 minutes - although there was a certainly an element of the stars aligning. Good testcases certainly help.

Yes I appreciate the bug has been here for sometime. Yes that's not excellent. But it's a bug that dates from Gogs and is still present in Gogs.

Some appreciation of the hard work that we give you for free and some thanks wouldn't go amiss.

hi @zeripath mi comment its due its ver frustrating for us the constants "upgrades",

we appreciated that gitea has many features.. but you taking about "paid to work" and "time" well there's too much time in more and more features, and less and less bugfixeds..

you have some level of right when said that mi comment are too hard, but i have some level of right when the answerd are always "upgrade to lasted"... please! gitea 1.0 was great for some people.. but then need to upgrade! and then upgrade.. and then we have a "microsoft style" life!

take in consideration due some of us (that obvilously loves gitea) relies on the OS vendors (as example AWS machines) so if i run a version of go that are not shipped with the OS (as example 1.10 in strech Debian) vendor limited their support..

so then i must use a gieta compiled agains the go vendor to property addressed bugs that does not comes from gitea.. could you understand the problem respect the "constants upgrades"

@zeripath I think sometimes these bugs are not related with open source or not. Windows/Linux also have many such ten years or twenty years bugs. But of course all our maintainers/contributors spent many spare time on Gitea because we love her.

@mckaygerhard It's not fixed because not many gitea users encountered it or it has many limited conditions. If you encountered it frequently and cannot stand it, please don't complain and send a PR to fix it.

thanks for your reply @lunny , i want to help but sorry i not have enought skills in golang.. take for sure if i have those skilss i'll take by myselft that problem! but unfortunatelly, i dont have those skills, i am a very contributor when i found a problem .. but currently i need that fix and i cannot do it by myselft!

many of us are in same problem! that's why i said "please less features and more fixeds without raising requirements".. thanks ..

due do you noted that issue are market as "closed"? but you said "it's not fixed" so what happened here?

It is fixed in master by pr #6555

thaks for your fix @zeripath a question here important? will be backported for those have not 1.8 series of gitea? PLEASE?

@mckaygerhard it has been back port to v1.8

a well, i taking about and cited: _"will be backported for those have not 1.8 series of gitea? PLEASE?"_ ?

@mckaygerhard This will likely not be backported to 1.7.x as it relies on fairly major changes that will be introduced in 1.9.x (moving git to modules) and are already extra work just to backport to 1.8.x

Was this page helpful?
0 / 5 - 0 ratings