"Coud not lock" Error with git tf checkin

Aug 15, 2012 at 6:47 PM

I was able to clone a TFS project, make a few changes and committed them to the local repo, but when I execute "git tf checkin" I get:

me@machine /c/gitrepo/tfs_project (master)
$ git tf checkin
Connecting to TFS...
Checking in to $/tfs_project: 0%
git-tf: Could not lock $/tfs_project


But I have no issue making checkins to the project using TFS in visual studio?

Aug 16, 2012 at 11:13 PM
Edited Aug 16, 2012 at 11:14 PM

Thanks for reporting this issue. This is actually by design. When Git-tf checks in changes into tfs, it first attempts to lock the root of the folder mapped. The lock is needed to avoid getting out of sync if other users check in changes while your checkin is being processed. Unfortunately, tfs locks binary files when they are edited by default (e.g. image files) and this can get annoying.

To work around the issue, you can specify --no-lock when checking in and that step will be skipped

git tf checkin --no-lock

Aug 17, 2012 at 3:26 AM

Hi Youhana, thanks for your reply,

I understand the purpose behind TFS obtaining locks -- my question is why this error occurs for me in git-tf, when I can perform the same operation using the team tools in visual studio with no issues? As the git-tf docs mention, 

git tf checkin --no-lock

Is considered generally unsafe and should be avoided.


So, my question is, using the same user and everything, why am I able to check in in visual studio, but not git tf?

Aug 17, 2012 at 3:47 AM


Thanks for reply. The reason this is more common with git-tf is that for example .. if you did a clone for $/project/folder in git-tf and then you changed $/project/folder/file.txt in git and committed the change and then tried to execute git tf checkin. git-tf will try to lock all of the files and folders under $/project/folder to ensure consistency between git repo contents and tfs. On the other hand if you try to do the same checkin in Visual Studio, workspaces ensure the consistency issue and thus Visual Studio only ensures that $/project/folder/file.txt is not locked and not all the contents inside the folder. With tfs automatically locking image files, hitting this issue becomes more common in git-tf because git-tf default checkin always tries to lock the root. 

Let me know if this explains the difference ? or if you have any further questions.



Aug 17, 2012 at 3:26 PM

Ah, yes this does explain it more fully -- but it makes me wonder how feasible using git tf really is, especially with a large team? If the --no-lock option is "dangerous", as the git tf help documentation states, it seems unwise to use that option very frequently?

Aug 20, 2012 at 1:42 PM

Hello jordanday,

I see how this can be annoying. I added a task on our backlog to address this issue and make the error less blocking/annoying. We will be addressing it in future releases.

Thanks for reporting the issue.



Aug 28, 2012 at 5:20 PM

Also, we spun up a new thread to talk about fixing this:  http://gittf.codeplex.com/discussions/393372