Thomas Rast schrieb: > Heiko Voigt wrote: >> This leads me to a completely different solution to the same problem. >> How about teaching git to inherit its hooks from the parental project >> (e.g. the one it was cloned from)? That way we are not limited to >> one default behaviour but many that would match the one from the >> upstream project. > [...] >> What do you think about that? > > Three words: huge security hole. > > Especially on cloning, where the checkout immediately afterwards > would already run the post-checkout hook, without any chance for the > user to inspect its contents. Good point here as well. > The usual advice is to track the hooks in the repository, e.g., under > hooks/, and instruct the users to copy them to .git/hooks/ if they > want them. I read about that possibility but it does not completely satisfy me, because a new user to a project can not just git clone url/to/somewhere and start working. How about combining my first approach with the second idea? Teach git different default sets of hooks. So something like: git init --workflow="topic-branches" would initialize and install a certain set of hooks. Implement the possibility to propagate this setting to the server, by using a config variable or similar. This way only secure hooks will automatically be inherited and the user has the benefit of a more specific workflow support. cheers Heiko -- 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
