yocto-docs: Fixup a couple of merge issues

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

documentation/Makefile

@@ -209,7 +209,7 @@ ifeq ($(DOC),ref-manual)
 XSLTOPTS = --xinclude
 ALLPREQ = html pdf eclipse tarball
 TARFILES = ref-manual.html ref-style.css figures/poky-title.png \
-	figures/buildhistory.png figures/buildhistory-web.png  eclipse
+	figures/buildhistory.png figures/buildhistory-web.png eclipse
 MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf $(DOC)/eclipse
 FIGURES = figures
 STYLESHEET = $(DOC)/*.css
@@ -245,8 +245,9 @@ TARFILES = profile-manual.html profile-manual.pdf profile-manual-style.css \
            figures/perf-wget-g-copy-to-user-expanded-stripped-unresolved-hidden.png figures/pybootchartgui-linux-yocto.png \
            figures/pychart-linux-yocto-rpm.png figures/pychart-linux-yocto-rpm-nostrip.png \
            figures/sched-wakeup-profile.png figures/sysprof-callers.png \
-           figures/sysprof-copy-from-user.png figures/sysprof-copy-to-user.png
+           figures/sysprof-copy-from-user.png figures/sysprof-copy-to-user.png \
-MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf
+           eclipse
+MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf $(DOC)/eclipse
 FIGURES = figures
 STYLESHEET = $(DOC)/*.css
 endif

documentation/kernel-manual/kernel-how-to.xml

@@ -246,10 +246,10 @@
         </para>
 
         <section id='change-inspection-kernel-changes-commits'>
-            <title>Change Inspection: Kernel Changes/Commits</title>
+            <title>Change Inspection: Changes/Commits</title>
 
             <para>
-                A common question when working with a BSP or kernel is:
+                A common question when working with a kernel is:
                 "What changes have been applied to this tree?"
             </para>
 
@@ -257,53 +257,95 @@
                 In projects that have a collection of directories that
                 contain patches to the kernel, it is possible to inspect or "grep" the contents
                 of the directories to get a general feel for the changes.
-                This sort of patch inspection is not an efficient way to determine what has been done to the
+                This sort of patch inspection is not an efficient way to determine what has been
-                kernel.
+                done to the kernel.
                 The reason it is inefficient is because there are many optional patches that are
                 selected based on the kernel type and the feature description.
                 Additionally, patches could exist in directories that are not included in the search.
             </para>
 
             <para>
-                A more efficient way to determine what has changed in the kernel is to use
+                A more efficient way to determine what has changed in the branch is to use
                 Git and inspect or search the kernel tree.
                 This method gives you a full view of not only the source code modifications,
                 but also provides the reasons for the changes.
             </para>
 
-            <section id='what-changed-in-a-bsp'>
+            <section id='what-changed-in-a-kernel'>
-                <title>What Changed in a BSP?</title>
+                <title>What Changed in a Kernel?</title>
 
                 <para>
-                    Following are a few examples that show how to use Git to examine changes.
+                    Following are a few examples that show how to use Git commands to examine changes.
-                    Because the Yocto Project Git repository does not break existing Git
+                    Because Git repositories in the Yocto Project do not break existing Git
-                    functionality and because there exists many permutations of these types of
+                    functionality, and because there exists many permutations of these types of
-                    commands, there are many more methods to discover changes.
+                    Git commands, many methods exist by which you can discover changes.
                     <note>
-                        Unless you provide a commit range
+                        In the following examples, unless you provide a commit range,
-                        (&lt;kernel-type&gt;..&lt;bsp&gt;-&lt;kernel-type&gt;), <filename>kernel.org</filename> history
+                        <filename>kernel.org</filename> history is blended with Yocto Project
-                        is blended with Yocto Project changes.
+                        kernel changes.
+                        You can form ranges by using branch names from the kernel tree as the
+                        upper and lower commit markers with the Git commands.
+                        You can see the branch names through the web interface to the
+                        Yocto Project source repositories at
+                        <ulink url='http://git.yoctoproject.org/cgit.cgi'></ulink>.
+                        For example, the branch names for the <filename>linux-yocto-3.4</filename>
+                        kernel repository can be seen at
+                        <ulink url='http://git.yoctoproject.org/cgit.cgi/linux-yocto-3.4/refs/heads'></ulink>.
                     </note>
+                    To see a full range of the changes, use the
+                    <filename>git whatchanged</filename> command and specify a commit range
+                    for the branch (<filename>&lt;commit&gt;..&lt;commit&gt;</filename>).
+                </para>
+
+                <para>
+                    Here is an example that looks at what has changed in the
+                    <filename>emenlow</filename> branch of the
+                    <filename>linux-yocto-3.4</filename> kernel.
+                    The lower commit range is the commit associated with the
+                    <filename>standard/base</filename> branch, while
+                    the upper commit range is the commit associated with the
+                    <filename>standard/emenlow</filename> branch.
                     <literallayout class='monospaced'>
-     # full description of the changes
+     $ git whatchanged origin/standard/base..origin/standard/emenlow
-     &gt; git whatchanged &lt;kernel type&gt;..&lt;kernel type&gt;/&lt;bsp&gt;
+                    </literallayout>
-        &gt; eg: git whatchanged yocto/standard/base..yocto/standard/common-pc/base
+                </para>
 
-     # summary of the changes
+                <para>
-     &gt; git log --pretty=oneline --abbrev-commit &lt;kernel type&gt;..&lt;kernel type&gt;/&lt;bsp&gt;
+                    To see a summary of changes use the <filename>git log</filename> command.
+                    Here is an example using the same branches:
+                    <literallayout class='monospaced'>
+     $ git log --oneline origin/standard/base..origin/standard/emenlow
+                    </literallayout>
+                    The <filename>git log</filename> output might be more useful than
+                    the <filename>git whatchanged</filename> as you get
+                    a short, one-line summary of each change and not the entire commit.
+                </para>
 
-     # source code changes (one combined diff)
+                <para>
-     &gt; git diff &lt;kernel type&gt;..&lt;kernel type&gt;/&lt;bsp&gt;
+                    If you want to see code differences associated with all the changes, use
-     &gt; git show &lt;kernel type&gt;..&lt;kernel type&gt;/&lt;bsp&gt;
+                    the <filename>git diff</filename> command.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     $ git diff origin/standard/base..origin/standard/emenlow
+                    </literallayout>
+                </para>
 
-     # dump individual patches per commit
+                <para>
-     &gt; git format-patch -o &lt;dir&gt; &lt;kernel type&gt;..&lt;kernel type&gt;/&lt;bsp&gt;
+                    You can see the commit log messages and the text differences using the
+                    <filename>git show</filename> command:
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     $ git show origin/standard/base..origin/standard/emenlow
+                    </literallayout>
+                </para>
 
-     # determine the change history of a particular file
+                <para>
-     &gt; git whatchanged &lt;path to file&gt;
+                    You can create individual patches for each change by using the
-
+                    <filename>git format-patch</filename> command.
-     # determine the commits which touch each line in a file
+                    Here is an example that that creates patch files for each commit and
-     &gt; git blame &lt;path to file&gt;
+                    places them in your <filename>Documents</filename> directory:
+                    <literallayout class='monospaced'>
+     $ git format-patch -o $HOME/Documents origin/standard/base..origin/standard/emenlow
                     </literallayout>
                 </para>
             </section>