The capture variables, $1, etc, are not valid unless the match
succeeded, and they're not cleared, either.
$ git checkout -B C origin/master && \
echo XXXXX > f.txt && \
git add f.txt && \
git commit -m 'this commit does something()'
Branch 'C' set up to track remote branch 'master' from 'origin'.
Reset branch 'C'
Your branch is up to date with 'origin/master'.
sh: -c: line 0: syntax error near unexpected token `('
sh: -c: line 0: `git log --abbrev=12 --pretty=format:"%h ('%s')" -1 does something() 2>/dev/null'
>>> VALIDATE "a169a98e14 this commit does something()"
(commit message):4: Commit 'does something()' does not seem to exist:
> Subject: [PATCH] this commit does something()
(commit message):4: Refer to the commit id properly: :
> Subject: [PATCH] this commit does something()
The patch does not validate.
This allows us to add a file "TODO.txt" in the top level directory.
This file is not intended to be merged to master, but keep track of
stuff that is still to do before merging a branch.
Let checkpatch.pl warn about the presence of such a file.
We have a few source code tags like "TODO" and "FIXME".
"XXX" is not intended to be merged, it is for marking
places in code while still working on it.
This takes current HEAD branch, and finds all the commits what
are not on master or one of the nm-1-* branches, and runs
checkpatch.pl on each.
The use is to run checkpatch.pl on all patches of a feature
branch.
Don't use the integer type before signed/unsigned, but the
other way around. That is,
unsigned long var;
instead of
long unsigned var;
Also, just use "unsigned" instead of "unsigned int".
Tabs are not only wrong after a space, they are always
wrong if they don't appear at the beginning of a line.
That would happen usually, when trying to align multiple
lines like
enum {
VALUE1 = 1;
OTHER_VALUE = 2;
};
When doing that, the alignment will only be correct, if the
reader later uses the same tab-width. Note that in NetworkManager
we recommend the tab-width to be 4 characters, but with our "smart
tab" indentation style, it wouldn't actually matter and the reader
is free to choose any other tab-width -- as long as we don't use
non-leading tabs.
Don't allow non-leading tabs.
We should not use glib typedefs for basic C types char, short, int,
long, float or double. We commonly do not use them, so enforce
consistency.
That is not true for typedefs like guint, which we commonly use
because it's shorter typing than "unsigned int" (or "int unsigned"
or "unsigned"). Whether or not to use guint is left undecided at this
point.
A naive code compliance checker. Invoke directly:
contrib/scripts/checkpatch.pl 0001-switch-comments-to-klingon.patch
contrib/scripts/checkpatch.pl hello.[ch] world.c
Use from a commit hook:
echo 'git format-patch --stdout -1 |contrib/scripts/checkpatch.pl || :>' \
>.git/hooks/post-commit
Or view the documentation with "perldoc contrib/scripts/checkpatch.pl"
