From: Junio C Hamano Date: Fri, 16 Oct 2015 21:32:53 +0000 (-0700) Subject: Merge branch 'jk/asciidoctor-section-heading-markup-fix' into maint X-Git-Tag: v2.6.2~5 X-Git-Url: https://git.lorimer.id.au/gitweb.git/diff_plain/aa8f64dead9d1ea5965fe1248709f1879f0da79c?ds=inline;hp=-c Merge branch 'jk/asciidoctor-section-heading-markup-fix' into maint * jk/asciidoctor-section-heading-markup-fix: Documentation: fix section header mark-up --- aa8f64dead9d1ea5965fe1248709f1879f0da79c diff --combined Documentation/git-bisect-lk2009.txt index 0f0c6ff082,78b10659c5..c06efbd42a --- a/Documentation/git-bisect-lk2009.txt +++ b/Documentation/git-bisect-lk2009.txt @@@ -119,7 -119,7 +119,7 @@@ developed and maintained during years o 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 +132,7 @@@ regressions. And this time is more tha 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: _____________ @@@ -1321,7 -1321,7 +1321,7 @@@ So git bisect is unconditional goodnes _____________ Acknowledgments - ---------------- + --------------- Many thanks to Junio Hamano for his help in reviewing this paper, for reviewing the patches I sent to the Git mailing list, for discussing diff --combined Documentation/user-manual.txt index 68978f5338,c964a8b0d6..1b7987e737 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@@ -1200,7 -1200,7 +1200,7 @@@ for other users who clone your reposito If you wish the exclude patterns to affect only certain repositories (instead of every repository for a given project), you may instead put them in a file in your repository named `.git/info/exclude`, or in any -file specified by the `core.excludesfile` configuration variable. +file specified by the `core.excludesFile` configuration variable. Some Git commands can also take exclude patterns directly on the command line. See linkgit:gitignore[5] for the details. @@@ -3424,7 -3424,7 +3424,7 @@@ just missing one particular blob versio [[the-index]] The index - ----------- + --------- The index is a binary file (generally kept in `.git/index`) containing a sorted list of path names, each with permissions and the SHA-1 of a blob @@@ -4230,9 -4230,9 +4230,9 @@@ Most of what `git rev-list` did is cont controls how and what revisions are walked, and more. The original job of `git rev-parse` is now taken by the function -`setup_revisions()`, which parses the revisions and the common command line +`setup_revisions()`, which parses the revisions and the common command-line options for the revision walker. This information is stored in the struct -`rev_info` for later consumption. You can do your own command line option +`rev_info` for later consumption. You can do your own command-line option parsing after calling `setup_revisions()`. After that, you have to call `prepare_revision_walk()` for initialization, and then you can get the commits one by one with the function `get_revision()`.