0

I'm having issues with github desktop, spewing the 'Files too large' warning when trying to commit, even though I ran the Git LFS configuration already. In total, there are 11 files causing this issue and they're all in the same folder.

I installed Git LFS and added the problematic folder to the git lfs track with git bash, as described here, but instead of associating a file type, I associated the problematic folder directory.

After having done this, and verifying that the .gitattributes file is indeed changed, I tried to commit my pending changelist with github desktop again.

The problem: I'm still getting the warning from GitHub Desktop, saying that Files are too large, with a suggestion that I should use Git LFS instead.

How do I solve this?

Edit 1: Added picture: Warning Edit 2: push -> commit

Thrindil
  • 143
  • 3
  • 17

2 Answers2

2

but instead of associating a file type, I associated the problematic folder directory

I suggest you don't do that, as it is clearly stated:

To associate a file type in your repository with Git LFS, enter git lfs track followed by the name of the file extension you want to automatically upload to Git LFS. source

run instead git lfs track '<problematic folder>/*.dll'. Indeed, .gitattributes do not, by default, track nested folders recursively - as suggested in issue #3963.

The rules by which the pattern matches paths are the same as in .gitignore files (see gitignore[5]), with a few exceptions:

  • negative patterns are forbidden

  • patterns that match a directory do not recursively match paths inside that directory (so using the trailing-slash path/ syntax is pointless in an attributes file; use path/** instead) source

See also issue #2214

Daemon Painter
  • 3,208
  • 3
  • 29
  • 44
  • I retried to run the git lfs track {large file directory here} again, and I can confirm that it works with a directory to a single file. Any idea how to specify certain file types to track, but only inside a certain directory: example: track only .dll files inside of a certain file directory, but no other .dll files? – Thrindil Dec 21 '20 at 16:04
  • 1
    For example, *.dll should match all dlls in your root, folder\*.dll should match all dll inside "folder" but nowhere else – Daemon Painter Dec 21 '20 at 16:11
0

It sounds like you already committed the large files to your normal git repo locally. You need to edit your commits with git rebase or git filter-branch.

Code-Apprentice
  • 81,660
  • 23
  • 145
  • 268
  • 1
    I did not commit the large files, since every time I was prompted with the 'Files too large' warning, I cancelled the commit. – Thrindil Dec 21 '20 at 15:30
  • 1
    @Thrindil What command gives the "files to large" warning? – Code-Apprentice Dec 21 '20 at 15:37
  • Pressing the 'Commit to main' button in github desktop. – Thrindil Dec 21 '20 at 15:38
  • @Thrindil I'm not familiar with Github Desktop's UI. I suggest checking two things: 1. Be sure the large files are not added to the git index. From the command line, you can do `git status` to check. You will have to do some googling to find the equivalent action in Github Desktop. 2. Add the folder containing these large files to your `.gitignore` file. I am assuming that doing so doesn't interfere with Git LFS. – Code-Apprentice Dec 21 '20 at 15:40
  • "Commit to main" is equivalent to just commit to "main" (ex master) locale branch, for those who wonder (like I was). No push. – Daemon Painter Dec 21 '20 at 15:43
  • @Code-Apprentice I did a 'git status' in git bash, and it says Untracked files: {directory of files I added to the git lfs track} – Thrindil Dec 21 '20 at 15:47
  • 1
    Also, for everyone suggesting to add the directory to my .gitignore file: that would solve my problem, yes. But that's also walking around the issue by just not using Git LFS, and I feel like I'll be stuck with the same question some day in the future if I take the easy route now. – Thrindil Dec 21 '20 at 15:53
  • @Thrindil Thanks for the clarification. I haven't used Git LFS, so I was uncertain how it interacts with `.gitignore`. That's why I explicitly stated my assumption above, which is incorrect from what you say. So please ignore that suggstion. – Code-Apprentice Dec 21 '20 at 16:08