We are using LFS locking for a large number of binary files. We regularly have times when we lock/unlock thousands of files at once. To that end I have added a plugin to our tool to make lots of concurrent lock/unlock calls and once, but I'm rate limited by the lockcache.db becoming corrupt.
I see an easy way to make locking more usable, and that would be to have the lock (and unlock) commands accept more than one file at a time.
git lfs lock file1 file2 file3 ...
instead of
git lfs lock file1
git lfs lock file2
git lfs lock file3
The command could have a flag --all or similar that would refuse to lock any if even a single lock could not be acquired. The command would report which locks it could and could not acquire (naturally a --dry-run option would be nice as well).
Thoughts? If people are interested I might scrape the time together to make a pr.
We are using LFS locking for a large number of binary files. We regularly have times when we lock/unlock thousands of files at once. To that end I have added a plugin to our tool to make lots of concurrent lock/unlock calls and once, but I'm rate limited by the
lockcache.dbbecoming corrupt.I see an easy way to make locking more usable, and that would be to have the lock (and unlock) commands accept more than one file at a time.
git lfs lock file1 file2 file3 ...instead of
git lfs lock file1git lfs lock file2git lfs lock file3The command could have a flag
--allor similar that would refuse to lock any if even a single lock could not be acquired. The command would report which locks it could and could not acquire (naturally a--dry-runoption would be nice as well).Thoughts? If people are interested I might scrape the time together to make a pr.