Re: Centralized processes in git

[Steven Grimm <koreth@midwinter.com>]

Jan Hudec wrote:
> Commit would undo any changes pushed between checking out a branch and
> commiting, so you should probably do the merges on a separate repository,
> that will only be managed by the scripts. You can use the alternates
> mechanism to avoid duplicating the data if that repository will be on the
> central server.
>   

That makes this kind of operation ten times more complicated than it 
ought to be, IMO.

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.

A lock-and-block primitive eliminates the need for a separate work queue 
manager for stuff like this: you just make sure you exclusive-lock the 
repo before you start your postprocessing (and make sure your 
postprocessing handles the case where another commit landed before you 
got launched, of course). Then you know that nothing else will screw 
with the repo while you're working, and that your execution will be 
serialized. If you don't need serialized operation like that, you just 
never grab the exclusive lock and things continue to work as today.

Stupid idea? The wrinkle, of course, is that you need to run git 
commands from within your script, so *those* can't block. I can think of 
a few easy ways around that, though, e.g., use an environment variable 
to identify yourself as the holder of the lock, perhaps by putting your 
PID in the lockfile and setting the variable to your PID.

-Steve