3 ms·

I have to say I love editorconfig, I feel that once you start running code and managing tools it starts to get too much for me. At that point just spin up a VM

I have to say I love editorconfig, I feel that once you start running code and managing tools it starts to get too much for me. At that point just spin up a VM or container so that the environment is yours. I loathe pre-commit hooks. I often times just want to save work in progress or show someone what I have right now and they slow down my work or worse fail and lose my commit message and cause me to have to figure out how to disable them to continue. If you want to run checks for formatting or similar that is much better done in CI. I can get a reminder without breaking any dev workflows. Of course make fixing formatting a single command, and maybe an optional hook for those that prefer it. But when projects try to auto-install hooks it drives me crazy.

andybak 4y ago
A compromise is to only enforce pre-commit rules when merging to main or some other important branch. Be as sloppy as you want on your own branches and make stuff proper when you're ready.
- ucm_edge 4y ago
  For us we did the main only pre commit thing and also a CI check that any MR marked as ready for review has to pass linting. So you can go wild in your own branches and draft MRs but anything you want someone else to review has to pass.
ghosty141 4y ago
Imo the pre-receive or update hook should be used on the server. For trunk based development I‘d also only check for (e.g) formatting on the main branch.
throw_a_grenade 4y ago
git commit -n|--no-verify I have it in shell history, so it's somethig like "^R ver".
- kevincox 4y ago
  By the time I realize I should have done that I have already been inconvinced. Also remember to copy .git/COMMIT_EDITMSG before you run it so that you don't loose your message.
  - throw_a_grenade 4y ago
    git config --global rebase.autoSquash true git commit --squash|--fixup <commit> git rebase -i origin/master # or whatever your remote/branch is https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---fixupamendrewordltcommitgt https://git-scm.com/docs/git-commit#Documentation/git-commit... Works wonders, but occasionally you screw up. To get out of screwup, use `git reflog` and `git reset --hard`.
rektide 4y ago
Pre commit hooks that fail are trash, just absolutely the worst thing you can do to ruin your team's good practices of committing often & keeping flow high. Any check that take more than 6 seconds can also go jump off a cliff as car as I'm concerned. But I do greatly value fast fixing & feedback. Run format! (and don't print out unchanged things!) Run lint! Maybe run tests, if they're fast. One of the constraints becomes that you are trying to make quick actionable easy to view data, and the output can become too long. We had some outside teams come in & deploy centralized & more updated lint & testing, and alas there's just multiple pages of yellow jest configuration warning as it starts, and it's just so much harder to quickly check status. These hooks need to be quick to read, as well as run. All of the hooks should run if they can, not stop on first problem. Ideally the ci/CD system is a good fast way to see test results. Devs shouldn't even have to think about it, just commit & off board the running. I hear Facebook has very interesting systems where devs aren't even having to make commits for this, which sounds epic. Alas many ci/CD systems are doubly slow, which sucks: slow to start, slow execution speed, and most damming low caching, so they have to do a lot of from-scratch bring up that just takes a really long time versus what local dev has. Systems like nx in JS land are starting to change this more systematically, rather than being a lot of custom ci/CD tweaking. Informational, not prescriptive! Use the tools to accelerate & guide. Right now we're all learning but tool heavy setups are for sure the way.
- hakre 4y ago
  And not to forget: - Pre-Commit hooks that fail to handle partial stages. - Running CI as far away as possible to enlarge feedback time. - Non-incremental builds.
- soulofmischief 4y ago
  One reason I love using yarn to cache my packages in JS-land. npm needs to catch up. Huge gains in deployment times.
- nine_k 4y ago
  Pre-commit hooks that can't fail are not very useful :) That is, they are not preventing you from committing something patently incorrect. But pre-commit hooks should fail fast.

andybak 4y ago

A compromise is to only enforce pre-commit rules when merging to main or some other important branch. Be as sloppy as you want on your own branches and make stuff proper when you're ready.

ucm_edge 4y ago
For us we did the main only pre commit thing and also a CI check that any MR marked as ready for review has to pass linting. So you can go wild in your own branches and draft MRs but anything you want someone else to review has to pass.

ghosty141 4y ago

Imo the pre-receive or update hook should be used on the server. For trunk based development I‘d also only check for (e.g) formatting on the main branch.

throw_a_grenade 4y ago

git commit -n|--no-verify I have it in shell history, so it's somethig like "^R ver".

kevincox 4y ago
By the time I realize I should have done that I have already been inconvinced. Also remember to copy .git/COMMIT_EDITMSG before you run it so that you don't loose your message.
- throw_a_grenade 4y ago
  git config --global rebase.autoSquash true git commit --squash|--fixup <commit> git rebase -i origin/master # or whatever your remote/branch is https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---fixupamendrewordltcommitgt https://git-scm.com/docs/git-commit#Documentation/git-commit... Works wonders, but occasionally you screw up. To get out of screwup, use `git reflog` and `git reset --hard`.

rektide 4y ago

Pre commit hooks that fail are trash, just absolutely the worst thing you can do to ruin your team's good practices of committing often & keeping flow high. Any check that take more than 6 seconds can also go jump off a cliff as car as I'm concerned. But I do greatly value fast fixing & feedback. Run format! (and don't print out unchanged things!) Run lint! Maybe run tests, if they're fast. One of the constraints becomes that you are trying to make quick actionable easy to view data, and the output can become too long. We had some outside teams come in & deploy centralized & more updated lint & testing, and alas there's just multiple pages of yellow jest configuration warning as it starts, and it's just so much harder to quickly check status. These hooks need to be quick to read, as well as run. All of the hooks should run if they can, not stop on first problem. Ideally the ci/CD system is a good fast way to see test results. Devs shouldn't even have to think about it, just commit & off board the running. I hear Facebook has very interesting systems where devs aren't even having to make commits for this, which sounds epic. Alas many ci/CD systems are doubly slow, which sucks: slow to start, slow execution speed, and most damming low caching, so they have to do a lot of from-scratch bring up that just takes a really long time versus what local dev has. Systems like nx in JS land are starting to change this more systematically, rather than being a lot of custom ci/CD tweaking. Informational, not prescriptive! Use the tools to accelerate & guide. Right now we're all learning but tool heavy setups are for sure the way.

hakre 4y ago
And not to forget: - Pre-Commit hooks that fail to handle partial stages. - Running CI as far away as possible to enlarge feedback time. - Non-incremental builds.
soulofmischief 4y ago
One reason I love using yarn to cache my packages in JS-land. npm needs to catch up. Huge gains in deployment times.
nine_k 4y ago
Pre-commit hooks that can't fail are not very useful :) That is, they are not preventing you from committing something patently incorrect. But pre-commit hooks should fail fast.