Fixing git hooks and automating commit messages

I believe that git hooks represent a very nice middle ground.

To be clear, they will always fail in the case that you want to push some code, close your laptop, and let a ci/cd pipeline handle validations.

But in the case that you are not closing your laptop, I believe git hooks can be superior, if setup properly.

An important note:
Theo (t3dotgg) has made a few videos explaining why he hates git hooks so much. I have made some meager attempts to assuade him otherwise, but not sure that has gotten anywhere.

The biggest issue with git hooks, is the fact that they typically impede a workflow which did not have git hooks setup.

1. Quality checks usually take more than 30 seconds, typically 60 seconds, at which point, you start losing your flow state (IMO), and may be tempted to multi-task, which is definitely bad if they fail.
2. Even if the checks were fast, you may not even be expecting them to succeed! So any failure can wreck havoc on your workflow! Now your co-workers can't collaborate or help with your not-yet-perfect code, because your push or commit failed :).

======

A critical side quest: TypeScript strictness settings.
Please bare with me, "have faith!" as they like to shout from mountain tops.

Let's say I want to made the tsconfig.json type-checking settings more strict, or add some eslint rules, etc.

I personally like a very strict eslint config. It forces me to think harder about my code, and most importantly, is a vector for learning.

Perhaps developers would be more amenable to stricter type-checking settings, if it weren't such a BLOCKING issue.

Here I tie together this side quest: Let's not make quality checks such a blocker.

======

What if we had a simple command to add // @ts-expect-error - TS ERROR MESSAGE comments throughout our code? In some ways it's just a different output mechanism for tsc. If we could just add code comments with the error messages, yes it's ugly, but anyone in gitlab/github/etc can just view the error messages, and act accordingly. We can agree it's not a big issue, or not.

======

How should git hooks work, then?

They need to integrate with your dev server, wherever you are getting a read-out of typescript or other lint errors. A git/hook process needs to be able to make an IPC/request to a unix socket which the dev server exposes, and the dev server responds with... the current set of errors. I think by default we want a this dev server to add ts/eslint ignore comments into your code, but a parameter could be passed in to disable this behavior, and the errors are then shown in the terminal, and the error messages are put into the commit message.

This way, we let a git commit immediately succeed, but still make it clear what errors we have, whether in the code itself as a comment, or in the commit message.

======

Part 2: Git commit messages.

Something I have somewhat dreamed of, is a tool which can automatically git commit as I am developing. We could imagine that it should not auto-commit if there are type errors, but if there were type errors, and those are all now fixed, it seems like a reasonable time to auto-commit. The problem then, is, what should the commit message BE?

What to put in a 50-character commit message is a topic of great debate. Was it a mistake for git to require them in the first place? Certainly not at the time that git was created.

I believe it would be best to tie a commit message to a commenting system. We can then add commit messages later, when reviewing code, and can directly "reply" to a commit message, should an author want to embed an initial comment (i.e. a traditional-ish commit message). For such a commenting system to be robust when a developer utilizes rebasing, it's best for a developer to "title" the change, with something like ReactDOMRender or LangChangeSupportSpanish, etc. The idea here is to give it a unique-ish title, whereby comment systems can reliably create a single comment thread for the ReactDOMRender commit, even when there are multiple ReactDOMRender commit shas that have been created, due to rebasing.

We could also create these unique ID's automatically. We could first look at newly created (not changed) code, and select the top-most export/variable/function name. If there's a new file name, we could take the files name as the commit message, etc.

If some type error is taking some time to solve, this auto-commiting tool could just commit the state that you are currently at.