git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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
Previous: Jon Seymour
Message 2 of 2 in “Is there an agreed protocol for git repo locking?”
  1. Jon SeymourMay 10, 2009
  2. Jakub NarebskiMay 10, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.