From: Jakub Narebski Date: Sun, 10 May 2009 15:17:52 GMT Subject: Re: Is there an agreed protocol for git repo locking? Message-ID: 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 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