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>

1 files changed, 54 insertions, 54 deletions

diff --git a/documentation/dev-manual/dev-manual-newbie.xml b/documentation/dev-manual/dev-manual-newbie.xml
index 46b680e6be..779d06d57e 100644
--- a/documentation/dev-manual/dev-manual-newbie.xml
+++ b/documentation/dev-manual/dev-manual-newbie.xml
@@ -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>