Every pull request fails with 500

[sbradl]

• Gitea version (or commit ref): at least 1.8 to 1.9.4
• Git version: 2.23.0.windows.1
• Operating system: windows
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • [x ] SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:
  git merge --no-ff --no-commit [C:/Gitea/data/tmp/local-repo/merge-155965200.git]: exec(10:PullRequest.Merge (git merge --no-ff --no-commit): C:/Gitea/data/tmp/local-repo/merge-155965200.git) failed: exit status 128() stdout: stderr: error: Cannot update sparse checkout: the following entries are not up to date:

[lunny]

Which version is your git ?

[sbradl]

• Git version: 2.23.0.windows.1

[zeripath]

@sbradl are you able to try to come up with a minimal test case to push up to try?

If not, Would it be possible to try this on a build with my PR #8548 ? If you can't build I can try to cross-compile a copy for you but it may take some time.

I'm currently looking at improving error handling in merging - and need real examples to test. It is likely that your problem is just a merge conflict and you just need to try a different stategy - it's just our error reporting is terrible.

[sbradl]

I tried every merge strategy and got the same error. Merging by hand with a simple "git merge" on the command line works without any problems.

I will try to make a reproducible example but I cannot do this with my real code because of copyright stuff. In another issue someone had the same problem: #7205 (comment)

Maybe @Ahaus314 can help with this

[zeripath]

Were you able to work out which file was causing the conflict?

There's a bug in #8629 which you might have hit. Otherwise I have a suspicion that our merging code might fail if files are moved in a specific way - but I don't know how to trigger it.

If you can work out what the problem was it would help immensely.

[zeripath]

The other thing is to try with my PR as the error messages are significantly improved.

[sbradl]

The error message lists some files so I can look if this could be related to the bug you mentionened. Yesterday we had a holiday and today I am not in the office. So it has to wait till monday.

[Ahaus314]

I tried every merge strategy and got the same error. Merging by hand with a simple "git merge" on the command line works without any problems.
I will try to make a reproducible example but I cannot do this with my real code because of copyright stuff. In another issue someone had the same problem: #7205 (comment)
Maybe @Ahaus314 can help with this

I finally got some progression on my issue regarding some Error 500 when trying to create a Pull Request. Our server is also Under Windows and the Git implementation differ from the Linux one regarding the handling of the limit of a file name. By default, Git handle a maximum of 4096 characters however under Windows, it's limited to 260 (or 259). In my case, it appears that some folder/filename exceed the 260/259 characters limit (yeah, my organization like long path). Even if the error message wasn't mentionning the "filename too long", I had to set a specific config for the Git instance on the server where Gitea is installed. I added:
$ git config --system core.longpaths true
(I found the answer here https://stackoverflow.com/questions/22575662/filename-too-long-in-git-for-windows). Pull Requests are now working fine. Hope it'll help you.

[sbradl]

Thanks a lot @Ahaus314 the longpaths setting seems to work for me too

[guillep2k]

I had to set a specific config for the Git instance on the server where Gitea is installed. I added:
$ git config --system core.longpaths true
(I found the answer here https://stackoverflow.com/questions/22575662/filename-too-long-in-git-for-windows). Pull Requests are now working fine. Hope it'll help you.

Can this be added inside Gitea by default? Sounds like a useful setting.

[zeripath]

So I have been worried about every other peculiarity of the windows filesystems and completely forgot about this piece of phenomenal idiocy on behalf of our proprietary overloads.

Merge is literally the last place that actually checks out files with their filenames and treepaths. I have removed every other place that does this - merge remains stubborn because you have to rewrite a lot of plumbing to get it to work and I just haven't had a chance to think about it properly. That's why most would only notice this on merge and literally nowhere else. (The only other way you could be affected is if you couldn't actually store a git repo because the filename was too long - oh and maybe a stupidly long branch name.)

Good catch @Ahaus314