Troubles because lfs is installed by default

[franksl]

Hello,
I kindly suggest to leave the lfs installation disabled by default. This caused lots of troubles in our team because not everybody was expert in git and also we wanted the repository and the file system to match exactly. As git lfs is an optional extension I think it should not be installed by default.
Thanks,
Frank

[dscho]

I am sorry to hear that this default caused lots of troubles in your team. However, it would cause much more trouble outside your team if I flipped the default to off, as users have come to rely on Git LFS being bundled and enabled by default in Git for Windows.

[franksl]

I understand the issue with keeping the existing status but I would like to point out that the choice of having lfs active by default make the windows environment different from the others (linux especially) when doing a default installation. My personal opinion is that this should be avoided by default. I'm not an expert with lfs so maybe we did something wrong. We found that a new repository was automatically using lfs under windows, but another windows machine that didn't have lfs installad had troubles with all the operations. The same repository cloned on a linux machine didn't expose any problems. Finding the real problem was not easy.
I think users should at least be clearly informed that the installation is setting lfs as active and for which files it's using it because it's a "feature" that is not standard git, but an optional extension.
I'll put a big notice in our internal documentation to warn users to not install lfs in any case, because for our use case this causes troubles and differences between environments.
Thanks anyway,
Frank

[derrickstolee]

Do you mean that your repository is creating LFS objects? That should not happen, because you need to specify which objects are being filtered into LFS blobs in your .gitattributes file.

Now, if the issue is differing behavior when cloning a certain repository, then it means that that repository is configured to use LFS and your Linux versions are creating the repositories incompletely (they are leaving the LFS indicator blobs on disk instead of smudging them into the actual contents).

[franksl]

We've just found that there are some .gitattributes files deeply nested in directories coming from external packages that contain lfs settings, I don't know why those files are there but we have no control over them (apart from deleting them each time an update is available), those are the supposed culprits. I suppose those settings are ignored if lfs is not installed. That is why we simply do not want lfs in our system, we need all files in a standard git format and repository. Lfs is a nice optional feature for sure but to us the automatic installation led to unexpected problems.
Frank

[derrickstolee]

This sounds like you are importing dependencies as source-level dependencies, and just taking their repositories as-is. This means that you should be using LFS if that's what they have specified in their repositories. Anything else will present incorrect repository data and will cause issues for you.

Disabling LFS is absolutely not the solution here.

[franksl]

I'm sorry but I don't have specific details, we are migrating this repository from SVN, which does not have any lfs concepts and everything works correctly as we need, so I'm pretty sure that everything lfs related can be ignored safely. This is what I need now. I don't know anything about those external packages, I just need a working repository without lfs or any other non standard features, so that I can create a situation where I have control. I understand it's an edgy situation so my initial issue was kindly a suggestion to leave lfs out of default installations.
Thanks for taking the time to analyse my case,
Frank

[derrickstolee]

If you think these .gitattributes files were created in error, then you should remove them from your repository.