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 - 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
