Merging pull requests on repository with LFS not working #2067

@severgun commented on GitHub (Jul 20, 2018):

Yes.
Also, broken once LFS pull request broke all webui merges for that repo.

@severgun commented on GitHub (Jul 20, 2018): Yes. Also, broken once LFS pull request broke all webui merges for that repo.

GiteaMirror commented

@severgun commented on GitHub (Jul 21, 2018):

After I add lfs.url = http://94.000.000.000:3000/Liquid/Test.git/info/lfs in .lfsconfig and push it to master I got new error.
From batch request: missing protocol: to Merge: git push: Invalid remote name "/home/git/gitea-repositories/liquid/Test.git"

@severgun commented on GitHub (Jul 21, 2018): After I add `lfs.url = http://94.000.000.000:3000/Liquid/Test.git/info/lfs` in .lfsconfig and push it to master I got new error. From `batch request: missing protocol:` to `Merge: git push: Invalid remote name "/home/git/gitea-repositories/liquid/Test.git"`

GiteaMirror commented

@gerroon commented on GitHub (Aug 7, 2018):

@severgun

Did you solve this issue? I am facing it as well.

@gerroon commented on GitHub (Aug 7, 2018): @severgun Did you solve this issue? I am facing it as well.

GiteaMirror commented

@severgun commented on GitHub (Aug 10, 2018):

Nope. Tagged as a bug. Waiting for a fix.
Seems like gitea now in pre-alpha unstable test because there is dozens of new issues per day.

@severgun commented on GitHub (Aug 10, 2018): Nope. Tagged as a bug. Waiting for a fix. Seems like gitea now in pre-alpha unstable test because there is dozens of new issues per day.

GiteaMirror commented

@gerroon commented on GitHub (Aug 10, 2018):

@severgun thanks

@gerroon commented on GitHub (Aug 10, 2018): @severgun thanks

GiteaMirror commented

@chowey commented on GitHub (Sep 12, 2018):

I'm getting the following error log when merging a pull request with LFS:

2018/09/12 11:24:52 [...routers/repo/pull.go:533 MergePullRequest()] [E] Merge: git push: Invalid remote name "C:\gitea\data\repos\my\repo.git"
error: failed to push some refs to 'C:\gitea\data\repos\my\repo.git'

I'm using Gitea on Windows.

@chowey commented on GitHub (Sep 12, 2018): I'm getting the following error log when merging a pull request with LFS: > 2018/09/12 11:24:52 [...routers/repo/pull.go:533 MergePullRequest()] [E] Merge: git push: Invalid remote name "C:\\gitea\\data\\repos\\my\\repo.git" > error: failed to push some refs to 'C:\gitea\data\repos\my\repo.git' I'm using Gitea on Windows.

GiteaMirror commented

@Haixing-Hu commented on GitHub (Nov 22, 2018):

same problem. any solution?

@Haixing-Hu commented on GitHub (Nov 22, 2018): same problem. any solution?

GiteaMirror commented

@ghost commented on GitHub (Nov 27, 2018):

same problem.
OS:centos7

$ git lfs env
git-lfs/2.6.0 (GitHub; linux amd64; go 1.11.1; git 93702d75)
git version 2.16.5

LocalWorkingDir=
LocalGitDir=
LocalGitStorageDir=
LocalMediaDir=lfs/objects
LocalReferenceDirs=
TempDir=lfs/tmp
ConcurrentTransfers=3
TusTransfers=false
BasicTransfersOnly=false
SkipDownloadErrors=false
FetchRecentAlways=false
FetchRecentRefsDays=7
FetchRecentCommitsDays=0
FetchRecentRefsIncludeRemotes=true
PruneOffsetDays=3
PruneVerifyRemoteAlways=false
PruneRemoteName=origin
LfsStorageDir=lfs
AccessDownload=none
AccessUpload=none
DownloadTransfers=basic
UploadTransfers=basic
git config filter.lfs.process = "git-lfs filter-process"
git config filter.lfs.smudge = "git-lfs smudge -- %f"
git config filter.lfs.clean = "git-lfs clean -- %f"

gitea.log

2018/11/27 11:19:39 [I] LFS server enabled
2018/11/27 11:20:22 [...routers/repo/pull.go:579 MergePullRequest()] [E] Merge: git merge --no-ff --no-commit [/var/apps/gitea/data/tmp/local-repo/merge-249727395.git]: exec(11:PullRequest.Merge (git merge --no-ff --no-commit): /var/apps/gitea/data/tmp/local-repo/merge-249727395.git) failed: exit status 128(<nil>) stdout:  stderr:
hint: The remote resolves to a file:// URL, which can only work with a
hint: standalone transfer agent.  See section "Using a Custom Transfer Type
hint: without the API server" in custom-transfers.md for details.
Downloading a.zip (34 B)

hint: The remote resolves to a file:// URL, which can only work with a
hint: standalone transfer agent.  See section "Using a Custom Transfer Type
hint: without the API server" in custom-transfers.md for details.
Error downloading object: a.zip (0a12b35): Smudge error: Error downloading a.zip (0a12b35d75289e158ab0d06fe388303c7275c458d51261dc44f747be6dfedc23): batch request: missing protocol: "file:///var/apps/gitea/repositories/developer/lfs-test.git/info/lfs"

Errors logged to /var/apps/gitea/data/tmp/local-repo/merge-249727395.git/.git/lfs/logs/20181127T112022.279642685.log
Use `git lfs logs last` to view the log.
error: external filter 'git-lfs filter-process' failed
fatal: a.zip: smudge filter lfs failed
 -
hint: The remote resolves to a file:// URL, which can only work with a
hint: standalone transfer agent.  See section "Using a Custom Transfer Type
hint: without the API server" in custom-transfers.md for details.
Downloading a.zip (34 B)

hint: The remote resolves to a file:// URL, which can only work with a
hint: standalone transfer agent.  See section "Using a Custom Transfer Type
hint: without the API server" in custom-transfers.md for details.
Error downloading object: a.zip (0a12b35): Smudge error: Error downloading a.zip (0a12b35d75289e158ab0d06fe388303c7275c458d51261dc44f747be6dfedc23): batch request: missing protocol: "file:///var/apps/gitea/repositories/developer/lfs-test.git/info/lfs"

Errors logged to /var/apps/gitea/data/tmp/local-repo/merge-249727395.git/.git/lfs/logs/20181127T112022.279642685.log
Use `git lfs logs last` to view the log.
error: external filter 'git-lfs filter-process' failed
fatal: a.zip: smudge filter lfs failed

@ghost commented on GitHub (Nov 27, 2018): same problem. OS:centos7 ``` $ git lfs env git-lfs/2.6.0 (GitHub; linux amd64; go 1.11.1; git 93702d75) git version 2.16.5 LocalWorkingDir= LocalGitDir= LocalGitStorageDir= LocalMediaDir=lfs/objects LocalReferenceDirs= TempDir=lfs/tmp ConcurrentTransfers=3 TusTransfers=false BasicTransfersOnly=false SkipDownloadErrors=false FetchRecentAlways=false FetchRecentRefsDays=7 FetchRecentCommitsDays=0 FetchRecentRefsIncludeRemotes=true PruneOffsetDays=3 PruneVerifyRemoteAlways=false PruneRemoteName=origin LfsStorageDir=lfs AccessDownload=none AccessUpload=none DownloadTransfers=basic UploadTransfers=basic git config filter.lfs.process = "git-lfs filter-process" git config filter.lfs.smudge = "git-lfs smudge -- %f" git config filter.lfs.clean = "git-lfs clean -- %f" ``` gitea.log ``` 2018/11/27 11:19:39 [I] LFS server enabled 2018/11/27 11:20:22 [...routers/repo/pull.go:579 MergePullRequest()] [E] Merge: git merge --no-ff --no-commit [/var/apps/gitea/data/tmp/local-repo/merge-249727395.git]: exec(11:PullRequest.Merge (git merge --no-ff --no-commit): /var/apps/gitea/data/tmp/local-repo/merge-249727395.git) failed: exit status 128(<nil>) stdout: stderr: hint: The remote resolves to a file:// URL, which can only work with a hint: standalone transfer agent. See section "Using a Custom Transfer Type hint: without the API server" in custom-transfers.md for details. Downloading a.zip (34 B) hint: The remote resolves to a file:// URL, which can only work with a hint: standalone transfer agent. See section "Using a Custom Transfer Type hint: without the API server" in custom-transfers.md for details. Error downloading object: a.zip (0a12b35): Smudge error: Error downloading a.zip (0a12b35d75289e158ab0d06fe388303c7275c458d51261dc44f747be6dfedc23): batch request: missing protocol: "file:///var/apps/gitea/repositories/developer/lfs-test.git/info/lfs" Errors logged to /var/apps/gitea/data/tmp/local-repo/merge-249727395.git/.git/lfs/logs/20181127T112022.279642685.log Use `git lfs logs last` to view the log. error: external filter 'git-lfs filter-process' failed fatal: a.zip: smudge filter lfs failed - hint: The remote resolves to a file:// URL, which can only work with a hint: standalone transfer agent. See section "Using a Custom Transfer Type hint: without the API server" in custom-transfers.md for details. Downloading a.zip (34 B) hint: The remote resolves to a file:// URL, which can only work with a hint: standalone transfer agent. See section "Using a Custom Transfer Type hint: without the API server" in custom-transfers.md for details. Error downloading object: a.zip (0a12b35): Smudge error: Error downloading a.zip (0a12b35d75289e158ab0d06fe388303c7275c458d51261dc44f747be6dfedc23): batch request: missing protocol: "file:///var/apps/gitea/repositories/developer/lfs-test.git/info/lfs" Errors logged to /var/apps/gitea/data/tmp/local-repo/merge-249727395.git/.git/lfs/logs/20181127T112022.279642685.log Use `git lfs logs last` to view the log. error: external filter 'git-lfs filter-process' failed fatal: a.zip: smudge filter lfs failed ```

GiteaMirror commented

@stale[bot] commented on GitHub (Jan 26, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Jan 26, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

@linghu86 commented on GitHub (May 13, 2019):

same problem

@linghu86 commented on GitHub (May 13, 2019): same problem

GiteaMirror commented

@Begounet commented on GitHub (May 23, 2019):

same problem

@Begounet commented on GitHub (May 23, 2019): same problem

GiteaMirror commented

@zeripath commented on GitHub (May 23, 2019):

Which version of Gitea are you using?

@zeripath commented on GitHub (May 23, 2019): Which version of Gitea are you using?

GiteaMirror commented

@Begounet commented on GitHub (May 23, 2019):

Gitea Version: 1.7.1
Edit: Do you think the issue has been fixed since?
Edit2: We just saw that the Gitea version goes from 1.7.1 to 1.8.1 in 5 months! You are so efficient!
Our admin has been told about it and will update the version tonight. I will be able to tell you about it tomorrow.
Edit3: Got an emergency, we had to delay the update. We will go back to you when it will be done :)

@Begounet commented on GitHub (May 23, 2019): Gitea Version: 1.7.1 Edit: Do you think the issue has been fixed since? Edit2: We just saw that the Gitea version goes from 1.7.1 to 1.8.1 in 5 months! You are so efficient! Our admin has been told about it and will update the version tonight. I will be able to tell you about it tomorrow. Edit3: Got an emergency, we had to delay the update. We will go back to you when it will be done :)

GiteaMirror commented

@Begounet commented on GitHub (May 24, 2019):

Ok, so we updated to 1.8.1 but the issue is still present.
Edit: the issue occured when I tried a "merge with rebase" but not with a "standard merge". Still investigating on reproducing the issue.
Edit: I made a new test by just adding one single 4x4 image (so it is filtered by Git LFS) and the merge didn't work.

@Begounet commented on GitHub (May 24, 2019): Ok, so we updated to 1.8.1 but the issue is still present. Edit: the issue occured when I tried a "merge with rebase" but not with a "standard merge". Still investigating on reproducing the issue. Edit: I made a new test by just adding one single 4x4 image (so it is filtered by Git LFS) and the merge didn't work.

GiteaMirror commented

@zeripath commented on GitHub (May 25, 2019):

OK so I bet this is same issue as #4760 and #732

@zeripath commented on GitHub (May 25, 2019): OK so I bet this is same issue as #4760 and #732

GiteaMirror commented

@zeripath commented on GitHub (May 25, 2019):

Now I am willing to bet that you have git-lfs version greater than 2.3.4 installed on your server and gitea user has a .gitconfig file containing:

[filter "lfs"]
	clean = git-lfs clean -- %f
	smudge = git-lfs smudge -- %f
	process = git-lfs filter-process
	required = true

If you remove that that should act as a workaround.

~~OK so that's not enough. Do your repos have .lfsconfig or is there an additional lfsconfig you're running?~~

~~In particular I'm highly suspicious that the there is lfs.storage set.~~

@zeripath commented on GitHub (May 25, 2019): Now I am willing to bet that you have git-lfs version greater than 2.3.4 installed on your server and gitea user has a .gitconfig file containing: ```ini [filter "lfs"] clean = git-lfs clean -- %f smudge = git-lfs smudge -- %f process = git-lfs filter-process required = true ``` If you remove that that should act as a workaround. ~~OK so that's not enough. Do your repos have .lfsconfig or is there an additional lfsconfig you're running?~~ ~~In particular I'm highly suspicious that the there is `lfs.storage` set.~~

GiteaMirror commented

@zeripath commented on GitHub (May 25, 2019):

~~I bet if you remove that - the problem will disappear.~~

@zeripath commented on GitHub (May 25, 2019): ~~I bet if you remove that - the problem will disappear.~~

GiteaMirror commented

@zeripath commented on GitHub (May 25, 2019):

~~Which is obviously not a complete solution but if it works then I know that I am at least on the right track.~~

@zeripath commented on GitHub (May 25, 2019): ~~Which is obviously not a complete solution but if it works then I know that I am at least on the right track.~~

GiteaMirror commented

@zeripath commented on GitHub (May 25, 2019):

OK, I think I've looked at this a bit more I think this is due to us previously cloning without setting --shared and without adding an alternative object dir reference for the pulled branch. What doesn't make sense though is that @Begounet has reported this on 1.8.1 - which also shouldn't be cloning without shared repository settings...

@Begounet I wonder can you reproduce this on master? What is your version of git lfs? Mine is:

:; git lfs version
git-lfs/2.3.4 (GitHub; linux amd64; go 1.8.3)

@zeripath commented on GitHub (May 25, 2019): OK, I think I've looked at this a bit more I think this is due to us previously cloning without setting --shared and without adding an alternative object dir reference for the pulled branch. What doesn't make sense though is that @Begounet has reported this on 1.8.1 - which also shouldn't be cloning without shared repository settings... @Begounet I wonder can you reproduce this on master? What is your version of git lfs? Mine is: ``` :; git lfs version git-lfs/2.3.4 (GitHub; linux amd64; go 1.8.3) ```

GiteaMirror commented

@ghost commented on GitHub (May 26, 2019):

This issue is not related to the version of git-lfs.
Gitea does not store the LFS objects in repositories/xxx.git/lfs/objects, but Git transfers the files from the local directory instead of Gitea's LFS server.

local-repo/merge-xxxxx.git/.git:

# git lfs env
Endpoint=/path/repositories/test1.git/info/lfs (auth=none)
Endpoint (head_repo)=/path/repositories/test1.git/info/lfs (auth=none)

Also, I don't think it's a good idea to download the LFS file to the local temp folder and merge the PR.

@ghost commented on GitHub (May 26, 2019): This issue is not related to the version of git-lfs. Gitea does not store the LFS objects in repositories/xxx.git/lfs/objects, but Git transfers the files from the local directory instead of Gitea's LFS server. local-repo/merge-xxxxx.git/.git: ``` # git lfs env Endpoint=/path/repositories/test1.git/info/lfs (auth=none) Endpoint (head_repo)=/path/repositories/test1.git/info/lfs (auth=none) ``` Also, I don't think it's a good idea to download the LFS file to the local temp folder and merge the PR.

GiteaMirror commented

@zeripath commented on GitHub (May 26, 2019):

@yasuokav it might actually be related to LFS version. For example prior to 11 months ago git LFS would definitely fail on multiple alternative repositories. I don't get this problem on 2.3.4 and I know git-lfs changed their handling of local clones at some point - likely around 2.6. So if you're experiencing this bug would you please tell me what your server's version of git-lfs is? I suspect it is highly pertinent.

Now, I agree that I'm not certain that grabbing the LFS objects in order to do a merge is a good idea. I will look at stopping this. If you are experiencing this bug there are a couple of things I would like to know:

If you edit the $HOME/.gitconfig for the user running git (or wherever you've changed $HOME to be) and either comment out or remove the LFS filter declarations does that stop this from occurring?
Do any of your affected repositories have .lfsconfig files?

So that's 3 questions but the git-lfs version question is pertinent. So please tell me.

@zeripath commented on GitHub (May 26, 2019): @yasuokav it might actually be related to LFS version. For example prior to 11 months ago git LFS would definitely fail on multiple alternative repositories. I don't get this problem on 2.3.4 and I know git-lfs changed their handling of local clones at some point - likely around 2.6. So if you're experiencing this bug would you please tell me what your server's version of git-lfs is? I suspect it is highly pertinent. Now, I agree that I'm not certain that grabbing the LFS objects in order to do a merge is a good idea. I will look at stopping this. If you are experiencing this bug there are a couple of things I would like to know: * If you edit the $HOME/.gitconfig for the user running git (or wherever you've changed $HOME to be) and either comment out or remove the LFS filter declarations does that stop this from occurring? * Do any of your affected repositories have .lfsconfig files? So that's 3 questions but the git-lfs version question is pertinent. So please tell me.

GiteaMirror commented

@ghost commented on GitHub (May 26, 2019):

@zeripath

git-lfs/2.4.0
It does help
No

@ghost commented on GitHub (May 26, 2019): @zeripath 1. git-lfs/2.4.0 2. It does help 3. No

GiteaMirror commented