Githooks: auto-install client-side hooks inside the repos
blog.viktoradam.net
blog.viktoradam.net
This is begging for nefarious things to be installed automatically.
The difference, I would say, is that installers and packages are created by ops people, and Git hooks are written by developers or devops people. Decide for yourself which one is more likely to make a mistake that reformats your system. (It's actually a hard question: developers are usually more precise with syntax in languages [like Bash] where ambiguous syntax can be dangerous; while ops people are better at understanding the system-level implications of the actions they're asking the system to perform.)
(Also, unlike installers or packages, there's no reason for a Git repo's hooks to be privileged to do anything outside of the Git repo's cloned .git dir + worktree. If Git wanted synced scriptability, it would be a perfect case for application-level sandboxing, using system calls like OpenBSD's pledge(2).
This is what you're missing though. No proper programming language performs automatic word splitting on spaces. Only shell scripting languages like like Bash do. There's a reason I didn't conflate "script" with "app" like you guys have. Scripts are both missing critical features for robust coding and also make it really easy to play fast and loose with everything. "Decide for yourself which one is more likely to make a mistake that reformats your system" is exactly what I have done in making the distinction here.
I wasn’t suggesting that we actually allow devs to sync bash scripts around, although I was pointing out that that’s what we’re presently already doing with e.g. Debian package hook scripts.
In the git-crypt's case, "git-crypt init" adds this to your .git/config:
[filter "git-crypt"]
smudge = \"git-crypt\" smudge
clean = \"git-crypt\" clean
required = trueObviously this is an open source side project, so it won't cater to everyone, I'm just skeptical of it being the benefit that it's claimed to be.
He gives his reasonings for it here: https://github.com/git-hooks/git-hooks/wiki/Why-golang
The tl;dr is that it will eventually have features that would be nontrivial to implement with bash, and Go is easier on the development-side than C (coming from a frontend dev experience).
Luckily for you, the project already has binaries built for Mac (Darwin): https://github.com/git-hooks/git-hooks/releases
Is it not a violation of abstraction to turn your version control system into a build/test/CI system?
Local staging, committing, rebasing, cherry-picking, etc. operate on arbitrary line-delimited text. I should be able to do those without triggering non-VCS things.
Do you want to add a convenient auto format step with your IDE, githooks, or inotifywait? Okay. But changing how a standard, fundamental tool works for everyone...
What's wrong with `make format`?
Most checks should be in the CI but git hooks allow a team to add rules without affecting all teams at once. When rules turn out good they can be enforced on everybody via CI. Even a single team might have dozens of machines, so they don't want to roll out git hooks manually.
This is the niche use case I can think of. Still, it exploits git to do things it is not made for. This is asking for trouble elsewhere.
The next he time he'll think twice if he should wait for the failed CI build or just install the hooks locally.
Internally / privately it's generally a lesser risk, but if this is open source please consider removing that feature for better security. That or document it incredibly clearly.
Build scripts are explicitly called by a user, a git hook is a side effect they've elected to setup. In this case the tool is adding side effects to commands without the user explicitly choosing to have them.
I can see someone downloading a repository, running a few git commands to make a couple of changes and not realising the git hooks have been installed and the behaviour of a command has changed. Once you're near that scenario, you're just opening up security holes rather than fixing them. It'd be better to have a script one can run after a git clone explicitly that is documented in the project repository.
"To setup git hooks to speed up development, run ./init-hooks." is easy, clear, makes it difficult to do it without knowing what's happening.
I tend to have some sort of setup or bootstrap script which the docs promote as the way to prepare for development. This tends to install any dev dependencies and also sets up hooks (which is always optional). This works fairly well in most cases, combine that with a lint on the CI and most people don't have any problems. It also saves assuming someone wants git hooks just because they're pulling code, often they just want to build and run it.