error 500 when compare branches #1633

@msongz commented on GitHub (Mar 19, 2018):

@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 commented on GitHub (Mar 19, 2018): @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 ```

GiteaMirror commented

@jonasfranz commented on GitHub (Mar 19, 2018):

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

@jonasfranz commented on GitHub (Mar 19, 2018): @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?

GiteaMirror commented

@msongz commented on GitHub (Mar 19, 2018):

@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 commented on GitHub (Mar 19, 2018): @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

GiteaMirror commented

@jonasfranz commented on GitHub (Mar 20, 2018):

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

@jonasfranz commented on GitHub (Mar 20, 2018): @msongz I tested it on a raspberry pi 2 with 1.4.0+rc2-5-gc0e0fb7 and cannot reproduce it.

GiteaMirror commented

2025-11-02 04:07:43 -06:00

@msongz commented on GitHub (Mar 20, 2018):

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

@msongz commented on GitHub (Mar 20, 2018): @JonasFranzDEV how about you clone my git to test again https://github.com/msongz/dietpi-script.git

GiteaMirror commented

@jonasfranz commented on GitHub (Mar 20, 2018):

pi2 and zerow are entirely different commit histories.

@jonasfranz commented on GitHub (Mar 20, 2018): pi2 and zerow are entirely different commit histories.

GiteaMirror commented

2025-11-02 04:07:43 -06:00

@jonasfranz commented on GitHub (Mar 20, 2018):

But this should been shown instead of error 500.

@jonasfranz commented on GitHub (Mar 20, 2018): But this should been shown instead of error 500.

GiteaMirror commented

2025-11-02 04:07:43 -06:00

@msongz commented on GitHub (Mar 20, 2018):

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

@msongz commented on GitHub (Mar 20, 2018): @JonasFranzDEV yes, they are separated; sorry for the unclear situation

GiteaMirror commented

@mckaygerhard commented on GitHub (Mar 26, 2018):

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

@mckaygerhard commented on GitHub (Mar 26, 2018): seem this only happened in different repositories with differents branchs..

GiteaMirror commented

@jonasfranz commented on GitHub (Jun 15, 2018):

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

@jonasfranz commented on GitHub (Jun 15, 2018): @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.

GiteaMirror commented

@mckaygerhard commented on GitHub (Jun 15, 2018):

please, please why not 1.5.X please!

@mckaygerhard commented on GitHub (Jun 15, 2018): please, please why not 1.5.X please!

GiteaMirror commented

2025-11-02 04:07:45 -06:00

@jonasfranz commented on GitHub (Jun 15, 2018):

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

@jonasfranz commented on GitHub (Jun 15, 2018): @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.

GiteaMirror commented

@lunny commented on GitHub (Apr 10, 2019):

fixed by #6555

@lunny commented on GitHub (Apr 10, 2019): fixed by #6555

GiteaMirror commented

@zeripath commented on GitHub (Apr 10, 2019):

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

@zeripath commented on GitHub (Apr 10, 2019): 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.)

GiteaMirror commented

@mckaygerhard commented on GitHub (Apr 10, 2019):

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 commented on GitHub (Apr 10, 2019): 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!

GiteaMirror commented

@zeripath commented on GitHub (Apr 10, 2019):

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

@zeripath commented on GitHub (Apr 10, 2019): @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.

GiteaMirror commented

@mckaygerhard commented on GitHub (Apr 10, 2019):

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"

@mckaygerhard commented on GitHub (Apr 10, 2019): 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"

GiteaMirror commented

@lunny commented on GitHub (Apr 11, 2019):

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

@lunny commented on GitHub (Apr 11, 2019): @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.

GiteaMirror commented

@mckaygerhard commented on GitHub (Apr 12, 2019):

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?

@mckaygerhard commented on GitHub (Apr 12, 2019): 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?

GiteaMirror commented

@zeripath commented on GitHub (Apr 12, 2019):

It is fixed in master by pr #6555

@zeripath commented on GitHub (Apr 12, 2019): It is fixed in master by pr #6555

GiteaMirror commented

@mckaygerhard commented on GitHub (Apr 12, 2019):

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

@mckaygerhard commented on GitHub (Apr 12, 2019): thaks for your fix @zeripath a question here important? will be backported for those have not 1.8 series of gitea? PLEASE?

GiteaMirror commented

@lunny commented on GitHub (Apr 12, 2019):

@mckaygerhard it has been back port to v1.8

@lunny commented on GitHub (Apr 12, 2019): @mckaygerhard it has been back port to v1.8

GiteaMirror commented

@mckaygerhard commented on GitHub (Apr 12, 2019):

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

@mckaygerhard commented on GitHub (Apr 12, 2019): a well, i taking about and cited: _"will be backported for those have not 1.8 series of gitea? PLEASE?"_ ?

GiteaMirror commented