{"thread":{"id":"9595","subject":"Centralized processes in git","startedAt":"2007-08-20T18:30:47Z","lastAt":"2007-08-21T06:13:36Z","messageCount":5,"participants":["Robert Boone","Jan Hudec","Steven Grimm","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"51106","messageId":"31FEEAE6-58A6-4A74-9DB7-E6F9D56D1C48@rlb3.com","threadId":"9595","inReplyTo":null,"subject":"Centralized processes in git","fromName":"Robert Boone","fromEmail":"robert@rlb3.com","sentAt":"2007-08-20T18:30:47Z","receivedAt":"2007-08-20T18:30:47Z","isPatch":false,"sender":{"key":"robert@rlb3.com","avatar":null},"body":"Hello,\n     My company is looking at git to replace subversion as our scm.  \nWe have a small team of developers which need to publish to a  \ncentralized repository. One thing we would like is to have an  \nautomated bug fix merge ability. So if I make a bug fix to master we  \nwant that fix to be merged into other branches that we set. If there  \nis a conflict we want that person  to be notified by email or some  \nother way. I would like to know if anyone on the list has a good way  \nto implement this?\n"},{"id":"51112","messageId":"20070820192947.GD8542@efreet.light.src","threadId":"9595","inReplyTo":"31FEEAE6-58A6-4A74-9DB7-E6F9D56D1C48@rlb3.com","subject":"Re: Centralized processes in git","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-08-20T19:29:47Z","receivedAt":"2007-08-20T19:29:47Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Mon, Aug 20, 2007 at 13:30:47 -0500, Robert Boone wrote:\n> Hello,\n>     My company is looking at git to replace subversion as our scm. We have \n> a small team of developers which need to publish to a centralized \n> repository. One thing we would like is to have an automated bug fix merge \n> ability. So if I make a bug fix to master we want that fix to be merged \n> into other branches that we set. If there is a conflict we want that person \n>  to be notified by email or some other way. I would like to know if anyone \n> on the list has a good way to implement this?\n\nNormal way of pushing changes to the central repo is over the ssh protocol,\nwhich invokes git (specifically git-receive-pack) on the server and that in\nturn invokes pre-receive, update, post-receive and post-update hooks. The\nfirst two can prevent the refs to be updated, the later two are for arbitrary\npost-processing.\n\nTo do the automatic merging like you describe, you'd probably put up\na script to run from post-receive and start whatever merges you want to do.\n\nThat script gets a list of updated refs along with new and old version names\non standard input, so you just look for your mainline name (refs/heads/master\nprobably) and if you find, run the appropriate merges. You can of course\nprogram whatever notifications you want in that script.\n\nCommit would undo any changes pushed between checking out a branch and\ncommiting, so you should probably do the merges on a separate repository,\nthat will only be managed by the scripts. You can use the alternates\nmechanism to avoid duplicating the data if that repository will be on the\ncentral server.\n\nI'd recommend the hook script to write the things to just write the\ninstructions what to merge somewhere (into a named pipe, probably -- or\nsocket, which could be extended to separate server) and process that with\na continually running \"daemon\" script, to avoid synchronization issues.\n\nIn git distribution is a pair of scripts in contrib/continuous directory,\nthat use the notifying hook + daemon approach to run tests against each\ncommit, so you can use that for inspiration. It's in perl and being universal\ncomplicates it quite a bit though; you can get a lot shorter with shell and\neverything hardcoded.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec <bulb@ucw.cz>\n"},{"id":"51140","messageId":"46CA3398.9060803@midwinter.com","threadId":"9595","inReplyTo":"20070820192947.GD8542@efreet.light.src","subject":"Re: Centralized processes in git","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-08-21T00:36:40Z","receivedAt":"2007-08-21T00:36:40Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Jan Hudec wrote:\n> Commit would undo any changes pushed between checking out a branch and\n> commiting, so you should probably do the merges on a separate repository,\n> that will only be managed by the scripts. You can use the alternates\n> mechanism to avoid duplicating the data if that repository will be on the\n> central server.\n>   \n\nThat makes this kind of operation ten times more complicated than it \nought to be, IMO.\n\nI wonder if it makes sense to expose a repository locking mechanism for \nthis kind of application. The builtin git commands would test for the \nlock and block (waiting up to some configurable timeout) until it went \naway, but wouldn't necessarily ever actually lock things themselves. Or \nmaybe a shared/exclusive lock (aka an rwlock) would be appropriate here; \nthe repository-altering commands would grab a shared lock.\n\nA lock-and-block primitive eliminates the need for a separate work queue \nmanager for stuff like this: you just make sure you exclusive-lock the \nrepo before you start your postprocessing (and make sure your \npostprocessing handles the case where another commit landed before you \ngot launched, of course). Then you know that nothing else will screw \nwith the repo while you're working, and that your execution will be \nserialized. If you don't need serialized operation like that, you just \nnever grab the exclusive lock and things continue to work as today.\n\nStupid idea? The wrinkle, of course, is that you need to run git \ncommands from within your script, so *those* can't block. I can think of \na few easy ways around that, though, e.g., use an environment variable \nto identify yourself as the holder of the lock, perhaps by putting your \nPID in the lockfile and setting the variable to your PID.\n\n-Steve\n"},{"id":"51141","messageId":"46CA3485.4080207@midwinter.com","threadId":"9595","inReplyTo":"46CA3398.9060803@midwinter.com","subject":"Re: Centralized processes in git","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-08-21T00:40:37Z","receivedAt":"2007-08-21T00:40:37Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Steven Grimm wrote:\n> the repository-altering commands would grab a shared lock.\n\nI guess that's a bit confusing -- what I mean to say is that the \nrepository-altering commands that today do not lock the repository would \ngrab a shared lock such that, in the absence of something else grabbing \nthe exclusive lock, they will continue to effectively not lock the \nrepository. IOW, by grabbing the shared lock they will continue to \nexhibit their current behavior under normal conditions.\n\n-Steve\n"},{"id":"51152","messageId":"20070821061336.GC7323@coredump.intra.peff.net","threadId":"9595","inReplyTo":"46CA3398.9060803@midwinter.com","subject":"Re: Centralized processes in git","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-08-21T06:13:36Z","receivedAt":"2007-08-21T06:13:36Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 21, 2007 at 08:36:40AM +0800, Steven Grimm wrote:\n\n> I wonder if it makes sense to expose a repository locking mechanism for this \n> kind of application. The builtin git commands would test for the lock and \n> block (waiting up to some configurable timeout) until it went away, but \n> wouldn't necessarily ever actually lock things themselves. Or maybe a \n> shared/exclusive lock (aka an rwlock) would be appropriate here; the \n> repository-altering commands would grab a shared lock.\n\nFor this use case, I don't think you need to touch the core git commands\nat all. Since we're just talking about a repo that people are pushing\ninto, why not just grab the lock in a hook before accepting the push?\n\nThat serializes the push, but each push can do arbitrary work while\nholding the lock.\n\n-Peff\n"}]}