error 500 when creating new PR: git read-tree Develop: exit status 128 - error: invalid path

[zuhairamahdi]

Gitea Version

1.15.2

Git Version

No response

Operating System

Windows

How are you running Gitea?

In windows Server as windows process

Database

MSSQL

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

2021/09/19 14:41:51 ...ers/web/repo/pull.go:1113:CompareAndPullRequestPost() [E] NewPullRequest: git read-tree Develop: exit status 128 - error: invalid path 'UCFS TAS'HEEL/Support Files/Assets.xcassets/Icon_NewWordAr.imageset/#New# Icon\Gold\new icons\new arabichdpi.png'

Description

for some projects that have weird path 'created on linux and/or macOS' we keep getting error 500

Screenshots

No response

[wxiaoguang]

It seems that the some filenames contain strange characters which make Windows filesystem unhappy.

Maybe you can try this first:

https://stackoverflow.com/questions/63727594/github-git-checkout-returns-error-invalid-path-on-windows

And it's highly recommended to use "valid" filenames for files in git in all platforms. Or you can run gitea in Linux, whose filesystem can allow almost every character in filename.

[delvh]

And it's highly recommended to use "valid" filenames for files in git on all platforms. Or you can run gitea in Linux, whose filesystem can allow almost every character in the filename.

Rule of thumb:
Use only limited ASCII for filenames (0-9 A-Z a-z and -._ as special signs). And especially no spaces, as those can lead to a myriad of other problems.
That prevents exactly those kinds of problems.

[wxiaoguang]

Use only limited ASCII for filenames (0-9 A-Z a-z and -._ as special signs). And especially no spaces, as those can lead to a myriad of other problems.

Spaces are OK in modern days. If you have developed some macOS or iOS application, you will find that Apple recommends to use spaces in filenames.

[zuhairamahdi]

the issue is that I can see old pull requests worked just fine but once we upgraded to 1.15 we are getting this issue.

[zeripath]

it's interesting because I can't think of any changes to this area in 1.15.

(In particular this call to read-tree has been present since #9302 in 1.11)

[zeripath]

and the read-tree should not be looking at the filesystem at all.

[zeripath]

We could specifically add a -i to the command-line but there shouldn't be a working tree at all.

[zuhairamahdi]

it's interesting because I can't think of any changes to this area in 1.15.

(In particular this call to read-tree has been present since #9302 in 1.11)

I think this might explain it. we upgraded from 1.10 to 1.14 and now to 1.15 where all the pull requests we made when we were using 1.10

[zeripath]

If you could would it be possible change this line:

gitea/services/pull/patch.go

Line 140 in d4bb8e0

_, err = git.NewCommand("read-tree", "base").RunInDir(tmpBasePath)

to:

	_, err = git.NewCommand("read-tree", "-i", "base").RunInDir(tmpBasePath)

---

OK this doesn't work.

---

which means I need to look at bit closer at why read-tree is even moaning about this - there shouldn't be any interaction of the work-tree.

[zuhairamahdi]

@zeripath is this specific to gogit version? if we used the default package you think it might help?