Because tools is loaded with many scripts other than git hooks. Re-use it has some drawbacks: all the executables in it could be automatically run by git. This will unlikely happen, but I don't like to leave this possibility open. Second, much important to me, the directory is more like a toolbox than an ordered drawer like I would expect a git hook dir. That's why I'd move them in a new one.
Hi,
Interesting idea, but why the need for a new directory? Point core.hooksPath to tools and be done with it?
Thanks,
Jaap
> On 20 May 2019, at 10:36, Dario Lombardo <lomato@xxxxxxxxx> wrote:
>
> Hi list
> In the current development process we're trying to enforce the contribution quality by providing git hooks that help the developer to push better changes.
> Those hooks are provided in the 'tools' directory. According to the developer instructions they must be copied to .git/hooks to be used by git. They're a copy, then they're not updated with git while their "original" is. This can be improved under unix by creating a hard link. Unfortunately there is no way to fully automate this process, but I think there is room for improvement.
>
> We could create a new directory under the tree called like 'git-hooks', and put all the git hooks we want under that. Then we change the developer instructions to use the command 'git config core.hooksPath git-hooks'. This approach would have many advantages:
> 1) it's the only way the wsdg tells to use
> 2) makes the hooks versioned
> 3) works on unix and on windows (although I haven't tried the hooks on windows)
>
> What about this approach? Any drawbacks I can't see?
> Dario.
>
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
