bk2204
commented
4 years ago => Because of this Git clone time is more. I tried LFS Concurrent option to make git clone a bit faster. (But still it takes time) . Will git fetch will be faster in Git LFS ?
The answer is that it depends. Normally, when you clone a repo using Git LFS, you download the entire Git history but only the Git LFS files for the version that you're checking out. If you have a small number of Git LFS files in your repository, then you'll likely spend more clone time because your repository won't be much smaller but you'll need to download the LFS files afterward. If, on the other hand, you have a lot of large files, it will likely be faster indeed.
Git LFS doesn't check out files when you fetch a Git repository, but when you check out a branch or other commit. So the git fetch operation will be faster, but then you'll need to download the LFS objects when you check out the new version.
Note that by default, only the LFS files for the current branch are downloaded from the repository, so your repository may be smaller in actual use than when you do the actual conversion.
Is LFS Objects are not compressed as Git Objects ? and because of that GIT LFS Objects sizes are bigger ?
That's correct. A lot of large objects don't compress well, such as images (which are often compressed) and textures, so we don't use compression. There is an issue tracking adding support for that, but for now, we don't have support for it.
Now Question to Git LFS experts : Do you recommend using Git LFS for above sources ?
Partly this depends on various factors. 50 GB is large for a repo, and it's possible your hosting provider (whether that's in the cloud or on premises) may encourage you to use Git LFS because the repo will perform better. If your developers are on fast networks and always have network connectivity, then Git LFS is a good choice, especially if disk space is at a premium. If you have developers who are sometimes on slow connections or who work offline and don't have disk space concerns, then you might be better off with a large repo.
I do recommend not checking additional third-party binaries (like executables and libraries) into your repo, but if you end up needing to do that, then yes, I definitely recommend Git LFS. Otherwise, your repository will continue to grow and eventually reach a unmanageable size.
=> I am migrating our source which is in Perforce source control to Git . I am in the confusion of using Git LFS or just upload the repository as it is Git.
=> Our perforce source code is huge around 50 GB => It has some third party library (.exe ,.dll,*lib) etc files. Currently there is NO artifactory server setup hence we cant use artifactory now. (that option is not available ) => We tried GIT lFS test migration by using git-lfs-migrate command but we are seeing size of GIT LFS repo is more than non LFS git repo. => Because of this Git clone time is more. I tried LFS Concurrent option to make git clone a bit faster. (But still it takes time) . Will git fetch will be faster in Git LFS ? Is LFS Objects are not compressed as Git Objects ? and because of that GIT LFS Objects sizes are bigger ?
Now Question to Git LFS experts : Do you recommend using Git LFS for above sources ?