[LFS] The "Force unlock" button is available only after an unsuccessful attempt to unlock files

Description

Besides the recently fixed bug (issue #3736 (closed)), there is another users issue.

There are some different workflows for dealing with a lot of binaries. Usually LFS is configured for this, configured the locking capabilities for binary files. One of the workflows implies that different binaries can be blocked by many different users.

So, let's start with the fact that there are a lot of locked files. Now more about the process:

• There is a "main" branch, which is updated quite often (small branches merge there)
• There is a minor big "design" branch in which many users work and blocks many different binaries.
• When the "design" branch starts to lag far behind the "main" branch, one operator starts to rebase a large minor "design" branch
• Rebase requires all affected files to be unlocked at this time.
• the operator who makes the rebase can select all files in the "LFS Lock" dialog box, press the "Unlock" button and wait a long enough period of time for the unlock operation to complete with an error (since there are many files locked by other users), and ONLY AFTER unlocking errors, the "Force unlock" button appears. This is a very unpleasant problem.

It is very sad that we have to wait for this extra time. One command "lfs unlock" for one file takes about 8 seconds. If there are more than 100 files (this is a very common situation in a large project), then it takes a long time to wait for the necessary "force unlock" button to appear (8 sec * 100 files = 800 sec or 13 minutes and 20 seconds). After the button appears, you need to wait the same amount of time until the operation is repeated with the necessary "force" flag. Total 26 minutes and 40 seconds.

One of the suggested solutions

I suggest giving users the ability to halve this time. To do this, you just need to enable the user in the "lfs locks" dialog box to enable the "force" flag BEFORE starting the "Unlock" command.

What steps will reproduce the problem?

1. Set up a test repository, configure LFS to track files, as well as add the ability to lock for any type of files, for example:

git lfs track "*.umap" --lockable

2. Ask another user who has access to this repository to lock some locked file, for example:

git lfs lock "Content/DownToEarth/Maps/MainMenu1.umap"
git lfs lock "Content/DownToEarth/Maps/MainMenu2.umap"
...
git lfs lock "Content/DownToEarth/Maps/MainMenu100.umap"

3. Now in the root folder of your local repository, right-click on the context menu item TortoiseGit -> LFS -> Show locked files
4. Select all files in the list...
5. and click the "Unlock" button. Wait a long time until the operation is completed with errors (because the files are locked by another user). Only then will the "Force unlock" button appear.
6. Press the "force unlock" button and wait for the operation to complete. The files will be successfully unlocked.

What is the expected output? What do you see instead?

The expected improvement will be to remove step 5 completely. And change step 6 as follows: 6(->5). In the "lfs locks" dialog box, enable the "force" checkbox and press the "unlock" button and wait for the operation to complete. The files will be successfully unlocked.

What version of TortoiseGit and Git are you using? On what operating system?

git --version
git version 2.31.1.windows.1

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

TortoiseGit 2.12.0.0 (C:\Program Files\TortoiseGit\bin)
git version 2.31.1.windows.1 (C:\Program Files\Git\bin; C:\Program Files\Git\mingw64\; C:\Program Files\Git\etc\gitconfig)

windows 10 corporate x64
version 1909
Build the OS 18363.1533