git lfs lockable without lfs tracking does not mark files as readonly

[OneLineTwoBugs]

Hi,

as already mentioned in #2497, here as a new issue. This is using git-lfs 2.7.1 on Windows (bundled with git-for-windows 2.21.0 installer, 64bit)

To reproduce, I use a repo without a .gitattributes file, no LFS support so far, but some .hardToMerge files.

git clone http://.../repo.git
cd repo
echo "*.hardToMerge -text lockable" > .gitattributes
git add .gitattributes
git commit -m "make .hardToMerge lockable"

I expect that this commit should mark all .hardToMerge files as read-only, but it doesn't. In fact, I can push, pull and reclone as much as I want and the files are not marked as read-only. I assume this is the case because this repo never triggers LFS hooks, as it doesn't LFS track any files.

What does work however is executing git lfs lock bla.hardToMerge; git lfs unlock bla.hardToMerge. Now, the file is marked as read-only.

Sidenote: git lfs track "*.hardToMerge" --lockable; git add -A; git commit -m "lfs track hardToMerge" works as expected, but it also enables LFS tracking for *.hardToMerge, which I don't want in this case as the files are not very large (couple of MBs) and they stay very similar after changing them, so git's delta compression works very well on them. (they are MS Access DBs in my case). In fact, for my particular repo with a lot of history, using git lfs migrate import --everything --include="*.mdb" turns neat 800MB repository in a 12GB beast.

I guess the question is: Is using lockable in .gitattributes without ANY LFS tracking even a supported scenario?

[bk2204]

From looking at the code, I think what you want to do will work. However, in general, Git LFS only marks files read-only when a checkout occurs. So if you have the hooks installed, running git checkout . should cause the files to be marked read-only as you're expecting.

I'm not sure that this is necessarily a supported scenario, but if it does indeed work for you, then we'll endeavor not to break it.

[OneLineTwoBugs]

After more testing, I can provide some more details:

I can make *.hardToMerge lockable without lfs tracking work by using the following workaround:

git clone http://.../repo.git
cd repo
git lfs track ".DoNotDeleteDummyFile"
echo "*.hardToMerge -text lockable" >> .gitattributes
echo "foobar" > .DoNotDeleteDummyFile
git add -A
git commit -m "make *.hardToMerge lockable"
git push

The criteria for it to work is:

• there must be at least one "regularly lfs tracked" line in .gitattributes
• at least one regularly lfs tracked file must be present in the repo

Note that deleting .DoNotDeleteDummyFile in a later commit breaks the functionality again for new clones.

And you're right @bk2204, only git checkout seems to set the read-only flags. After the above commands, the files are not marked as read-only just yet. They will be after git checkout .

[bk2204]

I think what's happening here is that in new clones, without an LFS file, no Git filter processes get called, which results in the hooks not getting installed and therefore the post-checkout hook not triggering the files.

If that's correct, then this is less a limitation of Git LFS and more a limitation of Git. You may find that after performing a clone without the dummy file, you can run git lfs install && git checkout . and then things work for you. Whether that's acceptable in your case, I don't know.

One other suggestion which may be helpful: you can try using an empty file as your LFS dummy file if you want to go that route. Git LFS uses the empty file as its own pointer, which means that the repository won't actually depend on a Git LFS server to work, except for the locking.

[OneLineTwoBugs]

Thanks for the quick answers @bk2204. I've spent almost the entire day playing around with this and my testing supports what you're saying. I think git-lfs would work fine, it's just not executed if there is no LFS file.

For me, the workaround I described is good enough. I'll try to empty the file and see if the object disappears from the lfs storage, but I can live with the 6 bytes there anyway :) I'm using Gitlab Community Edition as a server which has a working LFS storage out of the box.

Feel free to close this issue if you think this is a Git limitation rather than a Git LFS limitation.

[bk2204]

Yeah, I don't think there's anything we can do to improve this situation. I'm glad you found something that works for you.