Git LFS "Lock" Feature?

[djtooley]

We have some requests for the ability to "Lock" binary files (example: "*.docx") that are in our Git Repo, to avoid simultaneous editing of binary files.

I notice that Git LFS has the "Lock" feature. I tested it from the command line and it appears to work.

Is this a feature that is planned for Fork's LFS support?
(or is it already there, and I just missed it?)

Thanks!

[alectron]

This would be really really good to have indeed!
Churs.
c.

[DanPristupov]

Thank you for creating this issue.

I don't (and probably will not) use it during my daily workflow so I'd like to hear more info from the actual users.

This is a quite complex feature. I'm thinking out loudly how it might look like:

• First we need to make a file lockable. May be it can be some context menu option for LFS-tracked file.

• Locking and unlocking seems to be simple and can be added to some file context menu. But to which one? Showing it in Working Directory Changes doens't make much sense because file is already changes and it's too late to lock it. Searching for the file in FileTree view in commit details is too long.
  May be 'Open Quickly' command can help here. Press Ctrl+P, 'lock', find the file, enter. Same with unlock.

• Do you need to see the list of locked files somehow? Should this be a separate view? We need to remember that retrieving the locked files list from the server takes at least 2 seconds (which is quite long).

[alectron]

Hai,
thanks for sharing the thoughts.
I come from a Game-Dev / Perforce background, and would like to use git/bitbucket/etc as an alternative for such (so take my input with a grain of salt as I am still learning the git ways...).
Also, this is a requirement for collaborative team projects mostly and when a lot of binary files come into play...

As for the questions (from my perspective):

File Tree tab & file context menu in the TreeView would be the most likely entry point in Git-Fork for me.
As for your worries - in Game-Dev, a File-Lock itself will often be issued from another tool anyway i.e. Unreal/Unity Editor/Plugins themselves and passed onto the VCS (and usually before, or at the point of the very first edit of said file - which is when conflicts would appear when attempting to set the lock - and it's mostly about communicating the fact that another user is working with the file for the VCS)...
So in that context, git-fork would mostly act as an overview / VCS management tool, and showing locked files (via an icon/marker) in File-Tree only is pretty standard as well as navigating the TreeView to lock a file is generally not considered 'too long' for people used to that world (i.e. people from Perforce etc are very much used to having to traverse the file tree regularly anyway... and the time frame needed to work on a binary file could be multiple days to weeks. So spending 2 seconds to set a lock is a small price to pay, opposed to throwing away weeks of work :D ).
If there's more git-o-logic ways to do this, I'm very curious though.

And yes, for that point of view, seeing a list of locked files would be a great feature as well, either as its' own tab, or as a filter in File-Tree view.
Also, it would be great to be able to quickly see all locks from a user/me, as well as all locks set on a project by everyone (hence a File-Locks tab would make sense).

Churs.
c.

[djtooley]

I'm glad others are showing interest in file locking!

Like @alectron, I also come from a Perforce / Game-Dev background, and have only been using Git for about a year, in a different industry. Our small company has chosen Fork because we programmers were making the decision. (we like it!)

Our needs are:

1. Programmers are fine with vanilla Git - it works well for code, obviously.
2. We have several non-programmers who have needs for shared binary file editing (primarily .docx, but also more complex multi-data-file applications).
3. The obvious choice for shared binary file editing is locking the files. As former Perforce users, we're familiar with how smoothly this can work.
4. Some of our users are somewhat non-technical (I mentioned .docx?). So interface simplicity is a good thing.

How would I implement this?

1. Easy access to a file tree is huge, because it becomes that (non-tech) person's primary interface. It answers the question: "what is locked, what is not locked?"
2. Being able to return to the directory view they were at when they closed the app is good. Having to start navigating at the root every time is painful.
3. Also, a way to show a list of just the locked files is very important. (maybe a filter?)
4. Being able to paste a directory name or filename, to jump to that location in the file tree would be used frequently.
5. I find the current ways to access the file tree in Fork to be awkward. ESPECIALLY when the tree gets deep.
6. Showing the name of who has a file locked is incredibly helpful. (mouse-over tooltip is fine)
7. Selecting files, then right-click context menu to lock/unlock is good. Toolbar button also good.
8. Being able to select a directory for lock/unlock (so the "lock/unlock" happens on all the files contained in that directory, recursively) is helpful. Perhaps with a warning if more than X files are being locked/unlocked at a time.

That's the approach I would take, if I were coding it.
Does that help?

We looked for other Git GUIs to see if anybody did this well, and in the short time we spent looking, we didn't find any.

--- Doug

[DanPristupov]

Thank you very much for all the feedback. Tanya has started working on the LFS locks already.

I have another question, could you show me please the output of the following command on your biggest repository: time git lfs ls-files | wc -l

This command shows number of LFS files in your repo and the time it takes to list them.

Example of the output:

$ time git lfs ls-files | wc -l
2
real    0m0.796s
user    0m0.015s
sys     0m0.046s

Thank you in advance.

[djtooley]

I don't have this git repo under linux, but wrapping a timer around "git lfs ls-files" in a Windows bat file, then running it three times gives me about six and a half seconds: Elapsed Time for timer "Default": 0:00:06.50 Elapsed Time for timer "Default": 0:00:06.52 Elapsed Time for timer "Default": 0:00:06.42 This was our largest repository (>40,000 files), but so far it has no tracked LFS files. (it's mostly code, and related) Our "Documentation" repo is where we're intending to use the locking. (People want to lock their MS Word ".docx" files....) That repo is tiny in comparison. Running the command gives: Elapsed Time for timer "Default": 0:00:00.42 Elapsed Time for timer "Default": 0:00:00.34 Elapsed Time for timer "Default": 0:00:00.40 Yet another repo, where we have a need for LFS files is about 1 second: Elapsed Time for timer "Default": 0:00:01.27 Elapsed Time for timer "Default": 0:00:00.94 Elapsed Time for timer "Default": 0:00:01.0 And yet another repo, where we're not intending to use LFS, is: Elapsed Time for timer "Default": 0:00:02.65 Elapsed Time for timer "Default": 0:00:02.18 Elapsed Time for timer "Default": 0:00:02.21

…

On Thu, 30 Jan 2020 at 11:36, Dan ***@***.***> wrote: Thank you very much for all the feedback. Tanya has started working on the LFS locks already. I have another question, could you show me please the output of the following command on your biggest repository: time git lfs ls-files | wc -l This command shows number of LFS files in your repo and the time it takes to list them. Example of the output: $ time git lfs ls-files | wc -l 2 real 0m0.796s user 0m0.015s sys 0m0.046s Thank you in advance. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#605>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAYRXFOZFT6RNMS3R55EOI3RAL6XJANCNFSM4KCGPZJA> .

[alectron]

Hello,
I had no chance to check until today, and from our largest repo (20k files, 9GB of data, most of it binary / LFS tracked) I got:

real 0m6,809s
user 0m0,015s
sys 0m0,124s

Hope this helps.
c.

[DanPristupov]

Thank you.

I didn't expect such a bad result, to be honest. 6 seconds for the operation to get list of LFS files is super long. Looks like LFS gets list of all repository files and then checks each if it belongs to LFS (which is O(n)). This will really complicate things for us but we will figure out something.

[DanPristupov]

As a start, we introduced the ability to lock/unlock LFS files in Fork 1.45.

[djtooley]

Much appreciated!

…

On Fri, 14 Feb 2020 at 12:28, Dan ***@***.***> wrote: As a start, we introduced the ability to lock/unlock LFS files in Fork 1.45. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#605>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAYRXFITAYMIWXY3M7J2VMDRC3IENANCNFSM4KCGPZJA> .

[JamesYFC]

Thanks for the effort so far. We're using file locking in larger projects with plenty of LFS files, and while the ability to lock and unlock files is a start, not being able to see what's locked and what's not locked at a glance is a real killer for the non-devs who don't use the terminal.

It would be great if there was a little lock icon or somesuch in the corner of the files' icons to show that the file is locked.
Even if the refresh locks operation takes a few seconds, could we try running the command, say, once every 30s?

Also, we're not able to see who has a particular file locked. It just says file is already locked.
The best we can get is trying to unlock a file that we've first tried to lock and realised it was already locked by someone else. Then it gives us the user id, but not the name.
When you run git lfs locks, it shows the name and IDs, so presumably that information shouldn't be difficult to retrieve.

[Carghaez]

Hello there! I have been using your GIT GUI for several months and I love it!

As the others says, It would be really useful to have the view of all locked files through a table, to be able to sort it or even right-click on one of the rows and then perform the unlock operation (git lfs unlockk --id XXXX).

I have personally implemented through Custom Repository Action "LFS show locks" with git lfs locks command

[Thane5]

I was almost about to open another issue when i saw that this one is still open, so i'll just use it.
Anyways, here is a (kind of obvious) concept of what a more visible file-locking window could look like:

[Carghaez]

Good idea! I hope it can be implemented this way, that would be great!