Git (LFS): what is locking support? And should I enable it?

Question

\"New\" Git Comment:

Just today I ran across the following comment from Git for the first time (at least the first time I saw it):

Mikes-Mac$ git push
         


        

Answer 1

Locking support of Git LFS is documented here https://github.com/git-lfs/git-lfs/wiki/File-Locking.

Git LFS v2.0.0 includes an early release of File Locking. File Locking lets developers lock files they are updating to prevent other users from updating them at the same time. Concurrent edits in Git repositories will lead to merge conflicts, which are very difficult to resolve in large binary files.

Once file patterns in .gitattributes are lockable, Git LFS will make them readonly on the local file system automatically. This prevents users from accidentally editing a file without locking it first.

Git LFS will verify that you're not modifying a file locked by another user when pushing. Since File Locking is an early release, and few LFS servers implement the API, Git LFS won't halt your push if it cannot verify locked files. You'll see a message like this:

$ git lfs push origin master --all
Remote "origin" does not support the LFS locking API. Consider disabling it with:
  $ git config 'lfs.http://git-server.com/user/test.locksverify' false
Git LFS: (0 of 0 files, 7 skipped) 0 B / 0 B, 879.11 KB skipped

$ git lfs push origin master --all
Locking support detected on remote "origin". Consider enabling it with:
  $ git config 'lfs.http://git-server.com/user/repo.locksverify' true
Git LFS: (0 of 0 files, 7 skipped) 0 B / 0 B, 879.11 KB skipped

So in some sense you may consider it an advisory mutex, because:

• If you don't "lock" the file, you can't edit it
• Once you "lock" the file with git lfs lock, you can edit it, and the repository server will recognize that you are editing it
• The server will not accept commits changing the files you have locked by other people.

It is mainly added to help team managing large files to prevent merge conflicts.