Aaron Schrab <aaron@xxxxxxxxxx> writes: > There have been at least a couple of submissions to add support for a > pre-push hook, which were rejected at least partially because they didn't > provide enough information to a hook script for it to determine what was > to be pushed any better than a separate wrapper around the 'git push' > command would be able to do. In this series I attempt to address that > problem. > > The first two patches in this series do a little bit of refactoring in > order to make it easier to call hooks with a variable number of arguments. > > The third patch actually adds support for calling a pre-push hook. If it > exists, it will be called with the name and URL of the destination remote > (if a named remote isn't being used, the URL will be supplied for both) > followed by another argument for each ref being pushed; these arguments > take the form: > > <local ref>:<local sha1>:<remote ref>:<remote sha1> One lesson we learned long time ago while doing hooks is to avoid unbound number of command line arguments and instead feed them from the standard input. I think this should do the same. > This should provide enough information for a script to easily determine > the set of commits that is being pushed, and thus make a decision if that > should be allowed. How does the hook communicate its decision to the calling Git? Will it be "all-or-none", or "I'll allow these but not those"? -- 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