diff options
Diffstat (limited to 'documentation/kernel-manual/kernel-how-to.xml')
| -rw-r--r-- | documentation/kernel-manual/kernel-how-to.xml | 2172 |
1 files changed, 0 insertions, 2172 deletions
diff --git a/documentation/kernel-manual/kernel-how-to.xml b/documentation/kernel-manual/kernel-how-to.xml deleted file mode 100644 index abb19f285c..0000000000 --- a/documentation/kernel-manual/kernel-how-to.xml +++ /dev/null @@ -1,2172 +0,0 @@ -<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - -<chapter id='kernel-how-to'> - -<title>Working with the Yocto Project Kernel</title> - - -<section id='actions-org'> - <title>Introduction</title> - <para> - This chapter describes how to accomplish tasks involving the kernel's tree structure. - The information covers the following: - <itemizedlist> - <listitem><para>Tree construction</para></listitem> - <listitem><para>Build strategies</para></listitem> -<!-- <listitem><para>Series & Configuration Compiler</para></listitem> - <listitem><para>kgit</para></listitem> --> - <listitem><para>Workflow examples</para></listitem> -<!-- <listitem><para>Source Code Manager (SCM)</para></listitem> - <listitem><para>Board Support Package (BSP) template migration</para></listitem> - <listitem><para>BSP creation</para></listitem> - <listitem><para>Patching</para></listitem> - <listitem><para>Updating BSP patches and configuration</para></listitem> - <listitem><para>guilt</para></listitem> - <listitem><para>scc file example</para></listitem> - <listitem><para>"dirty" string</para></listitem> - <listitem><para>Transition kernel layer</para></listitem> --> - </itemizedlist> - </para> -</section> - - <section id='tree-construction'> - <title>Tree Construction</title> - <para> - The Yocto Project kernel repository, as shipped with the product, is created by - compiling and executing the set of feature descriptions for every BSP/feature - in the product. - Those feature descriptions list all necessary patches, - configuration, branching, tagging and feature divisions found in the kernel. - </para> - <para> - You can find the files used to describe all the valid features and BSPs in the Yocto Project - kernel in any clone of the kernel git tree. - The directory <filename>meta/cfg/kernel-cache/</filename> is a snapshot of all the kernel - configuration and feature descriptions (.scc) used to build the kernel repository. - You should realize, however, that browsing the snapshot of feature - descriptions and patches is not an effective way to determine what is in a - particular kernel branch. - Instead, you should use git directly to discover the changes - in a branch. - Using git is a efficient and flexible way to inspect changes to the kernel. - For examples showing how to use git to inspect kernel commits, see the following sections - in this chapter. - </para> - <note><para> - Ground up reconstruction of the complete kernel tree is an action only taken by the - Yocto Project team during an active development cycle. - Creating a project simply clones this tree to make it efficiently available for building - and development. - </para></note> - <para> - The general flow for constructing a project-specific kernel tree is as follows: - <orderedlist> - <listitem><para>A top-level kernel feature is passed to the kernel build subsystem. - Normally, this is a BSP for a particular kernel type.</para></listitem> - - <listitem><para>The file that describes the top-level feature is located by searching - these system directories:</para> - - <itemizedlist> - <listitem><para>The in-tree kernel-cache directories</para></listitem> -<!-- <listitem><para>kernel-*-cache directories in layers</para></listitem> --> - <listitem><para>Recipe SRC_URIs</para></listitem> -<!-- <listitem><para>configured and default templates</para></listitem> --> - </itemizedlist> - - <para>For a typical build a feature description of the format: - <bsp name>-<kernel type>.scc is the target of the search. - </para></listitem> - - <listitem><para>Once located, the feature description is either compiled into a simple script - of actions, or an existing equivalent script that was part of the - shipped kernel is located.</para></listitem> - - <listitem><para>Extra features are appended to the top-level feature description. - These features can come from the KERNEL_FEATURES variable in recipes.</para></listitem> - - <listitem><para>Each extra feature is located, compiled and appended to the script from - step #3</para></listitem> - - <listitem><para>The script is executed, and a meta-series is produced. - The meta-series is a description of all the branches, tags, patches and configuration that - needs to be applied to the base git repository to completely create the - BSP source (build) branch.</para></listitem> - - <listitem><para>The base repository is cloned, and the actions - listed in the meta-series are applied to the tree.</para></listitem> - - <listitem><para>The git repository is left with the desired branch checked out and any - required branching, patching and tagging has been performed.</para></listitem> - </orderedlist> - </para> - - <para> - The tree is now ready for configuration and compilation. - </para> - - <note><para>The end-user generated meta-series adds to the kernel as shipped with - the Yocto Project release. - Any add-ons and configuration data are applied to the end of an existing branch. - The full repository generation that is found in the - official Yocto Project kernel repositories is the combination of all - supported boards and configurations.</para> - - <para>This technique is flexible and allows the seamless blending of an immutable - history with additional deployment specific patches. - Any additions to the kernel become an integrated part of the branches. - </para></note> - -<!-- <note><para>It is key that feature descriptions indicate if any branches are - required, since the build system cannot automatically decide where a - BSP should branch or if that branch point needs a name with - significance. There is a single restriction enforced by the compilation - phase: - </para> - <para>A BSP must create a branch of the format <bsp name>-<kernel type>.</para> - - <para>This means that all merged/support BSPs must indicate where to start - its branch from, with the right name, in its .scc files. The scc - section describes the available branching commands in more detail. - </para> -</note> --> - -<!-- <para> -A summary of end user tree construction activities follow: -<itemizedlist> - <listitem><para>compile and link a full top-down kernel description from feature descriptions</para></listitem> - <listitem><para>execute the complete description to generate a meta-series</para></listitem> - <listitem><para>interpret the meta-series to create a customized git repository for the - board</para></listitem> - <listitem><para>migrate configuration fragments and configure the kernel</para></listitem> - <listitem><para>checkout the BSP branch and build</para></listitem> -</itemizedlist> -</para> --> - </section> - - <section id='build-strategy'> - <title>Build Strategy</title> - <para> - There are some prerequisites that must be met before starting the compilation - phase of the kernel build system: - </para> - - <itemizedlist> - <listitem><para>There must be a kernel git repository indicated in the SRC_URI.</para></listitem> - <listitem><para>There must be a BSP build branch - <bsp name>-<kernel type> in 0.9 or - <kernel type>/<bsp name> in 1.0.</para></listitem> - </itemizedlist> - - <para> - You can typically meet these prerequisites by running the tree construction/patching phase - of the build system. - However, other means do exist. - For examples of alternate workflows such as bootstrapping a BSP, see - the<link linkend='workflow-examples'> Workflow Examples</link> section in this manual. - </para> - - <para> - Before building a kernel it is configured by processing all of the - configuration "fragments" specified by the scc feature descriptions. - As the features are compiled, associated kernel configuration fragments are noted - and recorded in the meta-series in their compilation order. - The fragments are migrated, pre-processed and passed to the Linux Kernel - Configuration subsystem (lkc) as raw input in the form of a <filename>.config</filename> file. - The lkc uses its own internal dependency constraints to do the final - processing of that information and generates the final <filename>.config</filename> file - that is used during compilation. - </para> - - <para> - Using the board's architecture and other relevant values from the board's template - the Kernel compilation is started and a kernel image is produced. - </para> - - <para>The other thing that you will first see once you configure a kernel is that - it will generate a build tree that is separate from your git source tree. - This build tree has the name using the following form: - <literallayout class='monospaced'> - linux-<BSPname>-<kerntype>-build - </literallayout> - "kerntype" is one of the standard kernel types. - </para> - - <para> - The existing support in the kernel.org tree achieves this default functionality. - </para> - - <para> - What this means, is that all the generated files for a particular BSP are now in this directory. - The files include the final <filename>.config</filename>, all the <filename>.o</filename> - files, the <filename>.a</filename> files, and so forth. - Since each BSP has its own separate build directory in its own separate branch - of the git tree you can easily switch between different BSP builds. - </para> - </section> - -<!-- <section id='scc'> - <title>Series & Configuration Compiler (SCC)</title> -<para> -In early versions of the product, kernel patches were simply listed in a flat -file called "patches.list", and then quilt was added as a tool to help -traverse this list, which in quilt terms was called a "series" file. -</para> -<para> -Before the 2.0 release, it was already apparent that a static series file was -too inflexible, and that the series file had to become more dynamic and rely -on certain state (like kernel type) in order to determine whether a patch was -to be used or not. The 2.0 release already made use of some stateful -construction of series files, but since the delivery mechanism was unchanged -(tar + patches + series files), most people were not aware of anything really -different. The 3.0 release continues with this stateful construction of -series files, but since the delivery mechanism is changed (git + branches) it -now is more apparent to people. -</para> -<para> -As was previously mentioned, scc is a "series and configuration -compiler". Its role is to combine feature descriptions into a format that can -be used to generate a meta-series. A meta series contains all the required -information to construct a complete set of branches that are required to -build a desired board and feature set. The meta series is interpreted by the -kgit tools to create a git repository that could be built. -</para> -<para> -To illustrate how scc works, a feature description must first be understood. -A feature description is simply a small bash shell script that is executed by -scc in a controlled environment. Each feature description describes a set of -operations that add patches, modify existing patches or configure the -kernel. It is key that feature descriptions can include other features, and -hence allow the division of patches and configuration into named, reusable -containers. -</para> -<para> -Each feature description can use any of the following valid scc commands: -<itemizedlist> - <listitem><para>shell constructs: bash conditionals and other utilities can be used in a feature - description. During compilation, the working directory is the feature - description itself, so any command that is "raw shell" and not from the - list of supported commands, can not directly modify a git repository.</para></listitem> - - <listitem><para>patch <relative path>/<patch name>: outputs a patch to be included in a feature's patch set. Only the name of - the patch is supplied, the path is calculated from the currently set - patch directory, which is normally the feature directory itself.</para></listitem> - - <listitem><para>patch_trigger >condition< >action< <tgt>: indicate that a trigger should be set to perform an action on a - patch.</para> - -<para>The conditions can be: - - <itemizedlist> - <listitem><para>arch:<comma separated arch list or "all"></para></listitem> - <listitem><para>plat:<comma separated platform list or "all"></para></listitem> - </itemizedlist></para> -<para>The action can be: - <itemizedlist> - <listitem><para>exclude: This is used in exceptional situations where a patch - cannot be applied for certain reasons (arch or platform). - When the trigger is satisfied the patch will be removed from - the patch list.</para></listitem> - <listitem><para>include: This is used to include a patch only for a specific trigger. - Like exclude, this should only be used when necessary. - It takes 1 argument, the patch to include.</para></listitem> - </itemizedlist></para></listitem> - - <listitem><para>include <feature name> [after <feature>]: includes a feature for processing. The feature is "expanded" at the - position of the include directive. This means that any patches, - configuration or sub-includes of the feature will appear in the final - series before the commands that follow the include.</para> - <para> - include searches the include directories for a matching feature name, - include directories are passed to scc by the caller using -I <path> and - is transparent to the feature script. This means that <feature name> must - be relative to one of the search paths. For example, if - /opt/kernel-cache/feat/sched.scc is to be included and scc is invoked - with -I /opt/kernel-cache, then a feature would issue "include - feat/sched.scc" to include the feature. -</para> -<para> - The optional "after" directive allows a feature to modify the existing - order of includes and insert a feature after the named feature is - processed. Note: the "include foo after bar" must be issued before "bar" - is processed, so is normally only used by a new top level feature to - modify the order of features in something it is including.</para></listitem> - - <listitem><para>exclude <feature name>: Indicates that a particular feature should *not* be included even if an - 'include' directive is found. The exclude must be issued before the - include is processed, so is normally only used by a new top level feature - to modify the order of features in something it is including.</para></listitem> - - <listitem><para>git <command>: Issues any git command during tree construction. Note: this command is - not validated/sanitized so care must be taken to not damage the - tree. This can be used to script branching, tagging, pulls or other git - operations.</para></listitem> - - <listitem><para>dir <directory>: changes the working directory for "patch" directives. This can be used to - shorten a long sequence of patches by not requiring a common relative - directory to be issued each time.</para></listitem> - - <listitem><para>kconf <type> <fragment name>: associates a kernel config frag with the feature. - <type> can be - "hardware" or "non-hardware" and is used by the kernel configuration - subsystem to audit configuration. <fragment name> is the name of a file - in the current feature directory that contains a series of kernel - configuration options. There is no restriction on the chosen fragment - name, although a suffix of ".cfg" is recommended. Multiple fragment - specifications are supported.</para></listitem> - - <listitem><para>branch <branch name>: creates a branch in the tree. All subsequent patch commands will be - applied to the new branch and changes isolated from the rest of the - repository.</para></listitem> - - <listitem><para>scc_leaf <base feature> <branch name>: Performs a combination feature include and branch. This is mainly a - convenience directive, but has significance to some build system bindings - as a sentinel to indicate that this intends to create a branch that is - valid for kernel compilation.</para></listitem> - - <listitem><para>tag <tag name>: Tags the tree. The tag will be applied in processing order, so will - be after already applied patches and precede patches yet to be applied.</para></listitem> - - <listitem><para>define <var> <value>: Creates a variable with a particular value that can be used in subsequent - feature descriptions.</para></listitem> -</itemizedlist> - -</para> - </section> --> - -<!-- <section id='kgit-tools'> - <title>kgit Tools</title> -<para> -The kgit tools are responsible for constructing and maintaining the Wind -River kernel repository. These activities include importing, exporting, and -applying patches as well as sanity checking and branch management. From the -developers perspective, the kgit tools are hidden and rarely require -interactive use. But one tool in particular that warrants further description -is "kgit-meta". -</para> -<para> -kgit-meta is the actual application of feature description(s) to a kernel repo. -In other words, it is responsible for interpreting the meta series generated -from a scc compiled script. As a result, kgit-meta is coupled to the set of -commands permitted in a .scc feature description (listed in the scc section). -kgit-meta understands both the meta series format and how to use git and -guilt to modify a base git repository. It processes a meta-series line by -line, branching, tagging, patching and tracking changes that are made to the -base git repository. -</para> -<para> -Once kgit-meta has processed a meta-series, it leaves the repository with the -last branch checked out, and creates the necessary guilt infrastructure to -inspect the tree, or add to it via using guilt. As was previously mentioned, -guilt is not required, but is provided as a convenience. Other utilities such -as quilt, stgit, git or others can also be used to manipulate the git -repository. -</para> - </section> --> - - <section id='workflow-examples'> - <title>Workflow Examples</title> - - <para> - As previously noted, the Yocto Project kernel has built in git integration. - However, these utilities are not the only way to work with the kernel repository. - Yocto Project has not made changes to git or to other tools that - would invalidate alternate workflows. - Additionally, the way the kernel repository is constructed results in using - only core git functionality thus allowing any number of tools or front ends to use the - resulting tree. - </para> - - <para> - This section contains several workflow examples. - </para> - - <section id='change-inspection-kernel-changes-commits'> - <title>Change Inspection: Kernel Changes/Commits</title> - - <para> - A common question when working with a BSP or kernel is: - "What changes have been applied to this tree?" - </para> - - <para> - 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. - 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 - 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> - - <para> - Following are a few examples that show how to use git to examine changes. - Note that 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. - </para> - - <note><para> - Unless you provide a commit range - (<kernel-type>..<bsp>-<kernel-type>), kernel.org history - is blended with Yocto Project changes. - </para></note> - - <literallayout class='monospaced'> - # full description of the changes - > git whatchanged <kernel type>..<bsp>-<kernel type> - > eg: git whatchanged standard..common_pc-standard - - # summary of the changes - > git log --pretty=oneline --abbrev-commit <kernel type>..<bsp>-<kernel type> - - # source code changes (one combined diff) - > git diff <kernel type>..<bsp>-<kernel type> - > git show <kernel type>..<bsp>-<kernel type> - - # dump individual patches per commit - > git format-patch -o <dir> <kernel type>..<bsp>-<kernel type> - - # determine the change history of a particular file - > git whatchanged <path to file> - - # determine the commits which touch each line in a file - > git blame <path to file> - </literallayout> - </section> - - <section id='show-a-particular-feature-or-branch-change'> - <title>Show a Particular Feature or Branch Change</title> - - <para> - Significant features or branches are tagged in the Yocto Project tree to divide - changes. - Remember to first determine (or add) the tag of interest. - </para> - - <note><para> - Because BSP branch, kernel.org, and feature tags are all present, there are many tags. - </para></note> - - <literallayout class='monospaced'> - # show the changes tagged by a feature - > git show <tag> - > eg: git show yaffs2 - - # determine which branches contain a feature - > git branch --contains <tag> - - # show the changes in a kernel type - (0.9 examples) - > git whatchanged wrs_base..<kernel type> - > eg: git whatchanged wrs_base..standard - </literallayout> - - <para> - You can use many other comparisons to isolate BSP changes. - For example, you can compare against kernel.org tags (e.g. v2.6.27.18, etc), or - you can compare agains subsystems (e.g. git whatchanged mm). - </para> - </section> - </section> - - <section id='development-saving-kernel-modifications'> - <title>Development: Saving Kernel Modifications</title> - - <para> - Another common operation is to build a BSP supplied by Yocto Project, make some - changes, rebuild and then test. - Those local changes often need to be exported, shared or otherwise maintained. - </para> - - <para> - Since the Yocto Project kernel source tree is backed by git, this activity is - much easier as compared to with previous releases. - Because git tracks file modifications, additions and deletions, it is easy - to modify the code and later realize that the changes should be saved. - It is also easy to determine what has changed. - This method also provides many tools to commit, undo and export those modifications. - </para> - - <para> - There are many ways to save kernel modifications. - The technique employed - depends on the destination for the patches: - - <itemizedlist> - <listitem><para>Bulk storage</para></listitem> - <listitem><para>Internal sharing either through patches or by using git</para></listitem> - <listitem><para>External submissions</para></listitem> - <listitem><para>Exporting for integration into another SCM</para></listitem> - </itemizedlist> - </para> - - <para> - Because of the following list of issues, the destination of the patches also influences - the method for gathering them: - - <itemizedlist> - <listitem><para>Bisectability</para></listitem> - <listitem><para>Commit headers</para></listitem> - <listitem><para>Division of subsystems for separate submission or review</para></listitem> - </itemizedlist> - </para> - - <section id='bulk-export'> - <title>Bulk Export</title> - - <para> - This section describes how you can export in "bulk" changes that have not - been separated or divided. - This situation works well when you are simply storing patches outside of the kernel - source repository, either permanently or temporarily, and you are not committing - incremental changes during development. - </para> - - <note><para> - This technique is not appropriate for full integration of upstream submission - because changes are not properly divided and do not provide an avenue for per-change - commit messages. - Therefore, this example assumes that changes have not been committed incrementally - during development and that you simply must gather and export them. - </para></note> - - <literallayout class='monospaced'> - # bulk export of ALL modifications without separation or division - # of the changes - - > git add . - > git commit -s -a -m >commit message< - or - > git commit -s -a # and interact with $EDITOR - </literallayout> - - <para> - The previous operations capture all the local changes in the project source - tree in a single git commit. - And, that commit is also stored in the project's source tree. - </para> - - <para> - Once the changes are exported, you can restore them manually using a template - or through integration with the <filename>default_kernel</filename>. - </para> - - </section> - - <section id='incremental-planned-sharing'> - <title>Incremental/Planned Sharing</title> - - <para> - This section describes how to save modifications when you are making incremental - commits or practicing planned sharing. - The examples in this section assume that changes have been incrementally committed - to the tree during development and now need to be exported. The sections that follow - describe how you can export your changes internally through either patches or by - using git commands. - </para> - - <para> - During development the following commands are of interest. - For full git documentation, refer to the git man pages or to an online resource such - as <ulink url='http://github.com'></ulink>. - - <literallayout class='monospaced'> - # edit a file - > vi >path</file - # stage the change - > git add >path</file - # commit the change - > git commit -s - # remove a file - > git rm >path</file - # commit the change - > git commit -s - - ... etc. - </literallayout> - </para> - - <para> - Distributed development with git is possible when you use a universally - agreed-upon unique commit identifier (set by the creator of the commit) that maps to a - specific changeset with a specific parent. - This identifier is created for you when - you create a commit, and is re-created when you amend, alter or re-apply - a commit. - As an individual in isolation, this is of no interest. - However, if you - intend to share your tree with normal git push and pull operations for - distributed development, you should consider the ramifications of changing a - commit that you have already shared with others. - </para> - - <para> - Assuming that the changes have not been pushed upstream, or pulled into - another repository, you can update both the commit content and commit messages - associated with development by using the following commands: - - <literallayout class='monospaced'> - > git add >path</file - > git commit --amend - > git rebase or git rebase -i - </literallayout> - </para> - - <para> - Again, assuming that the changes have not been pushed upstream, and that - no pending works-in-progress exist (use "git status" to check) then - you can revert (undo) commits by using the following commands: - - <literallayout class='monospaced'> - # remove the commit, update working tree and remove all - # traces of the change - > git reset --hard HEAD^ - # remove the commit, but leave the files changed and staged for re-commit - > git reset --soft HEAD^ - # remove the commit, leave file change, but not staged for commit - > git reset --mixed HEAD^ - </literallayout> - </para> - - <para> - You can create branches, "cherry-pick" changes or perform any number of git - operations until the commits are in good order for pushing upstream - or for pull requests. - After a push or pull, commits are normally considered - "permanent" and you should not modify them. - If they need to be changed you can incrementally do so with new commits. - These practices follow the standard "git" workflow and the kernel.org best - practices, which Yocto Project recommends. - </para> - - <note><para> - It is recommended to tag or branch before adding changes to a Yocto Project - BSP or before creating a new one. - The reason for this recommendation is because the branch or tag provides a - reference point to facilitate locating and exporting local changes. - </para></note> - - <section id='export-internally-via-patches'> - <title>Exporting Changes Internally by Using Patches</title> - - <para> - This section describes how you can extract committed changes from a working directory - by exporting them as patches. - Once extracted, you can use the patches for upstream submission, - place them in a Yocto Project template for automatic kernel patching, - or apply them in many other common uses. - </para> - - <para> - This example shows how to create a directory with sequentially numbered patches. - Once the directory is created, you can apply it to a repository using the - <filename>git am</filename> command to reproduce the original commit and all - the related information such as author, date, commit log, and so forth. - </para> - - <note><para> - The new commit identifiers (ID) will be generated upon re-application. - This action reflects that the commit is now applied to an underlying commit - with a different ID. - </para></note> - - <para> - <literallayout class='monospaced'> - # <first-commit> can be a tag if one was created before development - # began. It can also be the parent branch if a branch was created - # before development began. - - > git format-patch -o <dir> <first commit>..<last commit> - </literallayout> - </para> - - <para> - In other words: - <literallayout class='monospaced'> - # Identify commits of interest. - - # If the tree was tagged before development - > git format-patch -o <save dir> <tag> - - # If no tags are available - > git format-patch -o <save dir> HEAD^ # last commit - > git format-patch -o <save dir> HEAD^^ # last 2 commits - > git whatchanged # identify last commit - > git format-patch -o <save dir> <commit id> - > git format-patch -o <save dir> <rev-list> - </literallayout> - </para> - - <!--<para> - See the "template patching" example for how to use the patches to - automatically apply to a new kernel build. - </para>--> - </section> - - <section id='export-internally-via-git'> - <title>Exporting Changes Internally by Using git</title> - - <para> - This section describes how you can export changes from a working directory - by pushing the changes into a master repository or by making a pull request. - Once you have pushed the changes in the master repository you can then - pull those same changes into a new kernel build at a later time. - </para> - - <para> - Use this command form to push the changes: - <literallayout class='monospaced'> - git push ssh://<master server>/<path to repo> <local branch>:<remote branch> - </literallayout> - </para> - - <para> - For example, the following command pushes the changes from your local branch - <filename>common_pc-standard</filename> to the remote branch with the same name - in the master repository <filename>//git.mycompany.com/pub/git/kernel-2.6.27</filename>. - <literallayout class='monospaced'> - > push ssh://git.mycompany.com/pub/git/kernel-2.6.27 common_pc-standard:common_pc-standard - </literallayout> - </para> - - <para> - A pull request entails using "git request-pull" to compose an email to the - maintainer requesting that a branch be pulled into the master repository, see - <ulink url='http://github.com/guides/pull-requests'></ulink> for an example. - </para> - - <note><para> - Other commands such as 'git stash' or branching can also be used to save - changes, but are not |