yocto-docs: Fixup a couple of merge issues

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

2 files changed, 75 insertions, 32 deletions

diff --git a/documentation/Makefile b/documentation/Makefile
index 5272ee58bd..c3c6a3c7e3 100644
--- a/documentation/Makefile
+++ b/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
-MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf
+           figures/sysprof-copy-from-user.png figures/sysprof-copy-to-user.png \
+           eclipse
+MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf $(DOC)/eclipse
 FIGURES = figures
 STYLESHEET = $(DOC)/*.css
 endif
diff --git a/documentation/kernel-manual/kernel-how-to.xml b/documentation/kernel-manual/kernel-how-to.xml
index f29a0a865a..9d9aef6d06 100644
--- a/documentation/kernel-manual/kernel-how-to.xml
+++ b/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
-                kernel.
+                This sort of patch inspection is not an efficient way to determine what has been
+                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'>
-                <title>What Changed in a BSP?</title>
+            <section id='what-changed-in-a-kernel'>
+                <title>What Changed in a Kernel?</title>
 
                 <para>
-                    Following are a few examples that show how to use Git to examine changes.
-                    Because the Yocto Project Git repository does not break existing Git
-                    functionality and because there exists many permutations of these types of
-                    commands, there are many more methods to discover changes.
+                    Following are a few examples that show how to use Git commands to examine changes.
+                    Because Git repositories in the Yocto Project do not break existing Git
+                    functionality, and because there exists many permutations of these types of
+                    Git commands, many methods exist by which you can discover changes.
                     <note>
-                        Unless you provide a commit range
-                        (&lt;kernel-type&gt;..&lt;bsp&gt;-&lt;kernel-type&gt;), <filename>kernel.org</filename> history
-                        is blended with Yocto Project changes.
+                        In the following examples, unless you provide a commit range,
+                        <filename>kernel.org</filename> history is blended with Yocto Project
+                        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>
-                    <literallayout class='monospaced'>
-     # full description of the changes
-     &gt; git whatchanged &lt;kernel type&gt;..&lt;kernel type&gt;/&lt;bsp&gt;
-        &gt; eg: git whatchanged yocto/standard/base..yocto/standard/common-pc/base
+                    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>
 
-     # summary of the changes
-     &gt; git log --pretty=oneline --abbrev-commit &lt;kernel type&gt;..&lt;kernel type&gt;/&lt;bsp&gt;
+                <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'>
+     $ git whatchanged origin/standard/base..origin/standard/emenlow
+                    </literallayout>
+                </para>
 
-     # source code changes (one combined diff)
-     &gt; git diff &lt;kernel type&gt;..&lt;kernel type&gt;/&lt;bsp&gt;
-     &gt; git show &lt;kernel type&gt;..&lt;kernel type&gt;/&lt;bsp&gt;
+                <para>
+                    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>
 
-     # dump individual patches per commit
-     &gt; git format-patch -o &lt;dir&gt; &lt;kernel type&gt;..&lt;kernel type&gt;/&lt;bsp&gt;
+                <para>
+                    If you want to see code differences associated with all the changes, use
+                    the <filename>git diff</filename> command.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     $ git diff origin/standard/base..origin/standard/emenlow
+                    </literallayout>
+                </para>
 
-     # determine the change history of a particular file
-     &gt; git whatchanged &lt;path to file&gt;
+                <para>
+                    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 commits which touch each line in a file
-     &gt; git blame &lt;path to file&gt;
+                <para>
+                    You can create individual patches for each change by using the
+                    <filename>git format-patch</filename> command.
+                    Here is an example that that creates patch files for each commit and
+                    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>