From 72fdc8ed09ca82008c57b7bc8a090d25332def37 Mon Sep 17 00:00:00 2001 From: Richard Purdie Date: Thu, 14 Feb 2013 17:30:09 +0000 Subject: yocto-docs: Fixup a couple of merge issues Signed-off-by: Richard Purdie --- documentation/Makefile | 7 +- documentation/kernel-manual/kernel-how-to.xml | 100 ++++++++++++++++++-------- 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 @@
- Change Inspection: Kernel Changes/Commits + Change Inspection: Changes/Commits - 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?" @@ -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. - 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. -
- What Changed in a BSP? +
+ What Changed in a Kernel? - 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. - Unless you provide a commit range - (<kernel-type>..<bsp>-<kernel-type>), kernel.org history - is blended with Yocto Project changes. + In the following examples, unless you provide a commit range, + kernel.org 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 + . + For example, the branch names for the linux-yocto-3.4 + kernel repository can be seen at + . - - # full description of the changes - > git whatchanged <kernel type>..<kernel type>/<bsp> - > eg: git whatchanged yocto/standard/base..yocto/standard/common-pc/base + To see a full range of the changes, use the + git whatchanged command and specify a commit range + for the branch (<commit>..<commit>). + - # summary of the changes - > git log --pretty=oneline --abbrev-commit <kernel type>..<kernel type>/<bsp> + + Here is an example that looks at what has changed in the + emenlow branch of the + linux-yocto-3.4 kernel. + The lower commit range is the commit associated with the + standard/base branch, while + the upper commit range is the commit associated with the + standard/emenlow branch. + + $ git whatchanged origin/standard/base..origin/standard/emenlow + + - # source code changes (one combined diff) - > git diff <kernel type>..<kernel type>/<bsp> - > git show <kernel type>..<kernel type>/<bsp> + + To see a summary of changes use the git log command. + Here is an example using the same branches: + + $ git log --oneline origin/standard/base..origin/standard/emenlow + + The git log output might be more useful than + the git whatchanged as you get + a short, one-line summary of each change and not the entire commit. + - # dump individual patches per commit - > git format-patch -o <dir> <kernel type>..<kernel type>/<bsp> + + If you want to see code differences associated with all the changes, use + the git diff command. + Here is an example: + + $ git diff origin/standard/base..origin/standard/emenlow + + - # determine the change history of a particular file - > git whatchanged <path to file> + + You can see the commit log messages and the text differences using the + git show command: + Here is an example: + + $ git show origin/standard/base..origin/standard/emenlow + + - # determine the commits which touch each line in a file - > git blame <path to file> + + You can create individual patches for each change by using the + git format-patch command. + Here is an example that that creates patch files for each commit and + places them in your Documents directory: + + $ git format-patch -o $HOME/Documents origin/standard/base..origin/standard/emenlow
-- cgit v1.2.3-54-g00ecf