You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello everyone! I just discovered this project and I was immediately fascinated! The ability to choose what to download and what not from a single repository revolutionizes the submodule concept used so far to modularize the download of some components used only by members of a pre-production team.
Our team is a team of developers who have decided to use GIT over Perforce for a number of strategic and performance optimization reasons, having the ability to choose what to download from our projects is something we lack and that we have so far made up for through the use of submodules.
Having said that, we use LFS to handle large binary files. Furthermore, we save these binary files on a Cloud Object Storage, our LFS server is not on github but it is our custom server. This allows us to have total control of the binary files, encrypt them, backup them through redundancy mechanisms and keep them totally separated from our GIT repository which only knows the address of our LFS server.
Furthermore, LFS allows us to manage the lock of binary files in a granular way and this is essential for us to avoid collisions otherwise not resolvable by merge.
Having said that, for us LFS is fundamental, we cannot do without it (our server where to manage binary files, possibility to lock files, etc.), at the same time we would like to exploit the potential of file system virtualization offered by VFS for GIT.
Is it something possible? Is it possible to leverage both technologies on a repository?
In the end I think that VFS for GIT doesn't really care if the file is on LFS or on the repo, or am I wrong?
Unfortunately, VFS for Git cannot work with LFS since the virtual filesystem projection needs blob sizes from the Git remote which does not have the LFS objects on hand. Even further: smudge filters (such as CRLF conversion and LFS blob writing) are completely incompatible.
Perhaps you would be interested in using Scalar, which does work with LFS. It uses sparse-checkout to limit the size of the working directory and partial clone to reduce the initial clone size. You can get the latest version at the microsoft/git fork.
Activity
derrickstolee commentedon Jun 22, 2021
Unfortunately, VFS for Git cannot work with LFS since the virtual filesystem projection needs blob sizes from the Git remote which does not have the LFS objects on hand. Even further: smudge filters (such as CRLF conversion and LFS blob writing) are completely incompatible.
Perhaps you would be interested in using Scalar, which does work with LFS. It uses sparse-checkout to limit the size of the working directory and partial clone to reduce the initial clone size. You can get the latest version at the
microsoft/gitfork.