use pre-push hooks instead
  • KissYagni
    42·
    6 hours ago

    Everytine I’ve seen a pre-commit hook in my job, it was something that should have been in integration pipeline.

    You should not run linter, test or any static analysis tool in a pre-commit (I’m looking at you husky 😡). Why ? Because:

    • It takes time. A commit should be instantaneous.

    • It may change the content of the commit or of the repos without explicite action of the developer.

    • The developper’s branch is the developper’s mess. He don’t have to respect any convention, any quality gate or any workflow on its branch. Quality gates should happen only when integrating into trunk.

    I always commit and push on Friday afternoon before leaving as “WIP”, in case my computer crash during week end. I don’t want to address issues of a WIP job. I just want to backup my work.

    I may commit several time per minute, and do a rebase latter. I don’t want to spend 2min each time waiting for eslint to parse the repos. I don’t want to fix styling because I now I will fix it later and rebase -i before pushing.

    You can use custom pre-commit in your own workflow, but forcing all developer to have the same pre-commit is a bad idea.

    • Michal
      21·
      6 hours ago

      Amen. I also need to be able to commit WIP quickly if i need to urgently checkout master, or push my code because my laptop battery is about to die and i dont want it to have the only copy of my work.

  • falseWhite
    41·
    1 day ago

    Never had any issues.

    The article is just a sad dev ramble.

    I don’t know what’s available for the Rust ecosystem, but for JS/TS someone already did all the hard work and it just works like magic. The library is called Husky.

    • tyler
      1·
      3 hours ago

      husky has to be one of the most annoying and outright hostile libraries I’ve seen. Anytime I pull an open source project to get it working on my machine I have to go through and set up an entire development pipeline just to make a code change even if I never intend on upstreaming that change because husky forces formatting on commits. What an idiotic thing to do. The article covers this clearly. It’s just not something that should be done on commit.

    • Michal
      1·
      6 hours ago

      Can you share what you use git commit hooks for?

      • falseWhite
        3·
        6 hours ago

        I run an eslint fix and prettier formatter. It’s a typescript project.

  • Len@aus.social
    4·
    2 days ago

    @codeinabox I’ve got one to ask if I’m sure when I’m committing to anything called master or main. Helps prevent working in the wrong branch.

    I don’t need to only catch that at the push stage and then have to rebase 🤷🏻‍♂️

    • JackbyDevEnglish
      1·
      6 hours ago

      Actually rebasing before pushing is the best time to do so, so a pre-push hook seems great. You can also have your branch displayed in your shell which would help avoid this.

    • Vulwsztyn
      21·
      1 day ago

      you don’t have to rebase.

      create a new branch from main

      push it

      go to main

      git reset --hard origin/main

      • Len@aus.social
        2·
        1 day ago

        @Vulwsztyn yeah, “there are multiple ways to fix a mistake” is not the point, dude!

        Besides which, yes I do have to rebase if I already have a topic branch for what I’m working on, and didn’t pay attention to which branch I’m on.

        I almost never want to commit to the main branch, only merge from a topic branch. So that means that having confirmation before committing to it is useful.

        • JackbyDevEnglish
          11·
          4 hours ago
          git switch -c blah
git push -u origin blah
git switch main
git reset --hard origin/main