{"thread":{"id":"19271","subject":"Is there an agreed protocol for git repo locking?","startedAt":"2009-05-10T13:58:02Z","lastAt":"2009-05-10T15:17:52Z","messageCount":2,"participants":["Jon Seymour","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"113460","messageId":"2cfc40320905100658i4d7ef065qe01e35f2929dd2f6@mail.gmail.com","threadId":"19271","inReplyTo":null,"subject":"Is there an agreed protocol for git repo locking?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2009-05-10T13:58:02Z","receivedAt":"2009-05-10T13:58:02Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"As I understand it, the normal use case for git is one in which a\nsingle user performs a number of git operations in sequence on a\nprivate repo.\n\nAs such, locking issues don't normally arise - the user is only doing\none thing at once.\n\nI am working on an idea which will imply the need for concurrently\nexecuting processes to modify the repo, in particular refs.  I\nspecifically don't want to have a repo for each process precisely\nbecause I don't want to incur the costs of repo creation for every\nprocess and, in any case, I need them to share the refs.\n\nIn my use case, I may need locks that span several otherwise atomic\noperations - therefore relying on atomic locks that each git tool\nmight employ for safety is not sufficient.\n\nIs there an agreed upon locking protocol for the git repo? Is there\ntool support for this locking?\n\nThe case for adding it is that locking protocols only work if everyone\nagrees on the same protocol. The easiest way to do this would be to\nprovide tools that enforce the desired locking protocol.\n\njon.\n"},{"id":"113462","messageId":"m3hbztm1gi.fsf@localhost.localdomain","threadId":"19271","inReplyTo":"2cfc40320905100658i4d7ef065qe01e35f2929dd2f6@mail.gmail.com","subject":"Re: Is there an agreed protocol for git repo locking?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-05-10T15:17:52Z","receivedAt":"2009-05-10T15:17:52Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Disclaimer: please take it with a bit of salt, as I am not\nand was not working on the area in question.\n\nJon Seymour <jon.seymour@gmail.com> writes:\n\n> As I understand it, the normal use case for git is one in which a\n> single user performs a number of git operations in sequence on a\n> private repo.\n> \n> As such, locking issues don't normally arise - the user is only doing\n> one thing at once.\n> \n> I am working on an idea which will imply the need for concurrently\n> executing processes to modify the repo, in particular refs.  I\n> specifically don't want to have a repo for each process precisely\n> because I don't want to incur the costs of repo creation for every\n> process and, in any case, I need them to share the refs.\n\nInstead of sharing full repo (object database + refs + worktree), you\ncan have many worktrees for the same repository - see contrib/workdir\n(object database + refs are shared), or even use alternates to share\nonly object database.\n \n> In my use case, I may need locks that span several otherwise atomic\n> operations - therefore relying on atomic locks that each git tool\n> might employ for safety is not sufficient.\n> \n> Is there an agreed upon locking protocol for the git repo? Is there\n> tool support for this locking?\n> \n> The case for adding it is that locking protocols only work if everyone\n> agrees on the same protocol. The easiest way to do this would be to\n> provide tools that enforce the desired locking protocol.\n\nThe C API for locking is described in Documentation/technical/api-lockfile\nFrom what I understand git tries to avoid locking whenever possible,\nusing \"atomic update\" (create/copy + write + atomic rename), but it is\nnot always possible, see e.g. updating both ref and reflog for it.\nLockfiles had extension *.lock, and will have extension *..lck\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"}]}