-
-
Notifications
You must be signed in to change notification settings - Fork 5.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LFS: Error 500 when merging pull request #732
Comments
@fabian-z could you give some idea? |
The error is caused by running Gitea under an OS user with the LFS client hooks installed - a workaround is to create a new user account and run Gitea using that account. This was - apparently incompletely - fixed in my PR by disabling the hooks for external git operations using global command arguments in Issue here is that the pull request model uses Unfortunately, said package is used in many files to construct custom git command-lines. I originally assumed the
We could either instrument these code parts with the necessary arguments, or port the relevant bits for usage with |
Since no PR to be sent, I will move this to v1.2 |
@fabian-z This is still happening with LFS enabled. I'm unsure how to run gitea as a local user account. |
Got same error and here is gitea.log record:
Application Version: 1.7.0 |
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. |
Ah! I think I understand what's causing this! Can anyone still reproduce this on 1.8+? |
I think I may finally have found the cause. I suspect 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. |
@Begounet are you able to come up with a minimal example for me? I would love to exactly figure out what is the problem here. I know it's due to the lfs smudge filter but I'd like to catch it in the act. I think #7062 and this workaround won't be the complete solution because we do need to be aware of lfs additions on merging - i.e. What happens if you add an LFS file through a merge and then delete the adding repository - I'm highly suspicious that this file will be deleted from the LFS. |
I will try to setup a server from my home, using the same LFS and Gitea versions but it will take some times since I am not really used to that kind of stuff. Unfortunately, I cannot provide access to our enterprise private servers. But I think the most important thing is to at least have once LFS filtered file in the commit you want to merge. And your workaround indeed worked! Thank you!
Shouldn't be the expected behavior? |
@Begounet Was there anything special about your filter configuration in .gitconfig? Was it exactly the same as I put in #732 (comment) ? The other question is what version of git do you have? It appears that my PR #7062 is unlikely to be required as we should be setting these (except for process) anyway: gitea/modules/setting/setting.go Lines 459 to 478 in 31557b1
|
So perhaps you have the lfs process running... I'll adjust #7062 to ignore the process at this point instead. |
In terms of the potential deletion bug: Suppose you have repository A and fork B.
You would need to check the LFS directly to see if it has disappeared. This problem wouldn't just affect users like you who are likely affected by the lfs filter process but every user of LFS. I think gitea needs to handle lfs filtering itself. |
And then he founds theses lines in the global config (/etc/gitconfig). |
FINALLY! I've managed to reproduce this, and it's stupidly easy to do. Oh dear. I'm so sorry this has not been fixed - I can't believe that this has been here for so long. OK, to reproduce:
|
On merge we walk the merge history and ensure that all lfs objects pointed to in the history are added to the base repository. This switches from relying on having git-lfs installed on the server, (and in fact .gitattributes being correctly installed.)
Hi, unfortunately we're experiencing this old "500" error when merging pull requests with files in lfs through Gitea.
Also it comes with error log same as reported in #4463. We've checked for the .gitconfig entries mentioned above and there are none. |
@kleszcz the mentioned fix for this not present in the 1.8.3 release that you are using. You would need to use master branch or wait for the 1.9 release (1.9 release candidate will be available very soon and hopefully final 1.9 release not terribly long after). |
…itea#7082) On merge we walk the merge history and ensure that all lfs objects pointed to in the history are added to the base repository. This switches from relying on having git-lfs installed on the server, (and in fact .gitattributes being correctly installed.)
[x]
):Description
I wanted to test the master version of Gitea in order to check the new features including LFS.
I added a new repo in Gitea, pushed a mp4 file which I did set for LFS. The file was properly pushed and stored using LFS.
Then I branched the "master" branch into a "dev". I push a "test.html" file into the "dev" branch. Then in Gitea I created a pull request. Gitea said there were no conflict and that the branch can be merged automatically. But when merging, I got a 500 error (see log above). It seems related to the LFS.
Dunno if I did something wrong, but seems to be a bug to me.
Thanks
The text was updated successfully, but these errors were encountered: