Autogenerated HTML docs for v1.8.1.2-545-g2f19ad

1 files changed, 78 insertions, 78 deletions

diff --git a/gitcore-tutorial.html b/gitcore-tutorial.html
index 0e91956ae..b5f28baf8 100644
--- a/gitcore-tutorial.html
+++ b/gitcore-tutorial.html
@@ -737,7 +737,7 @@ gitcore-tutorial(7) Manual Page
 <h2>NAME</h2>

 <div class="sectionbody">

 <p>gitcore-tutorial -

-   A git core tutorial for developers

+   A Git core tutorial for developers

 </p>

 </div>

 </div>

@@ -751,14 +751,14 @@ gitcore-tutorial(7) Manual Page
 <div class="sect1">

 <h2 id="_description">DESCRIPTION</h2>

 <div class="sectionbody">

-<div class="paragraph"><p>This tutorial explains how to use the "core" git commands to set up and

-work with a git repository.</p></div>

-<div class="paragraph"><p>If you just need to use git as a revision control system you may prefer

-to start with "A Tutorial Introduction to GIT" (<a href="gittutorial.html">gittutorial(7)</a>) or

-<a href="user-manual.html">the GIT User Manual</a>.</p></div>

+<div class="paragraph"><p>This tutorial explains how to use the "core" Git commands to set up and

+work with a Git repository.</p></div>

+<div class="paragraph"><p>If you just need to use Git as a revision control system you may prefer

+to start with "A Tutorial Introduction to Git" (<a href="gittutorial.html">gittutorial(7)</a>) or

+<a href="user-manual.html">the Git User Manual</a>.</p></div>

 <div class="paragraph"><p>However, an understanding of these low-level tools can be helpful if

-you want to understand git&#8217;s internals.</p></div>

-<div class="paragraph"><p>The core git is often called "plumbing", with the prettier user

+you want to understand Git&#8217;s internals.</p></div>

+<div class="paragraph"><p>The core Git is often called "plumbing", with the prettier user

 interfaces on top of it called "porcelain". You may not want to use the

 plumbing directly very often, but it can be good to know what the

 plumbing does for when the porcelain isn&#8217;t flushing.</p></div>

@@ -781,29 +781,29 @@ skip on your first reading.</td>
 </div>

 </div>

 <div class="sect1">

-<h2 id="_creating_a_git_repository">Creating a git repository</h2>

+<h2 id="_creating_a_git_repository">Creating a Git repository</h2>

 <div class="sectionbody">

-<div class="paragraph"><p>Creating a new git repository couldn&#8217;t be easier: all git repositories start

+<div class="paragraph"><p>Creating a new Git repository couldn&#8217;t be easier: all Git repositories start

 out empty, and the only thing you need to do is find yourself a

 subdirectory that you want to use as a working tree - either an empty

 one for a totally new project, or an existing working tree that you want

-to import into git.</p></div>

+to import into Git.</p></div>

 <div class="paragraph"><p>For our first example, we&#8217;re going to start a totally new repository from

 scratch, with no pre-existing files, and we&#8217;ll call it <em>git-tutorial</em>.

 To start up, create a subdirectory for it, change into that

-subdirectory, and initialize the git infrastructure with <em>git init</em>:</p></div>

+subdirectory, and initialize the Git infrastructure with <em>git init</em>:</p></div>

 <div class="listingblock">

 <div class="content">

 <pre><code>$ mkdir git-tutorial

 $ cd git-tutorial

 $ git init</code></pre>

 </div></div>

-<div class="paragraph"><p>to which git will reply</p></div>

+<div class="paragraph"><p>to which Git will reply</p></div>

 <div class="listingblock">

 <div class="content">

 <pre><code>Initialized empty Git repository in .git/</code></pre>

 </div></div>

-<div class="paragraph"><p>which is just git&#8217;s way of saying that you haven&#8217;t been doing anything

+<div class="paragraph"><p>which is just Git&#8217;s way of saying that you haven&#8217;t been doing anything

 strange, and that it will have created a local <code>.git</code> directory setup for

 your new project. You will now have a <code>.git</code> directory, and you can

 inspect that with <em>ls</em>. For your new empty project, it should show you

@@ -846,7 +846,7 @@ point to the branch you are working on right now, and you always
 start out expecting to work on the <code>master</code> branch.</p></div>

 <div class="paragraph"><p>However, this is only a convention, and you can name your branches

 anything you want, and don&#8217;t have to ever even <em>have</em> a <code>master</code>

-branch. A number of the git tools will assume that <code>.git/HEAD</code> is

+branch. A number of the Git tools will assume that <code>.git/HEAD</code> is

 valid, though.</p></div>

 <div class="admonitionblock">

 <table><tr>

@@ -872,17 +872,17 @@ populating your tree.</td>
 after finishing this tutorial.</td>

 </tr></table>

 </div>

-<div class="paragraph"><p>You have now created your first git repository. Of course, since it&#8217;s

+<div class="paragraph"><p>You have now created your first Git repository. Of course, since it&#8217;s

 empty, that&#8217;s not very useful, so let&#8217;s start populating it with data.</p></div>

 </div>

 </div>

 <div class="sect1">

-<h2 id="_populating_a_git_repository">Populating a git repository</h2>

+<h2 id="_populating_a_git_repository">Populating a Git repository</h2>

 <div class="sectionbody">

 <div class="paragraph"><p>We&#8217;ll keep this simple and stupid, so we&#8217;ll start off with populating a

 few trivial files just to get a feel for it.</p></div>

 <div class="paragraph"><p>Start off with just creating any random files that you want to maintain

-in your git repository. We&#8217;ll start off with a few bad examples, just to

+in your Git repository. We&#8217;ll start off with a few bad examples, just to

 get a feel for how this works:</p></div>

 <div class="listingblock">

 <div class="content">

@@ -904,7 +904,7 @@ commit that index file as an object.
 </p>

 </li>

 </ul></div>

-<div class="paragraph"><p>The first step is trivial: when you want to tell git about any changes

+<div class="paragraph"><p>The first step is trivial: when you want to tell Git about any changes

 to your working tree, you use the <em>git update-index</em> program. That

 program normally just takes a list of filenames you want to update, but

 to avoid trivial mistakes, it refuses to add new entries to the index

@@ -916,9 +916,9 @@ adding a new entry with the <code>--add</code> flag (or removing an entry with t
 <div class="content">

 <pre><code>$ git update-index --add hello example</code></pre>

 </div></div>

-<div class="paragraph"><p>and you have now told git to track those two files.</p></div>

+<div class="paragraph"><p>and you have now told Git to track those two files.</p></div>

 <div class="paragraph"><p>In fact, as you did that, if you now look into your object directory,

-you&#8217;ll notice that git will have added two new objects to the object

+you&#8217;ll notice that Git will have added two new objects to the object

 database. If you did exactly the steps above, you should now be able to do</p></div>

 <div class="listingblock">

 <div class="content">

@@ -939,7 +939,7 @@ you&#8217;ll have to use the object name, not the filename of the object:</p></d
 <pre><code>$ git cat-file -t 557db03de997c86a4a028e1ebd3a1ceb225be238</code></pre>

 </div></div>

 <div class="paragraph"><p>where the <code>-t</code> tells <em>git cat-file</em> to tell you what the "type" of the

-object is. git will tell you that you have a "blob" object (i.e., just a

+object is. Git will tell you that you have a "blob" object (i.e., just a

 regular file), and you can see the contents with</p></div>

 <div class="listingblock">

 <div class="content">

@@ -972,24 +972,24 @@ hexadecimal digits in most places.</td>
 look at the objects themselves, and typing long 40-character hex

 names is not something you&#8217;d normally want to do. The above digression

 was just to show that <em>git update-index</em> did something magical, and

-actually saved away the contents of your files into the git object

+actually saved away the contents of your files into the Git object

 database.</p></div>

 <div class="paragraph"><p>Updating the index did something else too: it created a <code>.git/index</code>

 file. This is the index that describes your current working tree, and

 something you should be very aware of. Again, you normally never worry

 about the index file itself, but you should be aware of the fact that

-you have not actually really "checked in" your files into git so far,

-you&#8217;ve only <strong>told</strong> git about them.</p></div>

-<div class="paragraph"><p>However, since git knows about them, you can now start using some of the

-most basic git commands to manipulate the files or look at their status.</p></div>

-<div class="paragraph"><p>In particular, let&#8217;s not even check in the two files into git yet, we&#8217;ll

+you have not actually really "checked in" your files into Git so far,

+you&#8217;ve only <strong>told</strong> Git about them.</p></div>

+<div class="paragraph"><p>However, since Git knows about them, you can now start using some of the

+most basic Git commands to manipulate the files or look at their status.</p></div>

+<div class="paragraph"><p>In particular, let&#8217;s not even check in the two files into Git yet, we&#8217;ll

 start off by adding another line to <code>hello</code> first:</p></div>

 <div class="listingblock">

 <div class="content">

 <pre><code>$ echo "It's a new day for git" &gt;&gt;hello</code></pre>

 </div></div>

-<div class="paragraph"><p>and you can now, since you told git about the previous state of <code>hello</code>, ask

-git what has changed in the tree compared to your old index, using the

+<div class="paragraph"><p>and you can now, since you told Git about the previous state of <code>hello</code>, ask

+Git what has changed in the tree compared to your old index, using the

 <em>git diff-files</em> command:</p></div>

 <div class="listingblock">

 <div class="content">

@@ -1032,10 +1032,10 @@ index 557db03..263414f 100644
 </div>

 </div>

 <div class="sect1">

-<h2 id="_committing_git_state">Committing git state</h2>

+<h2 id="_committing_git_state">Committing Git state</h2>

 <div class="sectionbody">

-<div class="paragraph"><p>Now, we want to go to the next stage in git, which is to take the files

-that git knows about in the index, and commit them as a real tree. We do

+<div class="paragraph"><p>Now, we want to go to the next stage in Git, which is to take the files

+that Git knows about in the index, and commit them as a real tree. We do

 that in two phases: creating a <em>tree</em> object, and committing that <em>tree</em>

 object as a <em>commit</em> object together with an explanation of what the

 tree was all about, along with information of how we came to that state.</p></div>

@@ -1044,7 +1044,7 @@ There are no options or other input: <code>git write-tree</code> will take the
 current index state, and write an object that describes that whole

 index. In other words, we&#8217;re now tying together all the different

 filenames with their contents (and their permissions), and we&#8217;re

-creating the equivalent of a git "directory" object:</p></div>

+creating the equivalent of a Git "directory" object:</p></div>

 <div class="listingblock">

 <div class="content">

 <pre><code>$ git write-tree</code></pre>

@@ -1150,9 +1150,9 @@ files to compare (the "meta-data") <strong>always</strong> comes from the index
 regardless of whether the <code>--cached</code> flag is used or not. The <code>--cached</code>

 flag really only determines whether the file <strong>contents</strong> to be compared

 come from the working tree or not.</p></div>

-<div class="paragraph"><p>This is not hard to understand, as soon as you realize that git simply

+<div class="paragraph"><p>This is not hard to understand, as soon as you realize that Git simply

 never knows (or cares) about files that it is not told about

-explicitly. git will never go <strong>looking</strong> for files to compare, it

+explicitly. Git will never go <strong>looking</strong> for files to compare, it

 expects you to tell it what the files are, and that&#8217;s what the index

 is there for.</p></div>

 </td>

@@ -1168,7 +1168,7 @@ update the index cache:</p></div>
 <div class="content">

 <pre><code>$ git update-index hello</code></pre>

 </div></div>

-<div class="paragraph"><p>(note how we didn&#8217;t need the <code>--add</code> flag this time, since git knew

+<div class="paragraph"><p>(note how we didn&#8217;t need the <code>--add</code> flag this time, since Git knew

 about the file already).</p></div>

 <div class="paragraph"><p>Note what happens to the different <em>git diff-&#42;</em> versions here.

 After we&#8217;ve updated <code>hello</code> in the index, <code>git diff-files -p</code> now shows no

@@ -1194,7 +1194,7 @@ the change. If you decide you don&#8217;t want to commit anything after all at
 this point (you can continue to edit things and update the index), you

 can just leave an empty message. Otherwise <code>git commit</code> will commit

 the change for you.</p></div>

-<div class="paragraph"><p>You&#8217;ve now made your first real git commit. And if you&#8217;re interested in

+<div class="paragraph"><p>You&#8217;ve now made your first real Git commit. And if you&#8217;re interested in

 looking at what <code>git commit</code> really does, feel free to investigate:

 it&#8217;s a few very simple shell scripts to generate the helpful (?) commit

 message headers, and a few one-liners that actually do the

@@ -1268,7 +1268,7 @@ all, but just show the actual commit message.</p></div>
 <div class="paragraph"><p>In fact, together with the <em>git rev-list</em> program (which generates a

 list of revisions), <em>git diff-tree</em> ends up being a veritable fount of

 changes. A trivial (but very useful) script called <em>git whatchanged</em> is

-included with git which does exactly this, and shows a log of recent

+included with Git which does exactly this, and shows a log of recent

 activities.</p></div>

 <div class="paragraph"><p>To see the whole history of our pitiful little git-tutorial project, you

 can do</p></div>

@@ -1297,7 +1297,7 @@ can still show it for each command just adding the <code>--root</code> option,
 which is a flag for <em>git diff-tree</em> accepted by both commands.</td>

 </tr></table>

 </div>

-<div class="paragraph"><p>With that, you should now be having some inkling of what git does, and

+<div class="paragraph"><p>With that, you should now be having some inkling of what Git does, and

 can explore on your own.</p></div>

 <div class="admonitionblock">

 <table><tr>

@@ -1305,7 +1305,7 @@ can explore on your own.</p></div>
 <div class="title">Note</div>

 </td>

 <td class="content">Most likely, you are not directly using the core

-git Plumbing commands, but using Porcelain such as <em>git add</em>, &#8216;git-rm&#8217;

+Git Plumbing commands, but using Porcelain such as <em>git add</em>, &#8216;git-rm&#8217;

 and &#8216;git-commit&#8217;.</td>

 </tr></table>

 </div>

@@ -1314,7 +1314,7 @@ and &#8216;git-commit&#8217;.</td>
 <div class="sect1">

 <h2 id="_tagging_a_version">Tagging a version</h2>

 <div class="sectionbody">

-<div class="paragraph"><p>In git, there are two kinds of tags, a "light" one, and an "annotated tag".</p></div>

+<div class="paragraph"><p>In Git, there are two kinds of tags, a "light" one, and an "annotated tag".</p></div>

 <div class="paragraph"><p>A "light" tag is technically nothing more than a branch, except we put

 it in the <code>.git/refs/tags/</code> subdirectory instead of calling it a <code>head</code>.

 So the simplest form of tag involves nothing more than</p></div>

@@ -1333,7 +1333,7 @@ particular state. You can, for example, do</p></div>
 obviously be an empty diff, but if you continue to develop and commit

 stuff, you can use your tag as an "anchor-point" to see what has changed

 since you tagged it.</p></div>

-<div class="paragraph"><p>An "annotated tag" is actually a real git object, and contains not only a

+<div class="paragraph"><p>An "annotated tag" is actually a real Git object, and contains not only a

 pointer to the state you want to tag, but also a small tag name and

 message, along with optionally a PGP signature that says that yes,

 you really did

@@ -1356,20 +1356,20 @@ name for the state at that point.</p></div>
 <div class="sect1">

 <h2 id="_copying_repositories">Copying repositories</h2>

 <div class="sectionbody">

-<div class="paragraph"><p>git repositories are normally totally self-sufficient and relocatable.

+<div class="paragraph"><p>Git repositories are normally totally self-sufficient and relocatable.

 Unlike CVS, for example, there is no separate notion of

-"repository" and "working tree". A git repository normally <strong>is</strong> the

-working tree, with the local git information hidden in the <code>.git</code>

+"repository" and "working tree". A Git repository normally <strong>is</strong> the

+working tree, with the local Git information hidden in the <code>.git</code>

 subdirectory. There is nothing else. What you see is what you got.</p></div>

 <div class="admonitionblock">

 <table><tr>

 <td class="icon">

 <div class="title">Note</div>

 </td>

-<td class="content">You can tell git to split the git internal information from

+<td class="content">You can tell Git to split the Git internal information from

 the directory that it tracks, but we&#8217;ll ignore that for now: it&#8217;s not

 how normal projects work, and it&#8217;s really only meant for special uses.

-So the mental model of "the git information is always tied directly to

+So the mental model of "the Git information is always tied directly to

 the working tree that it describes" may not be technically 100%

 accurate, but it&#8217;s a good model for all normal use.</td>

 </tr></table>

@@ -1390,13 +1390,13 @@ history outside the project you created.</p></div>
 </li>

 <li>

 <p>

-if you want to move or duplicate a git repository, you can do so. There

+if you want to move or duplicate a Git repository, you can do so. There

    is <em>git clone</em> command, but if all you want to do is just to

    create a copy of your repository (with all the full history that

    went along with it), you can do so with a regular

    <code>cp -a git-tutorial new-git-tutorial</code>.

 </p>

-<div class="paragraph"><p>Note that when you&#8217;ve moved or copied a git repository, your git index

+<div class="paragraph"><p>Note that when you&#8217;ve moved or copied a Git repository, your Git index

 file (which caches various information, notably some of the "stat"

 information for the files involved) will likely need to be refreshed.

 So after you do a <code>cp -a</code> to create a new copy, you&#8217;ll want to do</p></div>

@@ -1408,7 +1408,7 @@ So after you do a <code>cp -a</code> to create a new copy, you&#8217;ll want to
 </li>

 </ul></div>

 <div class="paragraph"><p>Note that the second point is true even across machines. You can

-duplicate a remote git repository with <strong>any</strong> regular copy mechanism, be it

+duplicate a remote Git repository with <strong>any</strong> regular copy mechanism, be it

 <em>scp</em>, <em>rsync</em> or <em>wget</em>.</p></div>

 <div class="paragraph"><p>When copying a remote repository, you&#8217;ll want to at a minimum update the

 index cache when you do this, and especially with other peoples'

@@ -1431,21 +1431,21 @@ tells you they need to be updated.</p></div>
 <div class="content">

 <pre><code>$ git reset</code></pre>

 </div></div>

-<div class="paragraph"><p>and in fact a lot of the common git command combinations can be scripted

+<div class="paragraph"><p>and in fact a lot of the common Git command combinations can be scripted

 with the <code>git xyz</code> interfaces.  You can learn things by just looking

 at what the various git scripts do.  For example, <code>git reset</code> used to be

 the above two lines implemented in <em>git reset</em>, but some things like

 <em>git status</em> and <em>git commit</em> are slightly more complex scripts around

-the basic git commands.</p></div>

+the basic Git commands.</p></div>

 <div class="paragraph"><p>Many (most?) public remote repositories will not contain any of

 the checked out files or even an index file, and will <strong>only</strong> contain the

-actual core git files. Such a repository usually doesn&#8217;t even have the

-<code>.git</code> subdirectory, but has all the git files directly in the

+actual core Git files. Such a repository usually doesn&#8217;t even have the

+<code>.git</code> subdirectory, but has all the Git files directly in the

 repository.</p></div>

-<div class="paragraph"><p>To create your own local live copy of such a "raw" git repository, you&#8217;d

+<div class="paragraph"><p>To create your own local live copy of such a "raw" Git repository, you&#8217;d

 first create your own subdirectory for the project, and then copy the

 raw repository contents into the <code>.git</code> directory. For example, to

-create your own copy of the git repository, you&#8217;d do the following</p></div>

+create your own copy of the Git repository, you&#8217;d do the following</p></div>

 <div class="listingblock">

 <div class="content">

 <pre><code>$ mkdir my-git

@@ -1458,7 +1458,7 @@ $ rsync -rL rsync://rsync.kernel.org/pub/scm/git/git.git/ .git</code></pre>
 <pre><code>$ git read-tree HEAD</code></pre>

 </div></div>

 <div class="paragraph"><p>to populate the index. However, now you have populated the index, and

-you have all the git internal files, but you will notice that you don&#8217;t

+you have all the Git internal files, but you will notice that you don&#8217;t

 actually have any of the working tree files to work on. To get

 those, you&#8217;d check them out with</p></div>

 <div class="listingblock">

@@ -1486,7 +1486,7 @@ repository, and checked it out.</p></div>
 <div class="sect1">

 <h2 id="_creating_a_new_branch">Creating a new branch</h2>

 <div class="sectionbody">

-<div class="paragraph"><p>Branches in git are really nothing more than pointers into the git

+<div class="paragraph"><p>Branches in Git are really nothing more than pointers into the Git

 object database from within the <code>.git/refs/</code> subdirectory, and as we

 already discussed, the <code>HEAD</code> branch is nothing but a symlink to one of

 these object pointers.</p></div>

@@ -1572,7 +1572,7 @@ $ git commit -m "Some work." -i hello</code></pre>
 <div class="paragraph"><p>Here, we just added another line to <code>hello</code>, and we used a shorthand for

 doing both <code>git update-index hello</code> and <code>git commit</code> by just giving the

 filename directly to <code>git commit</code>, with an <code>-i</code> flag (it tells

-git to <em>include</em> that file in addition to what you have done to

+Git to <em>include</em> that file in addition to what you have done to

 the index file so far when making the commit).  The <code>-m</code> flag is to give the

 commit log message from the command line.</p></div>

 <div class="paragraph"><p>Now, to make it a bit more interesting, let&#8217;s assume that somebody else

@@ -1615,7 +1615,7 @@ to resolve and what the merge is all about:</p></div>
 <div class="paragraph"><p>where the first argument is going to be used as the commit message if

 the merge can be resolved automatically.</p></div>

 <div class="paragraph"><p>Now, in this case we&#8217;ve intentionally created a situation where the

-merge will need to be fixed up by hand, though, so git will do as much

+merge will need to be fixed up by hand, though, so Git will do as much

 of it as it can automatically (which in this case is just merge the <code>example</code>

 file, which had no differences in the <code>mybranch</code> branch), and say:</p></div>

 <div class="listingblock">

@@ -1649,7 +1649,7 @@ message about your adventures in <em>git merge</em>-land.</p></div>
 history looks like. Notice that <code>mybranch</code> still exists, and you can

 switch to it, and continue to work with it if you want to. The

 <code>mybranch</code> branch will not contain the merge, but next time you merge it

-from the <code>master</code> branch, git will know how you merged it, so you&#8217;ll not

+from the <code>master</code> branch, Git will know how you merged it, so you&#8217;ll not

 have to do <em>that</em> merge again.</p></div>

 <div class="paragraph"><p>Another useful tool, especially if you do not always work in X-Window

 environment, is <code>git show-branch</code>.</p></div>

@@ -1742,7 +1742,7 @@ looks like, or run <em>show-branch</em>, which tells you this.</p></div>
 <h2 id="_merging_external_work">Merging external work</h2>

 <div class="sectionbody">

 <div class="paragraph"><p>It&#8217;s usually much more common that you merge with somebody else than

-merging with your own branches, so it&#8217;s worth pointing out that git

+merging with your own branches, so it&#8217;s worth pointing out that Git

 makes that very easy too, and in fact, it&#8217;s not that different from

 doing a <em>git merge</em>. In fact, a remote merge ends up being nothing

 more than "fetch the work from a remote repository into a temporary tag"

@@ -1787,7 +1787,7 @@ and requires you to have a log-in privilege over <code>ssh</code> to the
 remote machine.  It finds out the set of objects the other side

 lacks by exchanging the head commits both ends have and

 transfers (close to) minimum set of objects.  It is by far the

-most efficient way to exchange git objects between repositories.</p></div>

+most efficient way to exchange Git objects between repositories.</p></div>

 </dd>

 <dt class="hdlist1">

 Local directory

@@ -1801,7 +1801,7 @@ both ends on the local machine instead of running other end on
 the remote machine via <em>ssh</em>.</p></div>

 </dd>

 <dt class="hdlist1">

-git Native

+Git Native

 </dt>

 <dd>

 <p>

@@ -1829,8 +1829,8 @@ tree object; it repeats this process until it gets all the
 necessary objects.  Because of this behavior, they are

 sometimes also called <em>commit walkers</em>.</p></div>

 <div class="paragraph"><p>The <em>commit walkers</em> are sometimes also called <em>dumb

-transports</em>, because they do not require any git aware smart

-server like git Native transport does.  Any stock HTTP server

+transports</em>, because they do not require any Git aware smart

+server like Git Native transport does.  Any stock HTTP server

 that does not even support directory index would suffice.  But

 you must prepare your repository with <em>git update-server-info</em>

 to help dumb transport downloaders.</p></div>

@@ -2057,7 +2057,7 @@ update the public repository from it. This is often called
 <div class="title">Note</div>

 </td>

 <td class="content">This public repository could further be mirrored, and that is

-how git repositories at <code>kernel.org</code> are managed.</td>

+how Git repositories at <code>kernel.org</code> are managed.</td>

 </tr></table>

 </div>

 <div class="paragraph"><p>Publishing the changes from your local (private) repository to

@@ -2080,7 +2080,7 @@ on the remote machine. The communication between the two over
 the network internally uses an SSH connection.</td>

 </tr></table>

 </div>

-<div class="paragraph"><p>Your private repository&#8217;s git directory is usually <code>.git</code>, but

+<div class="paragraph"><p>Your private repository&#8217;s Git directory is usually <code>.git</code>, but

 your public repository is often named after the project name,

 i.e. <code>&lt;project&gt;.git</code>. Let&#8217;s create such a public repository for

 project <code>my-git</code>. After logging into the remote machine, create

@@ -2089,7 +2089,7 @@ an empty directory:</p></div>
 <div class="content">

 <pre><code>$ mkdir my-git.git</code></pre>

 </div></div>

-<div class="paragraph"><p>Then, make that directory into a git repository by running

+<div class="paragraph"><p>Then, make that directory into a Git repository by running

 <em>git init</em>, but this time, since its name is not the usual

 <code>.git</code>, we do things slightly differently:</p></div>

 <div class="listingblock">

@@ -2134,7 +2134,7 @@ there, run this command:</p></div>
 <div class="paragraph"><p>This synchronizes your public repository to match the named

 branch head (i.e. <code>master</code> in this case) and objects reachable

 from them in your current repository.</p></div>

-<div class="paragraph"><p>As a real example, this is how I update my public git

+<div class="paragraph"><p>As a real example, this is how I update my public Git

 repository. Kernel.org mirror network takes care of the

 propagation to other publicly visible machines:</p></div>

 <div class="listingblock">

@@ -2147,9 +2147,9 @@ propagation to other publicly visible machines:</p></div>
 <h2 id="_packing_your_repository">Packing your repository</h2>

 <div class="sectionbody">

 <div class="paragraph"><p>Earlier, we saw that one file under <code>.git/objects/??/</code> directory

-is stored for each git object you create. This representation

+is stored for each Git object you create. This representation

 is efficient to create atomically and safely, but

-not so convenient to transport over the network. Since git objects are

+not so convenient to transport over the network. Since Git objects are

 immutable once they are created, there is a way to optimize the

 storage by "packing them together". The command</p></div>

 <div class="listingblock">

@@ -2220,13 +2220,13 @@ repositories every once in a while.</p></div>
 <div class="sect1">

 <h2 id="_working_with_others">Working with Others</h2>

 <div class="sectionbody">

-<div class="paragraph"><p>Although git is a truly distributed system, it is often

+<div class="paragraph"><p>Although Git is a truly distributed system, it is often

 convenient to organize your project with an informal hierarchy

 of developers. Linux kernel development is run this way. There

 is a nice illustration (page 17, "Merges to Mainline") in

 <a href="http://www.xenotime.net/linux/mentor/linux-mentoring-2006.pdf">Randy Dunlap&#8217;s presentation</a>.</p></div>

 <div class="paragraph"><p>It should be stressed that this hierarchy is purely <strong>informal</strong>.

-There is nothing fundamental in git that enforces the "chain of

+There is nothing fundamental in Git that enforces the "chain of

 patch flow" this hierarchy implies. You do not have to pull

 from only one remote repository.</p></div>

 <div class="paragraph"><p>A recommended workflow for a "project lead" goes like this:</p></div>

@@ -2394,7 +2394,7 @@ Use <code>git format-patch origin</code> to prepare patches for e-mail
 <div class="sectionbody">

 <div class="paragraph"><p>If you are coming from CVS background, the style of cooperation

 suggested in the previous section may be new to you. You do not

-have to worry. git supports "shared public repository" style of

+have to worry. Git supports "shared public repository" style of

 cooperation you are probably more familiar with as well.</p></div>

 <div class="paragraph"><p>See <a href="gitcvs-migration.html">gitcvs-migration(7)</a> for the details.</p></div>

 </div>

@@ -2404,7 +2404,7 @@ cooperation you are probably more familiar with as well.</p></div>
 <div class="sectionbody">

 <div class="paragraph"><p>It is likely that you will be working on more than one thing at

 a time.  It is easy to manage those more-or-less independent tasks

-using branches with git.</p></div>

+using branches with Git.</p></div>

 <div class="paragraph"><p>We have already seen how branches work previously,

 with "fun and work" example using two branches.  The idea is the

 same if there are more than two branches.  Let&#8217;s say you started

@@ -2512,7 +2512,7 @@ to follow, not easier.</p></div>
 <div id="footnotes"><hr /></div>

 <div id="footer">

 <div id="footer-text">

-Last updated 2012-09-17 16:55:59 PDT

+Last updated 2013-02-05 21:07:26 PST

 </div>

 </div>

 </body>