'git lfs lock' on a file not tracked by LFS

[MarcelInTO]

What should be the behavior of 'git lfs lock' if its called on a file not tracked by LFS?

In my experiments with the comand line, it allows me to lock a file that isn't tracked by LFS. It subsequently shows that lock when I do a 'git lfs locks'. However, if I do a 'git lfs ls-files' it does not show that file as being tracked. Is that right?

git-lfs/2.13.3 (GitHub; windows amd64; go 1.16.2; git a5e6585)

[chrisd8088]

Thanks for the question. Yes, that sounds like the expected behaviour. Git LFS locks are a separate concept and can be applied to any file in the repo, regardless of whether the file is tracked by Git LFS. You can get a list of all active locks with git lfs locks (rather than git lfs ls-files, which lists tracked files).

[3Rton]

Sorry to revive a dead thread but I wanted to confirm something specifically about this.
I can also lock in gitignored paths/files that should not be part of the git nor lfs repo.

I feel like this would be worth opening and "issue" about but I wanted to confirm is that too actually intended behaviour?

[chrisd8088]

That's an interesting question! By all means open an issue and describe the situation you've encountered.

I foresee that it may not be straightforward to figure out how to apply gitignore rules without creating the possibility of confusion for users. For instance, if the logic is performed entirely in the Git LFS client, I might lock a file (registering the lock with the remote), while another user adds that file to .gitignore and pushes that change. After fetching those updates, I might find myself unable to unlock the file until I figured out that it was being ignored by .gitignore changes.

But we can certainly discuss implementation concerns in an issue, and having it there to track the idea is valuable, so by all means open an issue and fill in as many details as you're able. Thank you!

[bk2204]

It's intentional that we allow git lfs lock to lock files that aren't in the repo, because people can add or delete files in other branches and we want them to be able to lock and unlock files that aren't in their current branch.

[3Rton]

Ah those are actually great points.
For background: Im testing out Unreal Engine plugin that does automatic "check out/in" that flips lock/unlock. Right now running the plugins submit command with nothing seems to work as a workaround to unlock the stuff but its a little annoying.

Reading these scenarios, though, I guess it would be smarter try to fix the issue on their side. Thank you for such prompt replies, though!