sysmo-bts
/
generic-poky
9
0
Fork 0
Code Pull Requests Releases Activity

dev-manual: Updated wording about Git 

I removed the statement saying that checking out a Git repository
is a backup of the repo.  Technically, that is not true.  It would
be more of a clone operation.  The statement was superfluous anyway
so I decided to remove it altogether.

Reported-by: Trevor Woerner <twoerner@gmail.com>
(From yocto-docs rev: 081bd0119f8c17a3932485857b6846dcb6998ee1)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark 2013-05-28 08:40:40 +03:00 committed by Richard Purdie
parent 00c3a84272
commit e230049198
1 changed files with 54 additions and 54 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

108
documentation/dev-manual/dev-manual-newbie.xml
View File

@ -12,9 +12,9 @@
closed, proprietary environment.
Additionally, the Yocto Project uses specific tools and constructs as part of its development
environment.
This chapter specifically addresses open source philosophy, using the
This chapter specifically addresses open source philosophy, using the
Yocto Project in a team environment, source repositories, Yocto Project
terms, licensing, the open source distributed version control system Git,
terms, licensing, the open source distributed version control system Git,
workflows, bug tracking, and how to submit changes.
</para>
@ -190,15 +190,15 @@
extensive testing while they continue to develop
locally using their primary development system.
</para></listitem>
<listitem><para>Enable the PR Service when package feeds
need to be incremental with continually increasing
<ulink url='&YOCTO_DOCS_REF_URL;#var-PR'>PR</ulink>
<listitem><para>Enable the PR Service when package feeds
need to be incremental with continually increasing
<ulink url='&YOCTO_DOCS_REF_URL;#var-PR'>PR</ulink>
values.
Typically, this situation occurs when you use or
Typically, this situation occurs when you use or
publish package feeds and use a shared state.
You should enable the PR Service for all users who
use the shared state pool.
For more information on the PR Service, see the
For more information on the PR Service, see the
"<link linkend='working-with-a-pr-service'>Working With a PR Service</link>".
</para></listitem>
</itemizedlist>
@ -218,9 +218,9 @@
Of the SCMs BitBake supports, the
Yocto Project team strongly recommends using
<link linkend='git'>Git</link>.
Git is a distributed system that is easy to backup
(each checkout is a backup in itself), allows you to work
remotely, and then connects back to the infrastructure.
Git is a distributed system that is easy to backup,
allows you to work remotely, and then connects back to the
infrastructure.
<note>
For information about BitBake and SCMs, see the
BitBake manual located in the
@ -428,8 +428,8 @@
</para>
<para>
For any supported release of Yocto Project, you can go to the
<ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink> and
For any supported release of Yocto Project, you can go to the
<ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink> and
select the "Downloads" tab and get a tarball of the release.
You can also go to this site to download any supported BSP tarballs.
Unpacking the tarball gives you a hierarchical Source Directory that lets you develop
@ -461,7 +461,7 @@
<para>
<imagedata fileref="figures/index-downloads.png" align="center" width="6in" depth="3.5in" />
</para></listitem>
<listitem><para><emphasis>"Downloads" page for the
<listitem><para><emphasis>"Downloads" page for the
<ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink>:</emphasis>
Access this page by going to the website and then selecting
the "Downloads" tab.
@ -489,7 +489,7 @@
Append files are known as BitBake append files and <filename>.bbappend</filename> files.
The OpenEmbedded build system expects every append file to have a corresponding
recipe (<filename>.bb</filename>) file.
Furthermore, the append file and corresponding recipe file
Furthermore, the append file and corresponding recipe file
must use the same root filename.
The filenames can differ only in the file type suffix used (e.g.
<filename>formfactor_0.0.bb</filename> and <filename>formfactor_0.0.bbappend</filename>).
@ -641,7 +641,7 @@
</para></listitem>
<listitem><para id='oe-core'><emphasis>OE-Core:</emphasis> A core set of Metadata originating
with OpenEmbedded (OE) that is shared between OE and the Yocto Project.
This Metadata is found in the <filename>meta</filename> directory of the
This Metadata is found in the <filename>meta</filename> directory of the
<link linkend='source-directory'>Source Directory</link>.</para></listitem>
<listitem><para><emphasis>Package:</emphasis> In the context of the Yocto Project,
this term refers to the packaged output from a baked recipe.
@ -776,7 +776,7 @@
<para>
When you build an image using the Yocto Project, the build process uses a
known list of licenses to ensure compliance.
You can find this list in the
You can find this list in the
<link linkend='source-directory'>Source Directory</link> at
<filename>meta/files/common-licenses</filename>.
Once the build completes, the list of all licenses found and used during that build are
@ -869,7 +869,7 @@
When you clone a Git repository, you end up with an identical copy of the
repository on your development system.
Once you have a local copy of a repository, you can take steps to develop locally.
For examples on how to clone Git repositories, see the
For examples on how to clone Git repositories, see the
"<link linkend='getting-setup'>Getting Set Up</link>" section.
</para>
@ -911,14 +911,14 @@
$ cd poky
$ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
</literallayout>
In this example, the name of the top-level directory of your local
<link linkend='source-directory'>Source Directory</link>
In this example, the name of the top-level directory of your local
<link linkend='source-directory'>Source Directory</link>
is <filename>poky</filename>,
and the name of that local working area (local branch) you just
and the name of that local working area (local branch) you just
created and checked out is <filename>&DISTRO_NAME;</filename>.
The files in your local repository now reflect the same files that
are in the <filename>&DISTRO_NAME;</filename> development
branch of the Yocto Project's <filename>poky</filename>
The files in your local repository now reflect the same files that
are in the <filename>&DISTRO_NAME;</filename> development
branch of the Yocto Project's <filename>poky</filename>
upstream repository.
It is important to understand that when you create and checkout a
local working branch based on a branch name,
@ -1037,10 +1037,10 @@
repository and places it in your local Git repository.
You use this command to make sure you are synchronized with the repository
from which you are basing changes (.e.g. the master branch).</para></listitem>
<listitem><para><emphasis><filename>git push</filename>:</emphasis>
Sends all your committed local changes to an upstream Git
<listitem><para><emphasis><filename>git push</filename>:</emphasis>
Sends all your committed local changes to an upstream Git
repository (e.g. a contribution repository).
The maintainer of the project draws from these repositories
The maintainer of the project draws from these repositories
when adding changes to the project’s master repository or
other development branch.
</para></listitem>
@ -1088,8 +1088,8 @@
The "master" branch is the “upstream” repository where the final builds of the project occur.
The maintainer is responsible for allowing changes in from other developers and for
organizing the underlying branch structure to reflect release strategies and so forth.
<note>For information on finding out who is responsible (maintains)
for a particular area of code, see the
<note>For information on finding out who is responsible (maintains)
for a particular area of code, see the
"<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
section.
</note>
@ -1160,8 +1160,8 @@
You can name these branches anything you like.
It is helpful to give them names associated with the particular feature or change
on which you are working.
Once you are done with a feature or change and have merged it
into your local master branch, simply discard the temporary
Once you are done with a feature or change and have merged it
into your local master branch, simply discard the temporary
branch.</para></listitem>
<listitem><para><emphasis>Merge Changes:</emphasis> The <filename>git merge</filename>
command allows you to take the
@ -1189,9 +1189,9 @@
<filename>send-pull-request</filename> that ship with the release to facilitate this
workflow.
You can find these scripts in the <filename>scripts</filename>
folder of the
folder of the
<link linkend='source-directory'>Source Directory</link>.
For information on how to use these scripts, see the
For information on how to use these scripts, see the
"<link linkend='pushing-a-change-upstream'>Using Scripts to Push a Change Upstream and Request a Pull</link>" section.
</para></listitem>
<listitem><para><emphasis>Patch Workflow:</emphasis> This workflow allows you to notify the
@ -1199,7 +1199,7 @@
for the "master" branch of the Git repository.
To send this type of change, you format the patch and then send the email using the Git commands
<filename>git format-patch</filename> and <filename>git send-email</filename>.
For information on how to use these scripts, see the
For information on how to use these scripts, see the
"<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
section.
</para></listitem>
@ -1251,10 +1251,10 @@
<listitem><para>Provide a detailed description of the issue.
You should provide as much detail as you can about the context, behavior, output,
and so forth that surrounds the issue.
You can even attach supporting files for output from logs by
You can even attach supporting files for output from logs by
using the "Add an attachment" button.</para></listitem>
<listitem><para>Be sure to copy the appropriate people in the
"CC List" for the bug.
<listitem><para>Be sure to copy the appropriate people in the
"CC List" for the bug.
See the "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
section for information about finding out who is responsible
for code.</para></listitem>
@ -1281,37 +1281,37 @@
or notifying:
<itemizedlist>
<listitem><para><emphasis>Maintenance File:</emphasis>
Examine the <filename>maintainers.inc</filename> file, which is
located in the
Examine the <filename>maintainers.inc</filename> file, which is
located in the
<link linkend='source-directory'>Source Directory</link>
at <filename>meta-yocto/conf/distro/include</filename>, to
at <filename>meta-yocto/conf/distro/include</filename>, to
see who is responsible for code.
</para></listitem>
<listitem><para><emphasis>Board Support Package (BSP) README Files:</emphasis>
For BSP maintainers of supported BSPs, you can examine
For BSP maintainers of supported BSPs, you can examine
individual BSP <filename>README</filename> files.
Alternatively, you can examine the
<filename>MAINTAINERS</filename> file, which is found in the
Alternatively, you can examine the
<filename>MAINTAINERS</filename> file, which is found in the
<filename>meta-intel</filename>, for a list of all supported
BSP maintainers.
</para></listitem>
<listitem><para><emphasis>Search by File:</emphasis>
Using <link linkend='git'>Git</link>, you can enter the
following command to bring up a short list of all commits
Using <link linkend='git'>Git</link>, you can enter the
following command to bring up a short list of all commits
against a specific file:
<literallayout class='monospaced'>
git shortlog -- &lt;filename&gt;
</literallayout>
Just provide the name of the file for which you are interested.
The information returned is not ordered by history but does
include a list of all committers grouped by name.
The information returned is not ordered by history but does
include a list of all committers grouped by name.
From the list, you can see who is responsible for the bulk of
the changes against the file.
</para></listitem>
</itemizedlist>
</para>
<para>
<para>
For a list of the Yocto Project and related mailing lists, see the
"<ulink url='&YOCTO_DOCS_REF_URL;#resources-mailinglist'>Mailing lists</ulink>" section in
the Yocto Project Reference Manual.
@ -1320,7 +1320,7 @@
<para>
Here is some guidance on which mailing list to use for what type of change:
<itemizedlist>
<listitem><para>For changes to the core
<listitem><para>For changes to the core
<link linkend='metadata'>Metadata</link>, send your patch to the
<ulink url='&OE_LISTS_URL;/listinfo/openembedded-core'>openembedded-core</ulink> mailing list.
For example, a change to anything under the <filename>meta</filename> or
@ -1435,7 +1435,7 @@
</para>
<para>
The next two sections describe general instructions for both pushing
The next two sections describe general instructions for both pushing
changes upstream and for submitting changes as patches.
</para>
@ -1493,7 +1493,7 @@
Depending on the components changed, you need to submit the email to a specific
mailing list.
For some guidance on which mailing list to use, see the list in the
"<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
"<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
section.
For a description of the available mailing lists, see the
"<ulink url='&YOCTO_DOCS_REF_URL;#resources-mailinglist'>Mailing Lists</ulink>"
@ -1521,8 +1521,8 @@
To format commits, use the <filename>git format-patch</filename> command.
When you provide the command, you must include a revision list or a number of patches
as part of the command.
For example, either of these two commands takes your most
recent single commit and formats it as an email message in
For example, either of these two commands takes your most
recent single commit and formats it as an email message in
the current directory:
<literallayout class='monospaced'>
$ git format-patch -1
@ -1534,7 +1534,7 @@
<para>After the command is run, the current directory contains a
numbered <filename>.patch</filename> file for the commit.</para>
<para>If you provide several commits as part of the command,
the <filename>git format-patch</filename> command produces a
the <filename>git format-patch</filename> command produces a
series of numbered files in the current directory – one for each commit.
If you have more than one patch, you should also use the
<filename>--cover</filename> option with the command, which generates a
@ -1571,7 +1571,7 @@
The command also has several options that let you
specify recipients and perform further editing of the email message.
For information on how to use the <filename>git send-email</filename> command,
see <filename>GIT-SEND-EMAIL(1)</filename> displayed using
see <filename>GIT-SEND-EMAIL(1)</filename> displayed using
the <filename>man git-send-email</filename> command.
</para></listitem>
</itemizedlist>