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

[Jakub Narebski <jnareb@gmail.com>]

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

Jon Seymour <jon.seymour@gmail.com> 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