gitea: LFS: Error 500 when merging pull request

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:

• Create a repository

• git lfs track '*.jpg'

• git add .gitattributes

• git push

  • Or just add a .gitattributes file *.jpg filter=lfs diff=lfs merge=lfs -text on the web interface

• Then with another user, fork the repository

• Add a jpg over the web interface

• create a pull-request with that jpg

• BOOM

OK I finally have a working and complete bug fix for this in #7082

Now, the problem is that people who have been merging “successfully”, i.e. not experiencing #732 won’t realise that if they delete their forks their LFS objects will disappear.

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

In terms of the potential deletion bug: Suppose you have repository A and fork B.

• Say you add an LFS’d file f with OID o to B on branch to-merge.
• Then merge to-merge into A
• Does an LFSMetaObject get created for f in A?
• What happens if you delete repo B? If there is no LFSMetaObject for f in A and there is no other user of the oid o then f will get deleted from the LFS.

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.

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.

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 code.gitea.io/git.

Issue here is that the pull request model uses code.gitea.io/gitea/modules/process package to construct a git command-line: https://github.com/go-gitea/gitea/blob/master/models/pull.go#L284 Therefore, the arguments set for code.gitea.io/git don’t get applied and the operation errors out.

Unfortunately, said package is used in many files to construct custom git command-lines. I originally assumed the git package would already provide an abstraction layer.

models/git_diff.go
models/release.go
models/repo.go
models/repo_editor.go
models/repo_mirror.go
models/pull.go

We could either instrument these code parts with the necessary arguments, or port the relevant bits for usage with code.gitea.io/git and get global argument support with it.