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

Re: Centralized processes in git

From
Jeff King <peff@peff.net>
Date
Aug 21, 2007, 06:13 UTC
Message-ID
<20070821061336.GC7323@coredump.intra.peff.net>
In-Reply-To
<46CA3398.9060803@midwinter.com>
On Tue, Aug 21, 2007 at 08:36:40AM +0800, Steven Grimm wrote:
Show 6 quoted lines
> I wonder if it makes sense to expose a repository locking mechanism for this 
> kind of application. The builtin git commands would test for the lock and 
> block (waiting up to some configurable timeout) until it went away, but 
> wouldn't necessarily ever actually lock things themselves. Or maybe a 
> shared/exclusive lock (aka an rwlock) would be appropriate here; the 
> repository-altering commands would grab a shared lock.

For this use case, I don't think you need to touch the core git commands at all. Since we're just talking about a repo that people are pushing into, why not just grab the lock in a hook before accepting the push?

That serializes the push, but each push can do arbitrary work while holding the lock.

-Peff
Previous: Steven Grimm
Message 5 of 5 in “Centralized processes in git”
  1. Robert BooneAug 20, 2007
  2. Jan HudecAug 20, 2007
  3. Steven GrimmAug 21, 2007
  4. Steven GrimmAug 21, 2007
  5. Jeff KingAug 21, 2007

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.