Merge branch 'jc/doc-log-rev-list-options'

diff --git a/Documentation/git-bisect-lk2009.txt b/Documentation/git-bisect-lk2009.txt
index 0eed3e3f2939665a23b972144ad38397b31a53e6..0f0c6ff0829dfab3bd45b34b76a5b489f648eba9 100644 (file)
--- a/Documentation/git-bisect-lk2009.txt
+++ b/Documentation/git-bisect-lk2009.txt
@@ -119,7 +119,7 @@ developed and maintained during years or even tens of years by a lot
 of people. And as there are often many people who depend (sometimes
 critically) on such software, regressions are a really big problem.
 
-One such software is the linux kernel. And if we look at the linux
+One such software is the Linux kernel. And if we look at the Linux
 kernel, we can see that a lot of time and effort is spent to fight
 regressions. The release cycle start with a 2 weeks long merge
 window. Then the first release candidate (rc) version is tagged. And
@@ -132,7 +132,7 @@ regressions. And this time is more than 80% of the release cycle
 time. But this is not the end of the fight yet, as of course it
 continues after the release.
 
-And then this is what Ingo Molnar (a well known linux kernel
+And then this is what Ingo Molnar (a well known Linux kernel
 developer) says about his use of git bisect:
 
 _____________
@@ -1320,7 +1320,7 @@ So git bisect is unconditional goodness - and feel free to quote that
 ;-)
 _____________
 
-Acknowledgements
+Acknowledgments
 ----------------
 
 Many thanks to Junio Hamano for his help in reviewing this paper, for