Merge pull request #57 from randomecho/pronoun-wash
Remove pronoun I from voice for lack of lone addressor
This commit is contained in:
		@@ -140,8 +140,8 @@ layout: reference
 | 
				
			|||||||
  <div class="block">
 | 
					  <div class="block">
 | 
				
			||||||
    <p>As you saw in the <code>git add</code> section, in order to see what the
 | 
					    <p>As you saw in the <code>git add</code> section, in order to see what the
 | 
				
			||||||
    status of your staging area is compared to the code in your working
 | 
					    status of your staging area is compared to the code in your working
 | 
				
			||||||
    directory, you can run the <code>git status</code> command. I demonstrated
 | 
					    directory, you can run the <code>git status</code> command. Using the
 | 
				
			||||||
    using it with the <code>-s</code> option, which gives you short output.
 | 
					    <code>-s</code> option will give you short output.
 | 
				
			||||||
    Without that flag, the <code>git status</code> command will give you more
 | 
					    Without that flag, the <code>git status</code> command will give you more
 | 
				
			||||||
    context and hints.  Here is the same status output with and without the
 | 
					    context and hints.  Here is the same status output with and without the
 | 
				
			||||||
    <code>-s</code>.  The short output looks like this:
 | 
					    <code>-s</code>.  The short output looks like this:
 | 
				
			||||||
@@ -572,7 +572,7 @@ Further paragraphs come after blank lines.
 | 
				
			|||||||
    <p>Notice how if you don't stage any changes and then run
 | 
					    <p>Notice how if you don't stage any changes and then run
 | 
				
			||||||
    <code>git commit</code>, Git will simply give you the output of the
 | 
					    <code>git commit</code>, Git will simply give you the output of the
 | 
				
			||||||
    <code>git status</code> command, reminding you that nothing is staged.
 | 
					    <code>git status</code> command, reminding you that nothing is staged.
 | 
				
			||||||
    I've highlighted the important part of that message, saying that nothing
 | 
					    The important part of that message has been highlighted, saying that nothing
 | 
				
			||||||
    is added to be committed.   If you use <code>-a</code>, it will add and
 | 
					    is added to be committed.   If you use <code>-a</code>, it will add and
 | 
				
			||||||
    commit everything at once.
 | 
					    commit everything at once.
 | 
				
			||||||
    </p>
 | 
					    </p>
 | 
				
			||||||
@@ -605,11 +605,9 @@ Further paragraphs come after blank lines.
 | 
				
			|||||||
 | 
					
 | 
				
			||||||
  <div class="block">
 | 
					  <div class="block">
 | 
				
			||||||
    <p><code>git reset</code> is probably the most confusing command written
 | 
					    <p><code>git reset</code> is probably the most confusing command written
 | 
				
			||||||
    by humans.  I've been using Git for years, even wrote a book on it and I
 | 
					    by humans, but it can be very useful when you get the hang of it.
 | 
				
			||||||
    still get confused by what it is going to do at times.  So, I'll just
 | 
					    There are three specific invocations of it that are generally
 | 
				
			||||||
    tell you the three specific invocations of it that are generally
 | 
					    helpful.
 | 
				
			||||||
    helpful and ask you to blindly use it as I do - because it can be
 | 
					 | 
				
			||||||
    very useful.
 | 
					 | 
				
			||||||
    </p>
 | 
					    </p>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
    <h4>
 | 
					    <h4>
 | 
				
			||||||
@@ -617,19 +615,19 @@ Further paragraphs come after blank lines.
 | 
				
			|||||||
      <small>undo the last commit and unstage the files</small>
 | 
					      <small>undo the last commit and unstage the files</small>
 | 
				
			||||||
    </h4>
 | 
					    </h4>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
    <p>In the first case, we can use it to unstage something that you have
 | 
					    <p>First, you can use it to unstage something that has been
 | 
				
			||||||
    accidentally staged.  Let's say that you have modified two files and want
 | 
					    accidentally staged.  Let's say that you have modified two files and want
 | 
				
			||||||
    to record them into two different commits.  You should stage and commit
 | 
					    to record them into two different commits.  You should stage and commit
 | 
				
			||||||
    one, then stage and commit the other.  If you accidentally stage both of
 | 
					    one, then stage and commit the other.  If you accidentally stage both of
 | 
				
			||||||
    them, how do you <i>un-</i>stage one?  You do it with
 | 
					    them, how do you <i>un-</i>stage one?  You do it with
 | 
				
			||||||
    <code>git reset HEAD -- file</code>.  Technically here you don't have to
 | 
					    <code>git reset HEAD -- file</code>.  Technically you don't have to
 | 
				
			||||||
    add the <code>--</code> - it is used to tell Git when you have stopped
 | 
					    add the <code>--</code> - it is used to tell Git when you have stopped
 | 
				
			||||||
    listing options and are now listing file paths, but it's probably good to
 | 
					    listing options and are now listing file paths, but it's probably good to
 | 
				
			||||||
    get into the habit of using it to separate options from paths even if you
 | 
					    get into the habit of using it to separate options from paths even if you
 | 
				
			||||||
    don't need to.
 | 
					    don't need to.
 | 
				
			||||||
    </p>
 | 
					    </p>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
    <p>So, let's see what it looks like to unstage something.  Here we have
 | 
					    <p>Let's see what it looks like to unstage something.  Here we have
 | 
				
			||||||
    two files that have been modified since our last commit.  We will stage
 | 
					    two files that have been modified since our last commit.  We will stage
 | 
				
			||||||
    both, then unstage one of them.</p>
 | 
					    both, then unstage one of them.</p>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
@@ -782,7 +780,7 @@ nothing to commit (working directory clean)
 | 
				
			|||||||
 | 
					
 | 
				
			||||||
    <p><code>git rm</code> will remove entries from the staging area.
 | 
					    <p><code>git rm</code> will remove entries from the staging area.
 | 
				
			||||||
    This is a bit different from <code>git reset HEAD</code> which "unstages"
 | 
					    This is a bit different from <code>git reset HEAD</code> which "unstages"
 | 
				
			||||||
    files.  By "unstage" I mean it reverts the staging area to what was
 | 
					    files.  To "unstage" means it reverts the staging area to what was
 | 
				
			||||||
    there before we started modifying things.  <code>git rm</code> on the
 | 
					    there before we started modifying things.  <code>git rm</code> on the
 | 
				
			||||||
    other hand just kicks the file off the stage entirely, so that it's not
 | 
					    other hand just kicks the file off the stage entirely, so that it's not
 | 
				
			||||||
    included in the next commit snapshot, thereby effectively deleting it.</p>
 | 
					    included in the next commit snapshot, thereby effectively deleting it.</p>
 | 
				
			||||||
@@ -810,10 +808,10 @@ nothing to commit (working directory clean)
 | 
				
			|||||||
    </p>
 | 
					    </p>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
    <p class="aside">
 | 
					    <p class="aside">
 | 
				
			||||||
    I personally don't use this command that much in it's normal form - to
 | 
					    In its normal form the command is used to delete files.
 | 
				
			||||||
    delete files.  It's often easier to just remove the files off your disk and
 | 
					    But it's often easier to just remove the files off your disk and
 | 
				
			||||||
    then run a <code>git commit -a</code>, which will automatically remove them
 | 
					    then run <code>git commit -a</code>, which will also automatically remove
 | 
				
			||||||
    from your index, too.</p>
 | 
					    them from your index.</p>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
    <p class="nutshell">
 | 
					    <p class="nutshell">
 | 
				
			||||||
    <strong>In a nutshell</strong>,
 | 
					    <strong>In a nutshell</strong>,
 | 
				
			||||||
 
 | 
				
			|||||||
@@ -10,7 +10,7 @@ layout: reference
 | 
				
			|||||||
    Branching and Merging
 | 
					    Branching and Merging
 | 
				
			||||||
  </h2>
 | 
					  </h2>
 | 
				
			||||||
  <div class="block">
 | 
					  <div class="block">
 | 
				
			||||||
    <p>Branching in Git is one of my favorite features.  If you have used other
 | 
					    <p>Branching in Git is one of its many great features.  If you have used other
 | 
				
			||||||
    version control systems, it's probably helpful to forget most of what you
 | 
					    version control systems, it's probably helpful to forget most of what you
 | 
				
			||||||
    think about branches - in fact, it may be more helpful to think of them
 | 
					    think about branches - in fact, it may be more helpful to think of them
 | 
				
			||||||
    practically as <i>contexts</i> since that is how you will most often be
 | 
					    practically as <i>contexts</i> since that is how you will most often be
 | 
				
			||||||
@@ -319,7 +319,7 @@ HelloWorld.hello
 | 
				
			|||||||
</pre>
 | 
					</pre>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
    <p>So first we're going to create a new branch named 'change_class' and
 | 
					    <p>So first we're going to create a new branch named 'change_class' and
 | 
				
			||||||
    switch to it so your class renaming changes are isolated. I'm going to
 | 
					    switch to it so your class renaming changes are isolated. We're going to
 | 
				
			||||||
    change each instance of 'HelloWorld' to 'HiWorld'.</p>
 | 
					    change each instance of 'HelloWorld' to 'HiWorld'.</p>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
<pre>
 | 
					<pre>
 | 
				
			||||||
@@ -333,9 +333,9 @@ class HiWorld
 | 
				
			|||||||
 1 files changed, 2 insertions(+), 4 deletions(-)
 | 
					 1 files changed, 2 insertions(+), 4 deletions(-)
 | 
				
			||||||
</pre>
 | 
					</pre>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
    <p>So now I've committed the class renaming changes to the 'change_class'
 | 
					    <p>So now we've committed the class renaming changes to the 'change_class'
 | 
				
			||||||
      branch.  If I now switch back to the 'master' branch my class name will
 | 
					      branch.  To switch back to the 'master' branch the class name will
 | 
				
			||||||
      revert to what it was before I switched branches. Here I can change
 | 
					      revert to what it was before we switched branches. Here we can change
 | 
				
			||||||
      something different (in this case the printed output) and at the same
 | 
					      something different (in this case the printed output) and at the same
 | 
				
			||||||
      time rename the file from <code>hello.rb</code> to <code>ruby.rb</code>.
 | 
					      time rename the file from <code>hello.rb</code> to <code>ruby.rb</code>.
 | 
				
			||||||
      </p>
 | 
					      </p>
 | 
				
			||||||
@@ -365,10 +365,10 @@ index 2aabb6e..bf64b17 100644
 | 
				
			|||||||
 rename hello.rb => ruby.rb (65%)
 | 
					 rename hello.rb => ruby.rb (65%)
 | 
				
			||||||
</pre>
 | 
					</pre>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
    <p>Now those changes are recorded in my 'master' branch.  Notice that the
 | 
					    <p>Now those changes are recorded in the 'master' branch.  Notice that the
 | 
				
			||||||
      class name is back to 'HelloWorld', not 'HiWorld'.  Now I want to
 | 
					      class name is back to 'HelloWorld', not 'HiWorld'.  To incorporate
 | 
				
			||||||
      incorporate the 'HiWorld' change so I can just merge in my 'change_class'
 | 
					      the 'HiWorld' change we can just merge in the 'change_class'
 | 
				
			||||||
      branch.  However, I've changed the name of the file since I branched,
 | 
					      branch.  However, the name of the file has changed since we branched,
 | 
				
			||||||
      what will Git do?</p>
 | 
					      what will Git do?</p>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
<pre>
 | 
					<pre>
 | 
				
			||||||
@@ -391,7 +391,7 @@ end
 | 
				
			|||||||
HiWorld.hello
 | 
					HiWorld.hello
 | 
				
			||||||
</pre>
 | 
					</pre>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
    <p>Well, it will just figure it out. Notice that I had no merge conflicts
 | 
					    <p>Well, it will just figure it out. Notice that there are no merge conflicts
 | 
				
			||||||
    and the file that had been renamed now has the 'HiWorld' class name change
 | 
					    and the file that had been renamed now has the 'HiWorld' class name change
 | 
				
			||||||
    that was done in the other branch. Pretty cool.</p>
 | 
					    that was done in the other branch. Pretty cool.</p>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
@@ -474,9 +474,9 @@ index 9103e27,69cad1a..0000000
 | 
				
			|||||||
 | 
					
 | 
				
			||||||
    <p>A cool tip in doing merge conflict resolution in Git is that if you
 | 
					    <p>A cool tip in doing merge conflict resolution in Git is that if you
 | 
				
			||||||
    run <code>git diff</code>, it will show you both sides of the conflict
 | 
					    run <code>git diff</code>, it will show you both sides of the conflict
 | 
				
			||||||
    and how you've resolved it as I've shown here. Now it's time to mark
 | 
					    and how you've resolved it as shown here. Now it's time to mark
 | 
				
			||||||
    the file as resolved.  In Git we do that with <code>git add</code> -
 | 
					    the file as resolved.  In Git we do that with <code>git add</code> -
 | 
				
			||||||
    to tell Git the file has been resolved, you have to stage it.</p>
 | 
					    to tell Git the file has been resolved you have to stage it.</p>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
<pre>
 | 
					<pre>
 | 
				
			||||||
<b>$ git status -s</b>
 | 
					<b>$ git status -s</b>
 | 
				
			||||||
@@ -684,7 +684,7 @@ b7ae93b added from ruby
 | 
				
			|||||||
</pre>
 | 
					</pre>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
    <p>This way, it's pretty easy to see that we have Haskell code included in
 | 
					    <p>This way, it's pretty easy to see that we have Haskell code included in
 | 
				
			||||||
      the branch (as I've highlighted). What is even cooler is that we can
 | 
					      the branch (highlighted in the output). What is even cooler is that we can
 | 
				
			||||||
      easily tell Git that we only are interested in the commits that are
 | 
					      easily tell Git that we only are interested in the commits that are
 | 
				
			||||||
      reachable in one branch that are not reachable in another, in other words
 | 
					      reachable in one branch that are not reachable in another, in other words
 | 
				
			||||||
      which commits are unique to a branch in comparison to another.
 | 
					      which commits are unique to a branch in comparison to another.
 | 
				
			||||||
@@ -751,7 +751,7 @@ ab5ab4c added erlang
 | 
				
			|||||||
    tag", which allows you to add a tag message to it, which is what you almost
 | 
					    tag", which allows you to add a tag message to it, which is what you almost
 | 
				
			||||||
    always want to do.  Running this without the <code>-a</code> works too, but
 | 
					    always want to do.  Running this without the <code>-a</code> works too, but
 | 
				
			||||||
    it doesn't record when it was tagged, who tagged it, or let you add a tag
 | 
					    it doesn't record when it was tagged, who tagged it, or let you add a tag
 | 
				
			||||||
    message. I would recommend always creating annotated tags.</p>
 | 
					    message. It's recommended you always create annotated tags.</p>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
<pre>
 | 
					<pre>
 | 
				
			||||||
<b>$ git tag -a v1.0 </b>
 | 
					<b>$ git tag -a v1.0 </b>
 | 
				
			||||||
 
 | 
				
			|||||||
@@ -5,7 +5,7 @@ layout: reference
 | 
				
			|||||||
  <h2>Introduction to the Git Reference</h2>
 | 
					  <h2>Introduction to the Git Reference</h2>
 | 
				
			||||||
  <div class="block">
 | 
					  <div class="block">
 | 
				
			||||||
    <p>
 | 
					    <p>
 | 
				
			||||||
    This is the Git reference site. This is meant to be a quick
 | 
					    This is the Git reference site. It is meant to be a quick
 | 
				
			||||||
    reference for learning and remembering the most important and
 | 
					    reference for learning and remembering the most important and
 | 
				
			||||||
    commonly used Git commands.  The commands are organized into
 | 
					    commonly used Git commands.  The commands are organized into
 | 
				
			||||||
    sections of the type of operation you may be trying to do, and
 | 
					    sections of the type of operation you may be trying to do, and
 | 
				
			||||||
@@ -28,7 +28,7 @@ layout: reference
 | 
				
			|||||||
  <h2>How to Think Like Git</h2>
 | 
					  <h2>How to Think Like Git</h2>
 | 
				
			||||||
  <div class="block">
 | 
					  <div class="block">
 | 
				
			||||||
    <p>
 | 
					    <p>
 | 
				
			||||||
    The first thing that is important to understand about Git is
 | 
					    The first important thing to understand about Git is
 | 
				
			||||||
    that it thinks about version control very differently than
 | 
					    that it thinks about version control very differently than
 | 
				
			||||||
    Subversion or Perforce or whatever SCM you may be used to. It
 | 
					    Subversion or Perforce or whatever SCM you may be used to. It
 | 
				
			||||||
    is often easier to learn Git by trying to forget your assumptions
 | 
					    is often easier to learn Git by trying to forget your assumptions
 | 
				
			||||||
 
 | 
				
			|||||||
@@ -57,8 +57,8 @@ layout: reference
 | 
				
			|||||||
    you can use the <code>--author</code> option.  For example, let's say we're
 | 
					    you can use the <code>--author</code> option.  For example, let's say we're
 | 
				
			||||||
    looking for the commits in the Git source code done by Linus.  We would
 | 
					    looking for the commits in the Git source code done by Linus.  We would
 | 
				
			||||||
    type something like <code>git log --author=Linus</code>. The search is
 | 
					    type something like <code>git log --author=Linus</code>. The search is
 | 
				
			||||||
    case sensitive and also will search the email address.  I'll do the
 | 
					    case sensitive and will also search the email address.  The following
 | 
				
			||||||
    example using the <code>-[number]</code> option, which will limit the
 | 
					    example will use the <code>-[number]</code> option, which will limit the
 | 
				
			||||||
    results to the last [number] commits.
 | 
					    results to the last [number] commits.
 | 
				
			||||||
    </p>
 | 
					    </p>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
@@ -78,11 +78,11 @@ b532581 make "git unpack-file" a built-in
 | 
				
			|||||||
 | 
					
 | 
				
			||||||
    <p>
 | 
					    <p>
 | 
				
			||||||
    If you want to specify a date range that you're interested in filtering your
 | 
					    If you want to specify a date range that you're interested in filtering your
 | 
				
			||||||
    commits down to, you can use a number of options - I use <code>--since</code>
 | 
					    commits down to, you can use a number of options such as <code>--since</code>
 | 
				
			||||||
    and <code>--before</code>, but you can also use <code>--until</code> and
 | 
					    and <code>--before</code>, or you can also use <code>--until</code> and
 | 
				
			||||||
    <code>--after</code>.  For example, if I wanted to see all the commits in
 | 
					    <code>--after</code>.  For example, to see all the commits in
 | 
				
			||||||
    the Git project before 3 weeks ago but after April 18th, I could run this
 | 
					    the Git project before three weeks ago but after April 18th, you could run this
 | 
				
			||||||
    (I'm also going to use <code>--no-merges</code> to remove merge commits):
 | 
					    (We're also going to use <code>--no-merges</code> to remove merge commits):
 | 
				
			||||||
    </p>
 | 
					    </p>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
<pre>
 | 
					<pre>
 | 
				
			||||||
@@ -105,9 +105,9 @@ b6c8d2d Documentation/remote-helpers: Add invocation section
 | 
				
			|||||||
 | 
					
 | 
				
			||||||
    <p>
 | 
					    <p>
 | 
				
			||||||
      You may also want to look for commits with a certain phrase in the commit
 | 
					      You may also want to look for commits with a certain phrase in the commit
 | 
				
			||||||
      message.  You can use <code>--grep</code> for that.  Let's say I knew there
 | 
					      message.  Use <code>--grep</code> for that.  Let's say there
 | 
				
			||||||
      was a commit that dealt with using the P4EDITOR environment variable and
 | 
					      was a commit that dealt with using the P4EDITOR environment variable and
 | 
				
			||||||
      I wanted to remember what that change looked like - I could find the commit
 | 
					      you wanted to remember what that change looked like - you could find the commit
 | 
				
			||||||
      with <code>--grep</code>.
 | 
					      with <code>--grep</code>.
 | 
				
			||||||
    </p>
 | 
					    </p>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
@@ -132,11 +132,11 @@ Date:   Wed Mar 12 19:03:24 2008 -0500
 | 
				
			|||||||
    arguments.  If you want to use <code>--grep</code> and <code>--author</code>
 | 
					    arguments.  If you want to use <code>--grep</code> and <code>--author</code>
 | 
				
			||||||
    to see commits that were authored by someone AND have a specific message
 | 
					    to see commits that were authored by someone AND have a specific message
 | 
				
			||||||
    content, you have to add the <code>--all-match</code> option. In these
 | 
					    content, you have to add the <code>--all-match</code> option. In these
 | 
				
			||||||
    examples, I'm going to use the <code>--format</code> option, so we can see
 | 
					    examples we're going to use the <code>--format</code> option, so we can see
 | 
				
			||||||
    who the author of each commit was.
 | 
					    who the author of each commit was.
 | 
				
			||||||
    </p>
 | 
					    </p>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
    <p>If I look for the commit messages with 'p4 depo' in them, I get these
 | 
					    <p>If we look for the commit messages with 'p4 depo' in them, we get these
 | 
				
			||||||
    three commits:</p>
 | 
					    three commits:</p>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
<pre>
 | 
					<pre>
 | 
				
			||||||
@@ -146,8 +146,8 @@ da4a660 Benjamin Sergeant git-p4 fails when cloning a p4 depo.
 | 
				
			|||||||
1cd5738 Simon Hausmann Make incremental imports easier to use by storing the p4 d
 | 
					1cd5738 Simon Hausmann Make incremental imports easier to use by storing the p4 d
 | 
				
			||||||
</pre>
 | 
					</pre>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
    <p>If I add a <code>--author=Hausmann</code> argument, instead of further
 | 
					    <p>If we add a <code>--author=Hausmann</code> argument, instead of further
 | 
				
			||||||
    filtering it down to the one commit by Simon, it instead will show me all
 | 
					    filtering it down to the one commit by Simon, it instead will show all
 | 
				
			||||||
    commits by Simon OR commits with "p4 depo" in the message:</p>
 | 
					    commits by Simon OR commits with "p4 depo" in the message:</p>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
<pre>
 | 
					<pre>
 | 
				
			||||||
@@ -167,7 +167,7 @@ e96e400 Simon Hausmann git-p4: Fix submit user-interface.
 | 
				
			|||||||
...
 | 
					...
 | 
				
			||||||
</pre>
 | 
					</pre>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
    <p>However, if I add a <code>--all-match</code>, I get the results I'm
 | 
					    <p>However, adding <code>--all-match</code> will get the results you're
 | 
				
			||||||
    looking for:</p>
 | 
					    looking for:</p>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
<pre>
 | 
					<pre>
 | 
				
			||||||
@@ -438,7 +438,7 @@ index bb86f00..192151c 100644
 | 
				
			|||||||
    the triple-dot syntax, because it will almost always give you what you want.
 | 
					    the triple-dot syntax, because it will almost always give you what you want.
 | 
				
			||||||
    </p>
 | 
					    </p>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
    <p>As a bit of an aside, you can also have git manually calculate the
 | 
					    <p>As a bit of an aside, you can also have Git manually calculate what the
 | 
				
			||||||
    merge-base (first common ancestor commit) of any two commits would be with
 | 
					    merge-base (first common ancestor commit) of any two commits would be with
 | 
				
			||||||
    the <code>git merge-base</code> command:</p>
 | 
					    the <code>git merge-base</code> command:</p>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
@@ -447,7 +447,7 @@ index bb86f00..192151c 100644
 | 
				
			|||||||
8d585ea6faf99facd39b55d6f6a3b3f481ad0d3d
 | 
					8d585ea6faf99facd39b55d6f6a3b3f481ad0d3d
 | 
				
			||||||
</pre>
 | 
					</pre>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
    <p>So, you can do the equivalent of <code>git diff master...erlang</code>
 | 
					    <p>You can do the equivalent of <code>git diff master...erlang</code>
 | 
				
			||||||
    by running this:</p>
 | 
					    by running this:</p>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
<pre>
 | 
					<pre>
 | 
				
			||||||
@@ -457,7 +457,7 @@ index bb86f00..192151c 100644
 | 
				
			|||||||
 2 files changed, 9 insertions(+), 0 deletions(-)
 | 
					 2 files changed, 9 insertions(+), 0 deletions(-)
 | 
				
			||||||
</pre>
 | 
					</pre>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
    <p>I would of course recommend using the easier syntax, though.</p>
 | 
					    <p>You may prefer using the easier syntax though.</p>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					
 | 
				
			||||||
    <p class="nutshell">
 | 
					    <p class="nutshell">
 | 
				
			||||||
 
 | 
				
			|||||||
@@ -100,7 +100,7 @@ origin	git@github.com:github/git-reference.git (push)
 | 
				
			|||||||
    adds <code>[url]</code> under a local remote named <code>[alias]</code>.</p>
 | 
					    adds <code>[url]</code> under a local remote named <code>[alias]</code>.</p>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
    <p>For example, if we want to share our Hello World program with the world,
 | 
					    <p>For example, if we want to share our Hello World program with the world,
 | 
				
			||||||
    we can create a new repository on a server (I'll use GitHub as an example),
 | 
					    we can create a new repository on a server (Using GitHub as an example),
 | 
				
			||||||
    which should give you a URL, in this case "git@github.com:schacon/hw.git".
 | 
					    which should give you a URL, in this case "git@github.com:schacon/hw.git".
 | 
				
			||||||
    To add that to our project so we can push to it and fetch updates from it
 | 
					    To add that to our project so we can push to it and fetch updates from it
 | 
				
			||||||
    we would do this:</p>
 | 
					    we would do this:</p>
 | 
				
			||||||
@@ -117,8 +117,8 @@ github	git@github.com:schacon/hw.git (push)
 | 
				
			|||||||
    has no special meaning but is widely used because <code>git init</code>
 | 
					    has no special meaning but is widely used because <code>git init</code>
 | 
				
			||||||
    sets it up by default, 'origin' is often used as a remote name because
 | 
					    sets it up by default, 'origin' is often used as a remote name because
 | 
				
			||||||
    <code>git clone</code> sets it up by default as the cloned-from URL. In
 | 
					    <code>git clone</code> sets it up by default as the cloned-from URL. In
 | 
				
			||||||
    this case I've decided to name my remote 'github', but I could have really
 | 
					    this case we'll name the remote 'github', but you could name it just
 | 
				
			||||||
    named it just about anything.
 | 
					    about anything.
 | 
				
			||||||
    </p>
 | 
					    </p>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
    <h4>
 | 
					    <h4>
 | 
				
			||||||
@@ -266,10 +266,10 @@ fatal: No such remote 'guhflub'
 | 
				
			|||||||
    <p>The second command that will fetch down new data from a remote server is
 | 
					    <p>The second command that will fetch down new data from a remote server is
 | 
				
			||||||
    <code>git pull</code>.  This command will basically run a <code>git fetch</code>
 | 
					    <code>git pull</code>.  This command will basically run a <code>git fetch</code>
 | 
				
			||||||
    immediately followed by a <code>git merge</code> of the branch on that remote
 | 
					    immediately followed by a <code>git merge</code> of the branch on that remote
 | 
				
			||||||
    that is tracked by whatever branch you are currently in.  I personally don't much
 | 
					    that is tracked by whatever branch you are currently in.  Running the
 | 
				
			||||||
    like this command - I prefer running <code>fetch</code> and <code>merge</code>
 | 
					    <code>fetch</code> and <code>merge</code> commands separately involves less magic
 | 
				
			||||||
    separately.  Less magic, less problems.  However, if you like this idea, you
 | 
					    and less problems, but if you like the idea of <code>pull</code>, you can
 | 
				
			||||||
    can read about it in more detail in the
 | 
					    read about it in more detail in the
 | 
				
			||||||
    <a target="new" href="http://git-scm.com/docs/git-pull">official docs</a>.
 | 
					    <a target="new" href="http://git-scm.com/docs/git-pull">official docs</a>.
 | 
				
			||||||
    </p>
 | 
					    </p>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
@@ -277,9 +277,9 @@ fatal: No such remote 'guhflub'
 | 
				
			|||||||
    would first run <code>git fetch [alias]</code> to tell Git to fetch down all the
 | 
					    would first run <code>git fetch [alias]</code> to tell Git to fetch down all the
 | 
				
			||||||
    data it has that you do not, then you would run <code>git merge [alias]/[branch]</code>
 | 
					    data it has that you do not, then you would run <code>git merge [alias]/[branch]</code>
 | 
				
			||||||
    to merge into your current branch anything new you see on the server
 | 
					    to merge into your current branch anything new you see on the server
 | 
				
			||||||
    (like if someone else has pushed in the meantime). So, if I were working on my
 | 
					    (like if someone else has pushed in the meantime). So, if you were working on a
 | 
				
			||||||
    Hello World project with several other people and I wanted to bring in any changes
 | 
					    Hello World project with several other people and wanted to bring in any changes
 | 
				
			||||||
    that had been pushed since I last connected, I would do something like this:</p>
 | 
					    that had been pushed since we last connected, we would do something like this:</p>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
<pre>
 | 
					<pre>
 | 
				
			||||||
<b>$ git fetch github</b>
 | 
					<b>$ git fetch github</b>
 | 
				
			||||||
@@ -296,17 +296,17 @@ From github.com:schacon/hw
 | 
				
			|||||||
 * [new branch]      lisp       -> github/lisp
 | 
					 * [new branch]      lisp       -> github/lisp
 | 
				
			||||||
</pre>
 | 
					</pre>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
    <p>I can see that since the last time I synchronized with this remote, five branches
 | 
					    <p>Here we can see that since we last synchronized with this remote, five branches
 | 
				
			||||||
    have been added or updated.  The 'ada' and 'lisp' branches are new, where the
 | 
					    have been added or updated.  The 'ada' and 'lisp' branches are new, where the
 | 
				
			||||||
    'master', 'c-langs' and 'java' branches have been updated.  In this case, my team
 | 
					    'master', 'c-langs' and 'java' branches have been updated.  In our example case,
 | 
				
			||||||
    is pushing proposed updates to remote branches for review before they're merged
 | 
					    other developers are pushing proposed updates to remote branches for review before
 | 
				
			||||||
    into 'master'.
 | 
					    they're merged into 'master'.
 | 
				
			||||||
    </p>
 | 
					    </p>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
    <p>You can see the mapping that Git makes.  The 'master' branch on the remote
 | 
					    <p>You can see the mapping that Git makes.  The 'master' branch on the remote
 | 
				
			||||||
    repository becomes a branch named 'github/master' locally.  That way now I can
 | 
					    repository becomes a branch named 'github/master' locally.  That way you can
 | 
				
			||||||
    merge the 'master' branch on that remote into my local 'master' branch by running
 | 
					    merge the 'master' branch on that remote into the local 'master' branch by running
 | 
				
			||||||
    <code>git merge github/master</code>.  Or, I can see what new commits are on that
 | 
					    <code>git merge github/master</code>.  Or, you can see what new commits are on that
 | 
				
			||||||
    branch by running <code>git log github/master ^master</code>.  If your remote
 | 
					    branch by running <code>git log github/master ^master</code>.  If your remote
 | 
				
			||||||
    is named 'origin' it would be <code>origin/master</code> instead.  Almost any
 | 
					    is named 'origin' it would be <code>origin/master</code> instead.  Almost any
 | 
				
			||||||
    command you would run using local branches you can use remote branches with too.
 | 
					    command you would run using local branches you can use remote branches with too.
 | 
				
			||||||
@@ -356,10 +356,10 @@ To git@github.com:schacon/hw.git
 | 
				
			|||||||
</pre>
 | 
					</pre>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
    <p>Pretty easy. Now if someone clones that repository they will get exactly
 | 
					    <p>Pretty easy. Now if someone clones that repository they will get exactly
 | 
				
			||||||
    what I have committed and all of its history.</p>
 | 
					    what we have committed and all of its history.</p>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
    <p>What if I have a topic branch like the 'erlang' branch we created earlier
 | 
					    <p>What if you have a topic branch like the 'erlang' branch created earlier
 | 
				
			||||||
    and I just want to share that?  You can just push that branch instead.</p>
 | 
					    and want to share just that?  You can just push that branch instead.</p>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
<pre>
 | 
					<pre>
 | 
				
			||||||
<b>$ git push github erlang</b>
 | 
					<b>$ git push github erlang</b>
 | 
				
			||||||
 
 | 
				
			|||||||
		Reference in New Issue
	
	Block a user