Re: Is there an agreed protocol for git repo locking?

Disclaimer: please take it with a bit of salt, as I am not
and was not working on the area in question.

Jon Seymour [off-list ref] writes:

As I understand it, the normal use case for git is one in which a
single user performs a number of git operations in sequence on a
private repo.

As such, locking issues don't normally arise - the user is only doing
one thing at once.

I am working on an idea which will imply the need for concurrently
executing processes to modify the repo, in particular refs.  I
specifically don't want to have a repo for each process precisely
because I don't want to incur the costs of repo creation for every
process and, in any case, I need them to share the refs.

Instead of sharing full repo (object database + refs + worktree), you
can have many worktrees for the same repository - see contrib/workdir
(object database + refs are shared), or even use alternates to share
only object database.
 

In my use case, I may need locks that span several otherwise atomic
operations - therefore relying on atomic locks that each git tool
might employ for safety is not sufficient.

Is there an agreed upon locking protocol for the git repo? Is there
tool support for this locking?

The case for adding it is that locking protocols only work if everyone
agrees on the same protocol. The easiest way to do this would be to
provide tools that enforce the desired locking protocol.

The C API for locking is described in Documentation/technical/api-lockfile
From what I understand git tries to avoid locking whenever possible,
using "atomic update" (create/copy + write + atomic rename), but it is
not always possible, see e.g. updating both ref and reflog for it.
Lockfiles had extension *.lock, and will have extension *..lck

-- 
Jakub Narebski
Poland
ShadeHawk on #git