Feature: File locking in User interface

[davidsvantesson]

Git LFS support file locking. File locking with git lfs can be used without storing the file as a git lfs file.

I would like to have the following functionality in Gitea UI:

• Respect file locking when editing. If a file is locked with git lfs it shall not be editable in the UI. (Respect LFS File Lock on UI #8719)
• Respect file locking, no upload of file if locked (Prevent upload (overwrite) of lfs locked file #8769)
• Show if a file is locked and who locked it (Respect LFS File Lock on UI #8719)
• See all locks and force unlock in repo setting interface (Make repository management section handle lfs locks #8726)
• Check locks on server side when pushing (LFS locks not enforced on server side (can push commit modifying a file locked by another user) #11094)
• Warn if user edits file that is lockable (.gitattributes), but not locked (?)
• Support lock file and unlocking (your own lock) in UI. Files not marked as lockable can be locked but with warning?

[blueworrybear]

@davidsvantesson @guillep2k @lunny
I make a update to respect file locking. Files will not be editable if LFS locked.

However, I'm not sure if it's a good idea to allow user lock files in the UI.
For example, I'm not sure how to check is a file is lockable.

I'll keep working on this enhancement. I will send a PR at first at first.

[davidsvantesson]

Better to make smaller PRs than implement all at once. Determining if a file is locked is a first good step.

Locking a file actually doesn't require the lockable attribute. The lockable attribute is only used to make files read-only when they are not locked. But I am not sure if it is a good idea to allow locking a file in the UI that has not been set as lockable.

This is what I can find about determining if a file has the lockable attribute:
https://stackoverflow.com/a/56492205

[zeripath]

I think you can't really rely on the lockable attribute in the .gitattributes file - probably if the attribute isn't there you might have to put a warning up but people can have attributes set in multiple ways so only providing locking to those files in .gitattributes would be annoying to them.

(As an aside when you create a file in the editor we read the .gitattributes to determine if it should be lfs'd - because there's no other way of knowing.)

[davidsvantesson]

If a file is "lockable" according to .gitattributes, shouldn't we force to lock the file before editing? I mean that would best correspond to how a checkout on computer works; The file is read-only until locking the file.

[zeripath]

I suspect it's better to just give the user the option to lock in all cases, but have a slightly different UI when editing a file where the lockable attribute is set. Allowing people to lock new files is harder - you'd have to remember to remove the lock if they change the filename, and you can't easily test if the filename would be lockable without making a temporary repo (this could potentially be avoided), an index from the branch and then running git check-attr - it's really not free although I think we could make the index creation in read-tree a bit more efficient only reading in the .gitattributes. Similarly if you lock a file when editing are you supposed to lock the new file you're renaming it to?

We also don't have a mechanism to force the user to unlock if they've locked for any period of time. So if they navigate away a user could use this UI to lock all files.

The other issue is which .gitattributes do you interrogate - presumably you look at the one for the branch you're editing. Git lfs locks are locks for the whole of the repo.

[davidsvantesson]

Is git lfs using the .gitattributes file of the currently checked out branch, or the master (default) branch?

[zeripath]

Git lfs uses what you have checked out or in your index. It runs git check-attr on the file.