Git (LFS): what is blocking support? And should I turn it on?

Question

"New" Git Comment:

Today I first met the following comment from Git (at least the first time I saw it):

Mikes-Mac$ git push Locking support detected on remote "origin". Consider enabling it with: $ git config 'lfs.https://github.com/<my_repo>.git/info/lfs.locksverify' true Everything up-to-date Mikes-Mac$ 

What is this Locking support ? Is this something like locking a mutex for LFS (large file storage)? If so, is it not necessary to do anything at all on Git? (In a minimal order, how else can you set the "ordering" of the history of the log? Worse, can I have a binary file corrupted by simultaneous writing?)

My actions

Recently, I did not do anything different in this repository and did not do anything different with this repository compared to the others that I installed with LFS.

Therefore, I suppose this is a new comment provided to the “world” to inform us of new features.

No obvious documentation

However, neither Google search nor a quick search on their documentation led me to anything to explain this. So, I was left wondering:

• What is this lock?
  • Is this a mutex? If so, how can my repo function without it?
  • Is it limited only to LFS? How is it different from regular git file locking?
• What are the pros and cons of adding lock support for LFS?

Answer 1

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

Git LFS v2.0.0 includes an earlier version of file locking. File locking allows developers to block the files they update so that other users cannot update them at the same time. Parallel changes in Git repositories will lead to merge conflicts, which are very difficult to resolve in large binary files.

After the file templates in .gitattributes locked, Git LFS will make them readonly on the local file system automatically. This prevents users from accidentally editing the file without locking it.

Git LFS verifies that you are not modifying a file locked by another user on click. Since file locking is an earlier version, and several LFS servers implement the API, Git LFS will not stop your push if it cannot check the locked files. The following message will appear:

 $ 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 a sense, you can consider this an advisory mutex because:

• If you don’t lock the file, you cannot 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 does not accept committing changes to files that you have blocked by other people.

This is mainly added to help the team manage large files in order to prevent merge conflicts.