0

I'm new to the Git LFS locking feature, and have a question on how it works with Azure DevOps. Does it merely add read-only flags to the local branch? Or is there some magic on the server that prevents changes to locked files on the remote branch?

For example, I am able to change a locked file locally, and push those changes to the remote branch, without Azure DevOps blocking the "push". I'd expect something to verify that a locked file isn't being pushed to the remote branch. Sample:

# Verify lock 

C:\repo> git lfs lock .\test.png
Lock failed: There is an existing lock on this path.

# Simulate an app that changes the read-only flag, and makes changes to .\test.png

C:\repo> attrib -r .\test.png

# I opened .\test.png in MSPaint and made changes to it.

# Stage and commit changed file

C:\repo> git add .
C:\repo> git commit -m "testing changing locked file"
[master 57031ee] testing changing locked file
 1 file changed, 2 insertions(+), 2 deletions(-)

# Push commit. I'd expect this fail, since file is locked by another user, but it doesn't fail.

C:\repo> git push
Consider unlocking your own locked files: (`git lfs unlock <path>`)
* test.png
Uploading LFS objects: 100% (1/1), 11 KB | 0 B/s, done.
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 16 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 374 bytes | 374.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0
remote: Analyzing objects... (3/3) (267 ms)
remote: Checking for credentials and other secrets... (1/1) done (4 ms)
remote: Checking path lengths for refs and files...  done (5 ms)
remote: Storing packfile... done (161 ms)
remote: Storing index... done (102 ms)
To https://<myteam.visualstudio.com/DefaultCollection/<myproject>/_git/<myrepo>
   5b2a9d6..57031ee  master -> master
Adam
  • 1
  • 2
  • Hi friend, any update for this issue? Have you resolved this issue? Please check if my answer below helps to resolve your issue. If yes, you could [accept it as answer](https://meta.stackexchange.com/a/5235/515442) and If not, would you please let me know the latest information about this issue? – LoLance May 15 '20 at 05:16

1 Answers1

1

Push commit. I'd expect this fail, since file is locked by another user, but it doesn't fail.

Same behavior like yours with same command, but according to this document: Git LFS will verify that you're not modifying a file locked by another user when pushing.

If you want the push command to fail, try corresponding git lfs command (git lfs push origin master --all) instead of normal git push command(git push origin master).

The result if use git lfs push command:

enter image description here

LoLance
  • 25,666
  • 1
  • 39
  • 73