`GIT_LFS_FETCH_INCLUDE` environment variable is not applied to clones of LFS files in submodules

[overlordofmu]

Describe the bug

If a submodule uses Git LFS, the GIT_LFS_ENABLED environment variable is used for the submodule clone. However, the GIT_LFS_FETCH_INCLUDE environment variable which determines the filetypes that will download the actual file instead of the Git LFS pointer is ignored for the submodule.

To Reproduce

Steps to reproduce the behavior:

1. Fork the repository at https://github.com/overlordofmu/git-lfs-only
2. Create a Netlify site and link it to the forked repository (no build command and no publish directory - leave them empty)
3. Add the environment variables GIT_LFS_ENABLED=1 and GIT_LFS_FETCH_INCLUDE=*.jpg,*.png,*.jpeg,*.svg,*.gif,*.pdf,*.mp4,*.bmp,*.webp,*.mov to the web UI
4. See that both example.mov and example.mp4 work on the deployed site (right-click and save as to example).
5. Fork the repo here: https://github.com/overlordofmu/git-lfs-in-submodule
6. Again add the environment variables in the web UI.
7. See that both example.mov does not work while example.mp4 does even though both are Git LFS files on the submodule. The .mov file will be a Git LFS pointer like so:

$ cat example.mov
version https://git-lfs.github.com/spec/v1
oid sha256:6e26b46329f7e3ff304c592a93df60bb0f05ba9866373970d1b067bad6f5e49c
size 216396

Configuration

N/A

Expected behavior

The GIT_LFS_FETCH_INCLUDE environment variable will also apply to any submodules using Git LFS.

Build Output

N/A

Additional information

First reported here: https://answers.netlify.com/t/gitlfs-inside-submodule-not-working-correctly-for-some-file-types/49676

[hayden2114]

Friendly +1 on this bug. Would be awesome to get this submodule + gitLFS implementation working correctly

[hayden2114]

Any update on when this bug might be fixed or investigated?

[overlordofmu]

Hi, @hayden2114. The investigation phase is complete as the issue is well understood and the responsible code is known. I don't have an official ETA for a fix, though.

I want to be transparent as I can. I can give a best guess about a timeline and, before I do so, I want to be clear I'm not trying to dismiss you. I only want to be clear about the timeline for a fix so you don't delay a decision for a change that will not come soon. I would say that it is unlikely to be fixed in the next three months. Whether or not it would be fixed in the quarter after that is also not guaranteed.

As to why I say this, it is because this is a relatively recent discovery and one which so far only one person has reported. As there are other issues impacting a larger number of people, those issues are currently being prioritized over this one. It isn't that this isn't important - only that when prioritizing the issues the impact of this issue is smaller relative to other unresolved bugs.

I hope this makes the timeline for a fix more clear.

[hayden2114]

@overlordofmu thank you for the reply. That timeline is obviously way longer than I was expecting, which is disappointing, but I do greatly appreciate your honesty as it helps me plan the best course of action for my companies current and future projects.

[hayden2114]

@overlordofmu One thought I just had was that it may take 6 months for Netlify devs to get around to fixing the bug in the code but a temporary and much simpler fix to the problem would be to extend the default GIT_LFS_FETCH_INCLUDE statement to GIT_LFS_FETCH_INCLUDE=*.jpg,*.png,*.jpeg,*.svg,*.gif,*.pdf,*.mp4,*.bmp,*.webp,*.glb,*.gltf,*.basis,*.ktx2 so the submodule picks up on those additional 3D file types I'm looking for. I could be totally wrong but I would imagine that wouldn't take a Netlify dev more than a couple hours, maybe even less than an hour. And I wouldn't think that would negatively effect any Netlify users.

If this would be considered by the Netlify team that would be greatly appreciated.

[KockaAdmiralac]

Can #371 be considered while this bug is being resolved?