No, they’re inherently optional in Git. There’s no way to “check in” a git hook. You have to put in your README

Clone the repo and then please run pre-commit install! Oh and whatever you do don’t git commit --no-verify!

You definitely need to actually check the lints in CI. It’s very easy though, just add pre-commit run -a to your CI script.

So… to store encrypted data that only the user can decrypt you don’t need any fancy zero knowledge algorithms. Just have the user keep the encryption key.

For authentication you could use one of these algorithms. OPAQUE seems to be popular. I’m not an expert but it seems like it has several neat zero-knowledge style properties.

But probably forget about implementing it without a strong background in cryptography.

To check that people ran the pre-commit linters.

Committing itself won’t be possible

That’s not how pre-commit hooks work. They’re entirely optional and opt-in. You need CI to also run them to ensure people don’t forget.

You need them in CI anyway to check people have actually done that, but yeah you definitely don’t need to have CI automatically fix formatting and commit the fixes. That’s crazy.

Normally when I merge a PR I put the long PR message (if there is one) in the merge commit (again if there is one), rather than shitty Merge PR from patch1 that people seem to use.

You can actually change the behaviour on GitHub to be sane: https://blog.mergify.com/how-to-change-the-default-commit-message-on-github/amp/

If I’m not keeping the branch (usually PRs are not big enough to make preserving multiple commits useful) then I squash & merge which gives you the chance to edit the commit message and copy details from the PR message in.

It’s not hard and fast but:

• API is the actual interface for the functions, not the implementation. It’s possible for one API to be implemented by more than one library.
• Library is a bunch of code provided together. It might have more specific meaning depending on the language.
• A package is something you can install. It’s pretty much synonymous to library since most packages contain one library.
• A framework is just a library that dictates a lot about how your app works.

Apart from API they don’t really have strict definitions so they’ll be used interchangeably and differently depending on the language.

Yeah IIRC it deletes them, which is as mad as you would expect. Maybe they’ve fixed that since I used it last which was some years ago.