| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, when the rewrite option is passed, the script does not give
much choice on whether changes should be applied or not, it just does
"git comit -a --amend". However, uncrustify is not always entirely
right about the proposed style changes, or it might suggest changes
in distant/unrelated bits in the changed functions. Thus the developer
needs to be given some option.
Change the approach of the --rewrite option, so that it first does
"git add -p", so that individual changes may be decided upon, and
after all the chunks were gone through, uses "git commit --squash"
so that the changes may be reviewed before manually doing
"git rebase --autosquash" to merge the changes.
|
| |
|
|
| |
Include the sha used for the dry-run instead of using 'origin/main'.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The Python docs recommends using run() for all use-cases it can handle:
https://docs.python.org/3/library/subprocess.html#using-the-subprocess-module
run() waits for the subprocess started to complete, so it's not
necessary to use wait() and communicate() anymore. This simplifies the
script.
Previously running "check-style.py -r" after each commit in an
interactive rebase failed, b/c the script did not wait for the amend
command to complete. Using run() instead of Popen() solves this issue.
|
| |
|
|
|
|
| |
Before this, new files introduced by the range of commits checked were
not considered for formatting b/c uncrustify was always turned off in
the beginning of the files, and never turned back on.
|
| |
|
|
|
|
| |
This way "the line before start" and "the line before end" can be
expressed as "[start|end] - 1", which looks less like using a magic
number.
|
| |
|
|
|
|
|
| |
The docu for `Popen.wait()` says:
> This will deadlock when using stdout=PIPE and/or stderr=PIPE and
> the child process generates enough output to a pipe such that it
> blocks waiting for the OS pipe buffer to accept more data.
|
| |
|
|
|
|
|
| |
If for some reason uncrustify gets angry at our file and indent on/off
marks, it will result in an error code other than 0. Since in those
cases there is no output to diff with, we misinterpret those situations
as "the whole file should be deleted", which is far from it.
|
| |
|
|
| |
So it's more easily visible.
|
| |
|
|
| |
These have no code style to check.
|
| |
|
|
|
|
| |
Checking the end line, we should account that the whole chunk was
already displaced by the code comment that turns uncrustify on, so
we are off by one here.
|
| |
|
|
|
|
|
| |
This avoids setting the uncrustify on/off code comments in the
middle of surrounding code, and maybe breaking their style on the
way. Reducing the context to 0 ensures these are right at the start
and end lines of the function.
|
|
|
This script uses uncrustify to detect code style breaks in/around the
given SHA diff. There's two ways to use it:
- `check-style.py --sha $SHA` prints in stdout the diffs with the
changes suggested to the modifications done between HEAD and $SHA.
The default with no --sha specified is HEAD^
This is meant for integration in CI, in order to show code style
differences, and suggest a set of changes.
- `check-style.py -r` in addition amends the changes in the last
commit. This is ideal to rewrite all commits in a branch one by
one with the suggested changes, e.g.:
`$ git rebase origin/master --exec "./check-style -r"`
One caveat is that there is per-function granularity in the suggested
code changes, so the script might suggest to fix style in unmodified
portions of the changed functions.
|
