Re: [PATCH v1] travis-ci: override CFLAGS properly, add -Wdeclaration-after-statement

[Junio C Hamano]

Lars Schneider  writes:

> Jeff Merkey made me aware of http://kernelnewbies.org/FirstKernelPatch [2]
> where I found checkpatch.pl [3]. Would it make sense to check all commits
> that are not in next/master/maint with this script on Travis-CI?

That does not help very much.  These changes are already shown to
people and dirtied their eyes, and most likely I've already have
wasted time tweaking the glitches out locally.  The damage has
already been done.

It would make a lot of sense if the checkpatch is called inside
Roberto Tyley's "pull-request-to-patch-submission" thing, though.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1] travis-ci: override CFLAGS properly, add -Wdeclaration-after-statement

[Stefan Beller]

On Tue, Feb 9, 2016 at 10:42 AM, Junio C Hamano  wrote:
> Lars Schneider  writes:
>
>> Jeff Merkey made me aware of http://kernelnewbies.org/FirstKernelPatch [2]
>> where I found checkpatch.pl [3]. Would it make sense to check all commits
>> that are not in next/master/maint with this script on Travis-CI?
>
> That does not help very much.  These changes are already shown to
> people and dirtied their eyes, and most likely I've already have
> wasted time tweaking the glitches out locally.  The damage has
> already been done.
>
> It would make a lot of sense if the checkpatch is called inside
> Roberto Tyley's "pull-request-to-patch-submission" thing, though.

Last time I reported a bug/feature request, Roberto was glad to be
cc'd as he doesn't read the mailing list in full. So I cc'd him here.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1] travis-ci: override CFLAGS properly, add -Wdeclaration-after-statement

[Lars Schneider]

On 08 Feb 2016, at 13:25, Jeff King  wrote:

> On Mon, Feb 08, 2016 at 09:59:18AM +0100, larsxschnei...@gmail.com wrote:
> 
>> From: Lars Schneider 
>> 
>> The global Travis-CI environment variable CFLAGS did not override the
>> CFLAGS variable in the makefile. Pass CFLAGS as make variable to
>> override it properly.
> 
> Makes sense.
> 
>> In addition to that, add '-Wdeclaration-after-statement' to make a
>> Travis-CI build fail (because of '-Werror') if the code does not adhere
>> to the Git coding style.
> 
> I think this is a good step, but is probably the tip of the iceberg. I
> typically use:
> 
>  -Wall -Werror -Wdeclaration-after-statement
>  -Wpointer-arith -Wstrict-prototypes -Wvla
>  -Wold-style-declaration -Wold-style-definition
> 
> Junio does his integration testing with a similar set, which I think you
> can find in one of the scripts in his "todo" branch.

I collected the warnings from Junio's Make [1] script and merged them with 
yours. This is the resulting warning list for clang and gcc:

-Wdeclaration-after-statement -Wno-format-zero-length -Wold-style-definition 
-Woverflow -Wpointer-arith -Wstrict-prototypes -Wunused -Wvla

Gcc processes one extra warning that clang doesn't like:
-Wold-style-declaration

The build runs clean with all these checks enabled.

[1] https://github.com/git/git/blob/todo/Make


>> I made this patch because Peff pointed out to me that "git style doesn't
>> allow declaration-after-statement" [1]. I wonder if it would make sense
>> to add this check even in the makefile [2]?
> 
> I think we keep the default CFLAGS to a pretty tame set, so that we
> build out of the box on a large number of compilers. I know I have run
> into problems with -Wold-style-* on clang (though perhaps that is no
> longer the case, as I haven't tried recently), let alone truly antique
> compilers.
> 
> I have, however, wondered if it would make sense to codify this
> knowledge in the Makefile with an optional knob. E.g., let DEVELOPER=1
> roughly mean "you are a git dev, you have a reasonably modern compiler,
> and want to be as careful as possible before sending your patches".

That make sense. However, in "development mode" I don't like Werror.
How about two knobs? One called DEVELOPER which enables all the warnings
above and one called CONTINUOUS_INTEGRATION that enables Werror
in addition?


>> I am no make expert, but I
>> also wonder why we don't use the override directive [3] for the CFLAGS?
>> AFAIK this would allow a make invocation like this:
>> 
>> make target CFLAGS+=-Wdeclaration-after-statement
> 
> I think it is rather the opposite. If we used:
> 
>  override CFLAGS+= ...
> 
> in the Makefile, then if a user did:
> 
>  make CFLAGS=...
> 
> we would add to their CFLAGS (whereas without the override, our
> appending is ignored). Our Makefile solves that in a different way,
> though. We pass $(ALL_CFLAGS) to the compiler, and that in turn is made
> up of $(CFLAGS) and $(BASIC_CFLAGS). We assume the user tweaks the
> former, and we set the latter based on Makefile knobs (e.g., NO_CURL,
> etc).
I see. Thanks for the explanation.

Regarding CI checks:

Jeff Merkey made me aware of http://kernelnewbies.org/FirstKernelPatch [2]
where I found checkpatch.pl [3]. Would it make sense to check all commits
that are not in next/master/maint with this script on Travis-CI?

Stefan Beller recently mentioned "Adhere to the common coding style of 
Git" [4] where he removed explicit NULL checks. This kind of stuff could be
checked automatically with checkpatch.pl as far as I can see.

[2] http://www.spinics.net/lists/git/msg267445.html
[3] https://github.com/torvalds/linux/blob/master/scripts/checkpatch.pl
[4] http://permalink.gmane.org/gmane.comp.version-control.git/280842

Thanks,
Lars
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1] travis-ci: override CFLAGS properly, add -Wdeclaration-after-statement

[Ramsay Jones]

On 09/02/16 17:47, Junio C Hamano wrote:
> Jeff King  writes:
> 
>> Perhaps. I'm not sure that people actually use checkpatch.pl for git.
>>
>> Out of curiosity, I tried:
>>
>>   mkdir out
>>   git format-patch -o out v2.6.0..v2.7.0
>>   checkpatch.pl out/*
>>
>> It's rather noisy, and after skimming, I'd say (subjectively) that only
>> a small fraction are actual style issues we try to enforce. So it would
>> certainly need a fair bit of tweaking for regular use, I think.
>>
>> -Peff
> 
> FWIW, I use the attached (it assumes a recent kernel checkout at
> certain location and checkpatch-original.pl being a symlink to it)
> occasionally.  I found patches from some people are consistently
> clean and suspect they may be running checkpatch themselves.
> 
> -- >8 -- Meta/CP (not on 'todo' branch) -- >8 --
> #!/bin/sh
> 
> # Run checkpatch on the series
> Meta=$(git rev-parse --show-cdup)Meta
> cp0="$Meta/checkpatch-original.pl"
> cp1="$Meta/checkpatch.pl"
> tmp="/var/tmp/CP.$$"
> 
> mkdir "$tmp" || exit
> trap 'rm -fr "$tmp"' 0
> 
> if! test -f "$cp1" ||
>   test "$cp0" -nt "$cp1"
> then
>   cat "$cp0" >"$cp1" &&
>   (cd "$Meta" &&
> patch -p1 <<\EOF
> --- a/checkpatch.pl
> +++ b/checkpatch.pl
> @@ -282,6 +282,8 @@
>   Reviewed-by:|
>   Reported-by:|
>   Suggested-by:|
> + Helped-by:|
> + Mentored-by:|
>   To:|
>   Cc:
>  )};
> @@ -2338,7 +2340,7 @@
>  
>  # check for new typedefs, only function parameters and sparse annotations
>  # make sense.
> - if ($line =~ /\btypedef\s/ &&
> + if (0 && $line =~ /\btypedef\s/ &&
>   $line !~ /\btypedef\s+$Type\s*\(\s*\*?$Ident\s*\)\s*\(/ &&
>   $line !~ /\btypedef\s+$Type\s+$Ident\s*\(/ &&
>   $line !~ /\b$typeTypedefs\b/ &&
> @@ -2607,8 +2609,7 @@
>  
>   # No spaces for:
>   #   ->
> - #   :   when part of a bitfield
> - } elsif ($op eq '->' || $opv eq ':B') {
> + } elsif ($op eq '->') {
>   if ($ctx =~ /Wx.|.xW/) {
>   ERROR("SPACING",
> "spaces prohibited around 
> that '$op' $at\n" . $hereptr);
> 
> EOF
> )
> fi || exit
> 
> cat "$@" | git mailsplit -b -o"$tmp" >/dev/null
> 
> for mail in "$tmp"/*
> do
>   (
>   git mailinfo -k "$mail.msg" "$mail.patch" >"$mail.info" <"$mail"
>   echo
>   cat "$mail.msg"
>   printf "%s\n" -- "---"
>   cat "$mail.patch"
>   ) >"$mail.mbox"
>   perl "$Meta/checkpatch.pl" $ignore --no-tree --max-line-length=120 
> "$mail.mbox" || {
>   grep "Subject: " "$mail.info"
>   printf "%s\n" -- 
> ""
>   }
> done

I have used checkpatch on some small (new) projects from a 'style'
target in the makefile. (Checking both *.c and *.h)

If we try something similar on git, (while on current pu branch):

$ git diff
diff --git a/Makefile b/Makefile
index fd80e94..3d6f1d8 100644
--- a/Makefile
+++ b/Makefile
@@ -2247,6 +2247,14 @@ test-%$X: test-%.o GIT-LDFLAGS $(GITLIBS)
 check-sha1:: test-sha1$X
./test-sha1.sh
 
+ST_OBJ = $(patsubst %.o,%.st,$(C_OBJ))
+
+$(ST_OBJ): %.st: %.c GIT-CFLAGS FORCE
+   checkpatch.pl --no-tree --show-types --ignore=NEW_TYPEDEFS -f $<
+
+.PHONY: style $(ST_OBJ)
+style: $(ST_OBJ)
+
 SP_OBJ = $(patsubst %.o,%.sp,$(C_OBJ))
 
 $(SP_OBJ): %.sp: %.c GIT-CFLAGS FORCE
$ make -k style >zzz 2>&1
$ grep "^WARNING:" zzz | wc -l
7320
$ grep "^ERROR:" zzz | wc -l
1155
$ 

To try and summarize a little:

$ grep '^WARNING:' zzz | sort | uniq -c
  1 WARNING:AVOID_EXTERNS: externs should be avoided in .c files
 18 WARNING:BRACES: braces {} are not necessary for any arm of this 
statement
 82 WARNING:BRACES: braces {} are not necessary for single statement blocks
  5 WARNING:CVS_KEYWORD: CVS style keyword markers, these will _not_ be 
updated
 23 WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
  2 WARNING:DEFAULT_NO_BREAK: switch default: should use break
 33 WARNING:INDENTED_LABEL: labels should not be indented
539 WARNING:LEADING_SPACE: please, no spaces at the start of a line
  1 WARNING:LINE_CONTINUATIONS: Avoid unnecessary line continuations
   3422 WARNING:LONG_LINE: line over 80 characters
 14 WARNING:MISSING_BREAK: Possible switch case/default not preceeded by 
break or fallthrough comment
  1 WARNING:ONE_SEMICOLON: Statements terminations use 1 semicolon
 19 WARNING:PREFER_PRINTF: __printf(string-index, first-to-check) is 
preferred over __attribute__((format(printf, string-index, first-to-check)))
  7 WARNING:QUOTED_WHITESPACE_BEFORE_NEWLINE: unnecessary whitespace before 
a quoted newline
 17 

Re: [PATCH v1] travis-ci: override CFLAGS properly, add -Wdeclaration-after-statement

[Junio C Hamano]

Roberto Tyley  writes:

> I've not personally run checkpatch.pl (as Peff mentioned, it's not
> actually a documented part of the Git project's recommend contribution
> workflow) - I'm still trying to understand whether it will restrict
> it's errors to just the things that are introduced in a patch,

Yes, it works as a filter to pass a submitted patch through to catch
issues on the new lines.  You can obviously diff the current state
with an empty tree and feed the result to it, which would give you
all the existing issues ;-) but that is not very useful.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1] travis-ci: override CFLAGS properly, add -Wdeclaration-after-statement

[Roberto Tyley]

On 9 February 2016 at 18:42, Junio C Hamano  wrote:
> Lars Schneider  writes:
>> Jeff Merkey made me aware of http://kernelnewbies.org/FirstKernelPatch [2]
>> where I found checkpatch.pl [3]. Would it make sense to check all commits
>> that are not in next/master/maint with this script on Travis-CI?
>
> That does not help very much.  These changes are already shown to
> people and dirtied their eyes, and most likely I've already have
> wasted time tweaking the glitches out locally.  The damage has
> already been done.
>
> It would make a lot of sense if the checkpatch is called inside
> Roberto Tyley's "pull-request-to-patch-submission" thing, though.

I've not personally run checkpatch.pl (as Peff mentioned, it's not
actually a documented part of the Git project's recommend contribution
workflow) - I'm still trying to understand whether it will restrict
it's errors to just the things that are introduced in a patch, or if
it will indiscriminately mention existing problems too (of which I
guess there are many already present in the live Git codebase?). If it
mentions _existing_ problems, I wouldn't personally want it in any
automated flow until it can be tuned to find the trees of master/maint
totally clean. At that point it could be added to the Travis build,
and GitHub would automatically reflect the Travis status in any
git/git PR.

I like the idea of giving helpful guidance to users on how to make
their patches cleaner - I'm not that enthusiastic about submitGit
invoking the checkpatch.pl script directly at this point, given that
it lives in a separate project (the linux kernel) and the version
Junio uses is patched off _that_ - I'm lazy enough to not want to try
to get that all to work reliably on a little transient Heroku box.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1] travis-ci: override CFLAGS properly, add -Wdeclaration-after-statement

[Jeff King]

On Tue, Feb 09, 2016 at 11:06:17AM +0100, Lars Schneider wrote:

> I collected the warnings from Junio's Make [1] script and merged them with 
> yours. This is the resulting warning list for clang and gcc:
> 
> -Wdeclaration-after-statement -Wno-format-zero-length -Wold-style-definition 
> -Woverflow -Wpointer-arith -Wstrict-prototypes -Wunused -Wvla

Sounds right.

> > I have, however, wondered if it would make sense to codify this
> > knowledge in the Makefile with an optional knob. E.g., let DEVELOPER=1
> > roughly mean "you are a git dev, you have a reasonably modern compiler,
> > and want to be as careful as possible before sending your patches".
> 
> That make sense. However, in "development mode" I don't like Werror.
> How about two knobs? One called DEVELOPER which enables all the warnings
> above and one called CONTINUOUS_INTEGRATION that enables Werror
> in addition?

I'm curious why you don't want -Werror. Junio is going to compile the
result of applying your patch with it, so it makes sense to me to catch
problems as early as possible.

And while there are certainly false positives from gcc's warnings, we
work to squelch them whether -Werror is in effect or not. So IMHO,
-Werror is mostly about making sure you _see_ the warnings and don't
lose them in a flood of compilation messages.

> Regarding CI checks:
> 
> Jeff Merkey made me aware of http://kernelnewbies.org/FirstKernelPatch [2]
> where I found checkpatch.pl [3]. Would it make sense to check all commits
> that are not in next/master/maint with this script on Travis-CI?
> 
> Stefan Beller recently mentioned "Adhere to the common coding style of 
> Git" [4] where he removed explicit NULL checks. This kind of stuff could be
> checked automatically with checkpatch.pl as far as I can see.

Perhaps. I'm not sure that people actually use checkpatch.pl for git.
Out of curiosity, I tried:

  mkdir out
  git format-patch -o out v2.6.0..v2.7.0
  checkpatch.pl out/*

It's rather noisy, and after skimming, I'd say (subjectively) that only
a small fraction are actual style issues we try to enforce. So it would
certainly need a fair bit of tweaking for regular use, I think.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1] travis-ci: override CFLAGS properly, add -Wdeclaration-after-statement

[Junio C Hamano]

Jeff King  writes:

> Perhaps. I'm not sure that people actually use checkpatch.pl for git.
>
> Out of curiosity, I tried:
>
>   mkdir out
>   git format-patch -o out v2.6.0..v2.7.0
>   checkpatch.pl out/*
>
> It's rather noisy, and after skimming, I'd say (subjectively) that only
> a small fraction are actual style issues we try to enforce. So it would
> certainly need a fair bit of tweaking for regular use, I think.
>
> -Peff

FWIW, I use the attached (it assumes a recent kernel checkout at
certain location and checkpatch-original.pl being a symlink to it)
occasionally.  I found patches from some people are consistently
clean and suspect they may be running checkpatch themselves.

-- >8 -- Meta/CP (not on 'todo' branch) -- >8 --
#!/bin/sh

# Run checkpatch on the series
Meta=$(git rev-parse --show-cdup)Meta
cp0="$Meta/checkpatch-original.pl"
cp1="$Meta/checkpatch.pl"
tmp="/var/tmp/CP.$$"

mkdir "$tmp" || exit
trap 'rm -fr "$tmp"' 0

if  ! test -f "$cp1" ||
test "$cp0" -nt "$cp1"
then
cat "$cp0" >"$cp1" &&
(cd "$Meta" &&
patch -p1 <<\EOF
--- a/checkpatch.pl
+++ b/checkpatch.pl
@@ -282,6 +282,8 @@
Reviewed-by:|
Reported-by:|
Suggested-by:|
+   Helped-by:|
+   Mentored-by:|
To:|
Cc:
 )};
@@ -2338,7 +2340,7 @@
 
 # check for new typedefs, only function parameters and sparse annotations
 # make sense.
-   if ($line =~ /\btypedef\s/ &&
+   if (0 && $line =~ /\btypedef\s/ &&
$line !~ /\btypedef\s+$Type\s*\(\s*\*?$Ident\s*\)\s*\(/ &&
$line !~ /\btypedef\s+$Type\s+$Ident\s*\(/ &&
$line !~ /\b$typeTypedefs\b/ &&
@@ -2607,8 +2609,7 @@
 
# No spaces for:
#   ->
-   #   :   when part of a bitfield
-   } elsif ($op eq '->' || $opv eq ':B') {
+   } elsif ($op eq '->') {
if ($ctx =~ /Wx.|.xW/) {
ERROR("SPACING",
  "spaces prohibited around 
that '$op' $at\n" . $hereptr);

EOF
)
fi || exit

cat "$@" | git mailsplit -b -o"$tmp" >/dev/null

for mail in "$tmp"/*
do
(
git mailinfo -k "$mail.msg" "$mail.patch" >"$mail.info" <"$mail"
echo
cat "$mail.msg"
printf "%s\n" -- "---"
cat "$mail.patch"
) >"$mail.mbox"
perl "$Meta/checkpatch.pl" $ignore --no-tree --max-line-length=120 
"$mail.mbox" || {
grep "Subject: " "$mail.info"
printf "%s\n" -- 
""
}
done


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1] travis-ci: override CFLAGS properly, add -Wdeclaration-after-statement

[Jeff King]

On Mon, Feb 08, 2016 at 09:59:18AM +0100, larsxschnei...@gmail.com wrote:

> From: Lars Schneider 
> 
> The global Travis-CI environment variable CFLAGS did not override the
> CFLAGS variable in the makefile. Pass CFLAGS as make variable to
> override it properly.

Makes sense.

> In addition to that, add '-Wdeclaration-after-statement' to make a
> Travis-CI build fail (because of '-Werror') if the code does not adhere
> to the Git coding style.

I think this is a good step, but is probably the tip of the iceberg. I
typically use:

  -Wall -Werror -Wdeclaration-after-statement
  -Wpointer-arith -Wstrict-prototypes -Wvla
  -Wold-style-declaration -Wold-style-definition

Junio does his integration testing with a similar set, which I think you
can find in one of the scripts in his "todo" branch.

> I made this patch because Peff pointed out to me that "git style doesn't
> allow declaration-after-statement" [1]. I wonder if it would make sense
> to add this check even in the makefile [2]?

I think we keep the default CFLAGS to a pretty tame set, so that we
build out of the box on a large number of compilers. I know I have run
into problems with -Wold-style-* on clang (though perhaps that is no
longer the case, as I haven't tried recently), let alone truly antique
compilers.

I have, however, wondered if it would make sense to codify this
knowledge in the Makefile with an optional knob. E.g., let DEVELOPER=1
roughly mean "you are a git dev, you have a reasonably modern compiler,
and want to be as careful as possible before sending your patches".

> I am no make expert, but I
> also wonder why we don't use the override directive [3] for the CFLAGS?
> AFAIK this would allow a make invocation like this:
> 
> make target CFLAGS+=-Wdeclaration-after-statement

I think it is rather the opposite. If we used:

  override CFLAGS+= ...

in the Makefile, then if a user did:

  make CFLAGS=...

we would add to their CFLAGS (whereas without the override, our
appending is ignored). Our Makefile solves that in a different way,
though. We pass $(ALL_CFLAGS) to the compiler, and that in turn is made
up of $(CFLAGS) and $(BASIC_CFLAGS). We assume the user tweaks the
former, and we set the latter based on Makefile knobs (e.g., NO_CURL,
etc).

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v1] travis-ci: override CFLAGS properly, add -Wdeclaration-after-statement

[larsxschneider]

From: Lars Schneider 

The global Travis-CI environment variable CFLAGS did not override the
CFLAGS variable in the makefile. Pass CFLAGS as make variable to
override it properly.

In addition to that, add '-Wdeclaration-after-statement' to make a
Travis-CI build fail (because of '-Werror') if the code does not adhere
to the Git coding style.

Inspired-by: Jeff King 
Signed-off-by: Lars Schneider 
---

I made this patch because Peff pointed out to me that "git style doesn't
allow declaration-after-statement" [1]. I wonder if it would make sense
to add this check even in the makefile [2]? I am no make expert, but I
also wonder why we don't use the override directive [3] for the CFLAGS?
AFAIK this would allow a make invocation like this:

make target CFLAGS+=-Wdeclaration-after-statement

Thanks,
Lars

[1] http://www.spinics.net/lists/git/msg267273.html
[2] 
https://github.com/git/git/blob/ff4ea6004fb48146330d663d64a71e7774f059f9/Makefile#L377
[3] https://www.gnu.org/software/make/manual/make.html#Override-Directive

 .travis.yml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index c3bf9c6..29abff4 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -20,7 +20,7 @@ env:
 - DEFAULT_TEST_TARGET=prove
 - GIT_PROVE_OPTS="--timer --jobs 3"
 - GIT_TEST_OPTS="--verbose --tee"
-- CFLAGS="-g -O2 -Wall -Werror"
+- CFLAGS="-g -O2 -Wall -Werror -Wdeclaration-after-statement"
 - GIT_TEST_CLONE_2GB=YesPlease
 # t9810 occasionally fails on Travis CI OS X
 # t9816 occasionally fails with "TAP out of sequence errors" on Travis CI 
OS X
@@ -68,7 +68,7 @@ before_install:
 echo "$(tput setaf 6)Git-LFS Version$(tput sgr0)";
 git-lfs version;

-before_script: make --jobs=2
+before_script: make CFLAGS="$CFLAGS" --jobs=2

 script: make --quiet test

--
2.5.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html