We're moving to Git from CVS. We want to version-control our hooks with Git (hence the Subject: of this thread). We've come up with a couple of ways to do it. If anyone has a better suggestion, we'd like to hear it.
We have about 10 product teams. Each product will have a "blessed" repository used for continuous buildbot builds on our various main development and release branches and also for official release builds. We want each of these repositories to have the same set of hooks and we want the hooks to be version-controlled by Git. For instance, we've written a mod of the contributed post-receive- email hook that knows how to update our bug-tracking system when a commit is made that affects a particular case. We'd like this hook to be used by all our product repos, and updates to these hooks to become immediately available in the product repos with a minimum of manual effort. We'll have a Git repository called (say) "our_hooks". This will be used to track the hook files (like post-receive-email). Developers working on these scripts will be able to commit to the blessed "our_hooks" repository's master branch, at which time we'd like the new versions to immediately become available in the 10 or so product repositories. Plan A. What we wound up with is this, which relies (unfortunately) on the fact that (fortunately) all these blessed repos reside on the same server and FS. 1. There will be a our_hooks.git bare repo to which commits intended for immediate distribution will be pushed. 2. There will be a our_hooks repo with working files; these will be the actual files executed by the product repos. 3. The files in the hooks dir of the product repos will be symlinks to the working files in our_hooks. 4. our_hooks.git will contain a post-receive hook that will cd to our_hooks and pull the latest commit from our_hooks.git. We're not fond of symlinks, but the above will work, is simple, and is our favored solution unless something better comes along. Plan B. This was the first one we thought of. It avoids symlinks and the need for colocation of our_hooks with the product repos, but is more complex. 1. We'll still have our_hooks.git, and it will be pushed to in the same manner as in Plan A. 2. Each product.git's hooks dir will contain a Git repository called our_hooks, a clone of our_hooks.git with working files. 3. Each product.git's hooks dir will also contain wrappers that do nothing more than call the working copies in ./our_hooks. 4. Each such wrapper will cd into ./our_hooks and do a pull from our_hooks.git prior to calling the working file in ./our_hooks. This is a lot more work than Plan A (but what's work to a computer, and "premature optimization", etc. etc.). But it's more complex than Plan A, which is why we favor A. Plan C. Your move. ;-) -P. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "GitHub" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/github?hl=en -~----------~----~----~----~------~----~------~--~---
