2024-11-14 04:03:42 +08:00
|
|
|
# Git has the notion of hooks, which are custom scripts that are run on
|
|
|
|
|
# specific events. One of these hooks is the pre-commit hook (located at
|
|
|
|
|
# .git/hooks/pre-commit), which is run when committing, before specifying a
|
|
|
|
|
# message.
|
|
|
|
|
#
|
|
|
|
|
# To ease management of the pre-commit hook, the pre-commit framework
|
|
|
|
|
# ( https://pre-commit.com ) was developed. This is the configuration file
|
|
|
|
|
# for that framework. It contains a list of hooks, with information on where
|
|
|
|
|
# to find them and on which files to run them.
|
|
|
|
|
#
|
|
|
|
|
# See here ( https://pre-commit.com/#install ) on how to install the
|
|
|
|
|
# pre-commit framework.
|
|
|
|
|
#
|
|
|
|
|
# To run all the hooks specified in this file manually, you can do:
|
|
|
|
|
# $ pre-commit run
|
|
|
|
|
#
|
|
|
|
|
# To run some hooks and skip others, you can use environment variable SKIP:
|
|
|
|
|
# $ SKIP=flake8,isort pre-commit run
|
|
|
|
|
#
|
|
|
|
|
# To install the pre-commit framework in the repository in order to run the
|
|
|
|
|
# hooks on every commit, do:
|
|
|
|
|
# $ pre-commit install
|
|
|
|
|
#
|
|
|
|
|
# After installing the pre-commit framework, you can skip running all
|
|
|
|
|
# pre-commit hooks using --no-verify, or some using SKIP.
|
|
|
|
|
# $ git commit --no-verify ...
|
|
|
|
|
# $ SKIP=flake8,isort git commit ...
|
|
|
|
|
#
|
|
|
|
|
# In case some of these hooks don't work for you, you can make the SKIP
|
|
|
|
|
# setting permanent by:
|
|
|
|
|
# - setting SKIP in your environment
|
|
|
|
|
# (this will affect all repositories where it is set)
|
|
|
|
|
# - setting SKIP in .git/hooks/pre-commit by adding "export SKIP=..."
|
|
|
|
|
# (this will affect only this repository, but it may have to be re-added
|
|
|
|
|
# if .git/hooks/pre-commit is regenerated)
|
|
|
|
|
#
|
Add .pre-commit-config.yaml
Add a pre-commit [1] config file, with a single hook to run black on the
gdb directory whenever a Python file is modified. We can always add
more hooks if we find some that are useful.
Using pre-commit to run hooks is opt-in, as in it's not mandatory at all
for development, but it can be useful to run some checks that are easy
to forget (like running black). The hooks run locally on the
developer's machine when doing `git commit` (although they can also be
configured to run at other stages of the git workflow).
Follow these instructions to install the hooks in your local development
git repository:
- Install pre-commit the way you prefer. It can be using your OS
package manager if it has a recent enough version, or using `pip
install pre-commit`.
- Go to the binutils-gdb repository and run `pre-commit install`.
This installs a git hook at `.git/hooks/pre-commit`.
Now, whenever you modify and try to commit a Python file, pre-commit
will run black on it. For instance, if I try to insert something
misformatted, I get this when doing `git commit`:
$ git commit
black....................................................................Failed
- hook id: black
- files were modified by this hook
reformatted gdb/python/lib/gdb/dap/breakpoint.py
All done! ✨ 🍰 ✨
1 file reformatted.
At this point, black has already reformatted the files in place, so the
changes that fix the formatting are ready to add and commit. black is
only ran on files modified in the commit.
The hook defines a black version, which is downloaded at `pre-commit
install` time. pre-commit manages its own env at
`$HOME/.cache/pre-commit/<some-hash>`, so it won't use the version of
black you have installed already. This may help ensure that
contributors use the right black version.
The procedure when there is a new version of black (or a new version of
any hook we might be using in the future) is:
- Modify .pre-commit-config.yaml to change the version number, push to
the upstream repo.
- Have contributors run `pre-commit autoupdate` to make their local
pre-commit installation update the hooks.
It is possible to have pre-commit skip some hooks if needed [2].
I will add these instructions to the wiki if this patch gets merged, so
they are easy to find. We could perhaps think of having a
gdb/CONTRIBUTING document of some sort checked in the repo with that
kind of information.
I have not used pre-commit in a real project before, but have heard good
things from it. If we want to give it a try before pushing it to the
repo, some volunteers can copy the .pre-commit-config.yaml file locally
and try it for some time. However, pushing the file upstream is not
going to impact anybody who doesn't care about it, so I'd say it's
relatively low-risk to push it right now.
[1] https://pre-commit.com
[2] https://pre-commit.com/#temporarily-disabling-hooks
Change-Id: Id00cda882f5140914a670c87e574fa7f2f972099
Acked-By: Tom Tromey <tromey@adacore.com>
Acked-By: Guinevere Larsen <blarsen@redhat.com>
Acked-By: Andrew Burgess <aburgess@redhat.com>
2024-03-11 23:09:43 +08:00
|
|
|
# See https://pre-commit.com for more information
|
|
|
|
|
# See https://pre-commit.com/hooks.html for more hooks
|
2024-11-14 04:03:42 +08:00
|
|
|
|
Add .pre-commit-config.yaml
Add a pre-commit [1] config file, with a single hook to run black on the
gdb directory whenever a Python file is modified. We can always add
more hooks if we find some that are useful.
Using pre-commit to run hooks is opt-in, as in it's not mandatory at all
for development, but it can be useful to run some checks that are easy
to forget (like running black). The hooks run locally on the
developer's machine when doing `git commit` (although they can also be
configured to run at other stages of the git workflow).
Follow these instructions to install the hooks in your local development
git repository:
- Install pre-commit the way you prefer. It can be using your OS
package manager if it has a recent enough version, or using `pip
install pre-commit`.
- Go to the binutils-gdb repository and run `pre-commit install`.
This installs a git hook at `.git/hooks/pre-commit`.
Now, whenever you modify and try to commit a Python file, pre-commit
will run black on it. For instance, if I try to insert something
misformatted, I get this when doing `git commit`:
$ git commit
black....................................................................Failed
- hook id: black
- files were modified by this hook
reformatted gdb/python/lib/gdb/dap/breakpoint.py
All done! ✨ 🍰 ✨
1 file reformatted.
At this point, black has already reformatted the files in place, so the
changes that fix the formatting are ready to add and commit. black is
only ran on files modified in the commit.
The hook defines a black version, which is downloaded at `pre-commit
install` time. pre-commit manages its own env at
`$HOME/.cache/pre-commit/<some-hash>`, so it won't use the version of
black you have installed already. This may help ensure that
contributors use the right black version.
The procedure when there is a new version of black (or a new version of
any hook we might be using in the future) is:
- Modify .pre-commit-config.yaml to change the version number, push to
the upstream repo.
- Have contributors run `pre-commit autoupdate` to make their local
pre-commit installation update the hooks.
It is possible to have pre-commit skip some hooks if needed [2].
I will add these instructions to the wiki if this patch gets merged, so
they are easy to find. We could perhaps think of having a
gdb/CONTRIBUTING document of some sort checked in the repo with that
kind of information.
I have not used pre-commit in a real project before, but have heard good
things from it. If we want to give it a try before pushing it to the
repo, some volunteers can copy the .pre-commit-config.yaml file locally
and try it for some time. However, pushing the file upstream is not
going to impact anybody who doesn't care about it, so I'd say it's
relatively low-risk to push it right now.
[1] https://pre-commit.com
[2] https://pre-commit.com/#temporarily-disabling-hooks
Change-Id: Id00cda882f5140914a670c87e574fa7f2f972099
Acked-By: Tom Tromey <tromey@adacore.com>
Acked-By: Guinevere Larsen <blarsen@redhat.com>
Acked-By: Andrew Burgess <aburgess@redhat.com>
2024-03-11 23:09:43 +08:00
|
|
|
repos:
|
|
|
|
|
- repo: https://github.com/psf/black-pre-commit-mirror
|
2024-08-13 01:03:09 +08:00
|
|
|
rev: 24.8.0
|
Add .pre-commit-config.yaml
Add a pre-commit [1] config file, with a single hook to run black on the
gdb directory whenever a Python file is modified. We can always add
more hooks if we find some that are useful.
Using pre-commit to run hooks is opt-in, as in it's not mandatory at all
for development, but it can be useful to run some checks that are easy
to forget (like running black). The hooks run locally on the
developer's machine when doing `git commit` (although they can also be
configured to run at other stages of the git workflow).
Follow these instructions to install the hooks in your local development
git repository:
- Install pre-commit the way you prefer. It can be using your OS
package manager if it has a recent enough version, or using `pip
install pre-commit`.
- Go to the binutils-gdb repository and run `pre-commit install`.
This installs a git hook at `.git/hooks/pre-commit`.
Now, whenever you modify and try to commit a Python file, pre-commit
will run black on it. For instance, if I try to insert something
misformatted, I get this when doing `git commit`:
$ git commit
black....................................................................Failed
- hook id: black
- files were modified by this hook
reformatted gdb/python/lib/gdb/dap/breakpoint.py
All done! ✨ 🍰 ✨
1 file reformatted.
At this point, black has already reformatted the files in place, so the
changes that fix the formatting are ready to add and commit. black is
only ran on files modified in the commit.
The hook defines a black version, which is downloaded at `pre-commit
install` time. pre-commit manages its own env at
`$HOME/.cache/pre-commit/<some-hash>`, so it won't use the version of
black you have installed already. This may help ensure that
contributors use the right black version.
The procedure when there is a new version of black (or a new version of
any hook we might be using in the future) is:
- Modify .pre-commit-config.yaml to change the version number, push to
the upstream repo.
- Have contributors run `pre-commit autoupdate` to make their local
pre-commit installation update the hooks.
It is possible to have pre-commit skip some hooks if needed [2].
I will add these instructions to the wiki if this patch gets merged, so
they are easy to find. We could perhaps think of having a
gdb/CONTRIBUTING document of some sort checked in the repo with that
kind of information.
I have not used pre-commit in a real project before, but have heard good
things from it. If we want to give it a try before pushing it to the
repo, some volunteers can copy the .pre-commit-config.yaml file locally
and try it for some time. However, pushing the file upstream is not
going to impact anybody who doesn't care about it, so I'd say it's
relatively low-risk to push it right now.
[1] https://pre-commit.com
[2] https://pre-commit.com/#temporarily-disabling-hooks
Change-Id: Id00cda882f5140914a670c87e574fa7f2f972099
Acked-By: Tom Tromey <tromey@adacore.com>
Acked-By: Guinevere Larsen <blarsen@redhat.com>
Acked-By: Andrew Burgess <aburgess@redhat.com>
2024-03-11 23:09:43 +08:00
|
|
|
hooks:
|
|
|
|
|
- id: black
|
2024-04-03 02:04:21 +08:00
|
|
|
types_or: [file]
|
|
|
|
|
files: 'gdb/.*\.py(\.in)?$'
|
|
|
|
|
- repo: https://github.com/pycqa/flake8
|
2024-08-13 01:03:09 +08:00
|
|
|
rev: 7.1.1
|
2024-04-03 02:04:21 +08:00
|
|
|
hooks:
|
|
|
|
|
- id: flake8
|
|
|
|
|
types_or: [file]
|
|
|
|
|
# Note this one is only run on gdb/python, not (for now) the
|
|
|
|
|
# test suite.
|
|
|
|
|
files: 'gdb/python/.*\.py(\.in)?$'
|
|
|
|
|
args: [--config, gdb/setup.cfg]
|
|
|
|
|
- repo: https://github.com/pycqa/isort
|
|
|
|
|
rev: 5.13.2
|
|
|
|
|
hooks:
|
|
|
|
|
- id: isort
|
|
|
|
|
types_or: [file]
|
|
|
|
|
files: 'gdb/.*\.py(\.in)?$'
|
