git pre-commit hooks library

cf.  https://codimd.nomadic-labs.com/p/YcXmjg1qv#/4

pre-commit is a tool that helps to configure git pre-commit hooks, with an abundance of already configured scripts

pre-commit install and configuration

• Install in system

(apt-get / brew ) install pre-commit

• install in repo 

then in each repo clone (set-up pre-commit for this repo):

pre-commit install

• then (configure) edit .pre-commit-config.yaml

.pre-commit-config.yaml example  (from https://gitlab.com/tezos/tezos/-/blob/master/.pre-commit-config.yaml?ref_type=heads )

# See https://pre-commit.com for more information
# See https://pre-commit.com/hooks.html for more hooks
repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v3.2.0
    hooks:
      - id: trailing-whitespace
      - id: end-of-file-fixer
  - repo: https://github.com/koalaman/shellcheck-precommit
    rev: v0.9.0
    hooks:
      - id: shellcheck
        args: [ "--external-sources" ]
  - repo: https://github.com/cisagov/pre-commit-shfmt
    rev: v0.0.2
    hooks:
      - id: shfmt
        # These settings must mirror the ones set in `scripts/lint.sh`.
        args: [ "-i", "2", "-sr", "-d" ]
  - repo: https://github.com/arenadotio/pre-commit-ocamlformat
    rev: 0439858
    hooks:
      - id: ocamlformat
        args: [ "-i" ]
  - repo: https://github.com/hadolint/hadolint
    rev: v2.9.3
    hooks:
      - id: hadolint-docker
  - repo: https://github.com/python-jsonschema/check-jsonschema
    rev: 0.28.0
    hooks:
      - id: check-gitlab-ci
        args: ["--verbose"]
        files: '(\.gitlab-ci\.yml|\.gitlab/ci/.*\.yml)'

General Notes about pre-commits

• runs only against staged files

 

• to run manually :

pre-commit run --all-files

• to run 1 check specifically  (example : run only  1 plugin (shfmt) )

pre-commit run shfmt







[video] So You Think You Know Git - FOSDEM 2024

 Scott Chacon's FOSDEM 2024 talk on Git Tips and Tricks.

https://www.youtube.com/watch?v=aolI_Rz0ZqY&t=4s

Scott talks about:

00:00 - Introduction

01:06 - About Me (well, Scott Chacon)

02:36 - How Well Do You Know Git?

05:09 - Our Agenda

06:25 - Some Helpful Config Stuff

09:42 - Oldies But Goodies

16:22 - Some New Stuff (You May Not Have Noticed)

23:48 - Some Big Repo Stuff / Monorepo Stuff

33:29 - Some New Github Stuff

35:54 - GitButler

36:50 - End of talk

37:03 - Start of Q&A Session

37:06 - Q: Why does GitHub not do git range diff?

38:28 - Q: Why do submodules suck everywhere?

40:16 - Q: With SSH signing, is it possible to specify more than one key?

40:42 - Q: Why can't --force-with-lease be the default force?

42:33 - Q: If you were back on the Git development team, what direction would you like to see it move in?

44:58 - Q: We all love the Git CLI - but do you ever use any visual tools?

46:41 - That's all folks!-

Conventional Commits specification

 https://www.conventionalcommits.org/en/v1.0.0/

The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with SemVer, by describing the features, fixes, and breaking changes made in commit messages.

for example, to be used with commitlint : 

https://github.com/conventional-changelog/commitlint 

example, on gitlab-ci : https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/merge_requests/85#587d266bb27a4dc3022bbed44dfa19849df3044c

or, at changelog level :

https://github.com/conventional-changelog/conventional-changelog

also cf. commitzen  :

https://github.com/commitizen/cz-cli