Re: Is there an agreed protocol for git repo locking?
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- May 10, 2009, 15:17 UTC
- Message-ID
- <m3hbztm1gi.fsf@localhost.localdomain>
- In-Reply-To
- <2cfc40320905100658i4d7ef065qe01e35f2929dd2f6@mail.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:
Show 12 quoted lines
> 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.
Show 10 quoted lines
> 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