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@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html