That doesn't automate the maintenance of the hooks, doesn't handle cross branch differences, opens you up to all kinds of security holes because now it'll just do whatever the hook points to which is likely to be in the repo and not in some special higher scrutiny flow...
All the push back to making this system good just ensures its as terrible as the nay-sayers fear.
The alternative is have hooks _forcibly_ run on people's machines, which is fantastic as an attack vector and CVE generator but probably not a good choice in other respects.
No there are a million miles in-between no support/Don't use it and arbitrary code execution.
Signed git plugins and manifest or a canonical way to define hooks in repo that most tools can interface with and allow the user to automatically set up but asks to do so or really so much more.
I don't know why people get fixated on this as if 99.999% of what git pulls down isn't code you expect to run and there are systems in place to protect that.
Adding configuration to the config makes things feel far less exotic. I think these changes certainly improve things, but there's still plenty of room to go further.
I think there should probably be a way to specify canonical git configuration for things like hooks and LFS and all of that. It would be nice if when you clone, git prompts you to trust the remote config or to ask you to accept each new change as they come or fully reject them.
Having to scrape through the readme of every repo and then run arbitrary scripts doesn't seem like the most secure solution. When there's a canonical flow gitlab GitHub and all the tooling can support it and have proper permissions around it.
It's really disappointing how much lack of empathy there is when talking about new git features. Forget empathy. There's outright disdain for discussing alternative workflows.
Why waste a round trip, build time, loss of flow and CI machine queue wait time when you can catch things early?
CI should also run all the checks but CI checks are not a replacement for local hooks. LFS and things like it can't be implemented as remote CI checks.
Why are we acting like a James Bond villain, slowly lowering the changes into the vat of sharks after we've left the room? I want the hooks. Can we talk about making that easy, assuming some people want them?
You're looking for a technological solution for a human problem.
Automatically running arbitrary code from random repositories is a Really Bad Idea, so Git will almost certainly never auto-install pre-commit hooks. Just mention it in the README and run a checker in CI to confirm they are using it, it really isn't that difficult.
People wasting 2 minutes of their own time once during their first contribution because they didn't read the README is not that big of a deal. What's next, you want a script to automatically sign a project's legally-binding CLA on checkout?
You're talking out of both sides of your face here. It's dangerous and also it's super easy and you should do it first thing without having to think because it's so easy. You shouldn't run this code but also the build machine automatically runs it.
We already know we're definitely going to run some of these. We know we want to maintain changes to these hooks. Can we stop pretending like we're not doing that? We get it. Some of these will be untrusted so let's design a system to handle that instead of not designing a system and deciding to be just short of as unsafe as possible.
Automation an uniformity increases safety. Human intervention increases human error. Its just a matter of actually finding a good solution to know what is trusted but instead we get "just set it up manually because its safer."
Ok well what about when I pay you and give you a local machine to work on?
Can I pay you to run hooks on the work machine I own because it saves a lot of work on the share build machines? Can we talk about making that situation less error prone?
Tools growing unexpected code execution is how we keep having problems with secrets and other important things being stolen. If you add this feature to git, generally, then anybody cloning a git repo is going to have to deal with the fact that `git clone` might run arbitrary code. `git clone` is like `cp`. Do you want `cp` to unexpectedly run code? It should never do that.
Why force git to be a build tool?
Just document how to execute the scripts/checks that will be used by ci. Provide a simple script in the repo that folks can intentionally execute.
Git is already a build tool and LFS is a great example of something git should be able to do and is also an example of how bolted on these things feel because of pointless push back in talking about a real solution.
You don't need to bring up bad ideas as if it precludes the existence of good ideas. Let's talk about good ways to solve these problems and improve the tool.
This is Orkin's view, correct? I wonder if its just a matter of controlling more of the market. I can't say I've seen a Western Exterminator guy-with-hammer vs rat adornment in quite some years.
Building Unreal games. Running windows containers.
Windows server is actually kind of awesome for when you need a Windows machine. Linux is great for servers but Windows server is the real Windows pro. Rock solid and none of the crap.
The worst part of Windows server is knowing that Microsoft can make a good operating system and chooses not to.
reply