We are using Git LFS to store .png files in our GitLab repository. However, there is a possibility a commit will contain a raw .png file instead of a Git LFS pointer file. (For example, someone might not have Git LFS installed and push a raw file to the repo, or they might commit & push without git hooks). If neither the author nor the reviewee notices & the file ends up in the main branch, the image will end up permanently hogging up space in the history of the repo.
Question: Is there a way to make GitLab reject commits that contain binary files that ought to be Git LFS files? Or perhaps another similar solution?
Essentially, we seem to have the same problem as in this question, but we're looking for ways to prevent it from happening in the future (eg. with a new contributor who may not have or know about Git LFS).
I have not found anything specifically about rejecting files that ought to be Git LFS files. I guess one could try to implement a custom Git server hook (or worse, a pipeline job -- would ignore intermediate commits) that would invoke a custom script that would traverse the repo and look for non-LFS .png files. This seems very hacky though.
It would be great if there was a solution specifically for this problem, and I suppose there ought to be one since it seems to me anyone who uses Git LFS would suffer from the possibility someone accidentally uploads a raw file.
As far as I know GitLab is not able to do this check for you (it would be a useful feature in my opinion).
If you use merge requests, add a CI check with the command git lfs fsck --pointers, available in git lfs since version 3.0.1.
As you say it is a good idea to check all new commits, not just the last one of the MR. You can pass a range of commits to git lfs fsck.
So something like:
git lfs fsck --pointers $CI_MERGE_REQUEST_DIFF_BASE_SHA..HEAD
If you allow pushing to the main branch, you could do something similar in a server side hook but I'm afraid that would make the push take a long time (and be much more complex to setup/debug).