Locking Files Using Git LFS

[kenrao]

Hello,

I recently noticed the support for Git LFS in the 5.2.0 version of the Git client and decided to experiment locking the .xpr file (or any file in Git) as suggested in this article:
https://docs.gitlab.com/ee/user/project/file_lock.html

I’m curious to know if there are any reasons why we shouldn’t implement this across all our repos. We’ve tested it and it seems to work well. This could potentially solve our recurring issue of new writers unintentionally committing and pushing the .xpr project file.

Here’s the procedure we followed:

1. Created a .gitattribute file containing the following line and added it to a test repository:

Code: Select all

*.xpr lockable

2. Executed the following command to lock the sample.xpr file:

Code: Select all

git lfs lock sample.xpr

The system prompts for the GitLab username and password:

Code: Select all

C:\Users\user1\git\repo>git lfs lock sample.xpr
Username for 'https://gitlab.com': user1
Password for 'https://user1@gitlab.com':
Locked sample.xpr

Now, when another user tries to edit the sample.xpr project file in Oxygen XML Author, they can commit the file, but when attempting a push, they receive a dialog with the message:
“Cannot push. The pre-receive server-side hook declined the operation.”

image.png (23.5 KiB) Viewed 321 times

When I tried to push from the git command line, I received the following message:

Code: Select all

C:\Users\user2\git\repo>git push
Username for 'https://gitlab.com': user2
Password for 'https://user2@gitlab.com':
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 1.83 KiB | 1.83 MiB/s, done.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0
remote: GitLab: The path 'sample.xpr' is locked in Git LFS by user1
To https://gitlab.com/repo/test.git
 ! [remote rejected] branch1 -> branch1 (pre-receive hook declined)
error: failed to push some refs to 'https://gitlab.com/repo/test.git'

And for unlocking the files,

• For the user who locked the file, the command is:

  Code: Select all

  git lfs unlock sample.xpr

• If another user wants to unlock it, they need to use the --force flag:

Code: Select all

C:\Users\user2\git\repo>git lfs unlock sample.xpr --force
Username for 'https://gitlab.com': user2
Password for 'https://user2@gitlab.com':
Unlocked sample.xpr

Once the file is unlocked, users can push it from the Git Client without any issues. This method allows admins to keep the project file locked and only unlock it when they need to update it.
I would appreciate any insights or suggestions regarding this approach.

Thanks,
Kenneth

[xephon]

Hi Kenneth,

This is very interesting. We have a monolithic repository with dozens of *.xpr files. When we start a new project, we generate a skeleton of directories and files, also *.xpr files, with a script. It would be easy to unlock *.xpr files, commit the new one and then lock them again in the script.

But as long as modified *.xpr files show up in the staging view and throw a cryptic error message when trying to commit them, this approach is not user-friendly enough for our needs. It would be again something what needs to be explained (Git LFS, locking, and so forth) and the technical writers are already flooded with complexity.

To conclude, great function, could solve the annoying *.xpr issue, but the Oxygen Git Client would need to support it in a better way.

As an alternative, you can also keep "*.xpr" in a .gitignore file.