On Thursday 20 March 2008, Ping Yin wrote: > On Thu, Mar 20, 2008 at 7:20 PM, Johan Herland <johan@xxxxxxxxxxx> wrote: > > On Thursday 20 March 2008, Junio C Hamano wrote: > > > Victor Bogado da Silva Lins <victor@xxxxxxxxxx> writes: > > > > SO my question is, is there a way to make that hook global to all > > > > projects? If not, would it be a good idea to allow this? > > > > > > Probably a post- git-init hook that lets you do anything to your newly > > > created repository would be the only thing that you need. Then you can > > > copy, untar or even use symlink to muck with .git/hooks/ in whatever way > > > you please. > > > > > > There needs a mechanism for you to specify what that hook is, and it > > > cannot be in individual repositories, so it has to live in ~/.gitconfig > > > somewhere. > > > > Or you could add the hook (either the post-init hook, or for that matter > > the hook you want to make global) to the Git template directory on your > > system (/usr/share/git-core/templates by default). If you don't want to > > make it system-global (only user-global), I guess you could make your > > own Git template directory somewhere (copy the system's template dir, > > and add/enable whatever hooks you like), and set up an alias to > > "git init --template=<your_template_dir>". Then use this alias instead > > of "git init". > > template dir is meaningful for static hooks. However, sometimes we > need dynamic hooks which change over time. Having a real global hook > can help to implement a single logic or policy spreading among > multiple repositories. If you need to centralize the logic, you can just keep the actual hook outside the template directory, and store an (absolute) symlink within the template dir pointing to the hook. All your git repos will now exercise the centralized hook instead of each having a separate copy. > For example, we can enfore a policy to help to update the test or > deploy environent automatically: when repositories are pushed into a > central place, they are checked out into different places or hosts > automatically. > > I think ~/.gitconfig is a good place to give such an entry point. Still, I think this can be solved with the existing tools, without adding more features and config directives. ...Johan -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net -- 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
