-To get started, let’s clone our original hello repository, which does not contain the change we just committed. We’ll call our temporary repository hello-pull.
-
-1 $ cd ..
-2 $ hg clone hello hello-pull
-3 2 files updated, 0 files merged, 0 files removed, 0 files unresolved
-
-We’ll use the “hg pull” command to bring changes from my-hello into hello-pull. However, blindly pulling unknown changes into a repository is a somewhat scary prospect. Mercurial provides the “hg incoming” command to tell us what changes the “hg pull” command would pull into the repository, without actually pulling the changes in.
-
-1 $ cd hello-pull
-2 $ hg incoming ../my-hello
-3 comparing with ../my-hello
-4 searching for changes
-5 changeset: 5:fa1321bf0c80
-6 tag: tip
-7 user: Bryan O'Sullivan <bos@serpentine.com>
-8 date: Sun Jun 17 18:05:50 2007 +0000
-9 summary: Added an extra line of output
-10
-
-(Of course, someone could cause more changesets to appear in the repository that we ran “hg incoming” in, before we get a chance to “hg pull” the changes, so that we could end up pulling changes that we didn’t expect.)
-
-Bringing changes into a repository is a simple matter of running the “hg pull” command, and telling it which repository to pull from.
-
-1 $ hg tip
-2 changeset: 4:b57f9a090b62
-3 tag: tip
-4 user: Bryan O'Sullivan <bos@serpentine.com>
-5 date: Tue Sep 06 15:43:07 2005 -0700
-6 summary: Trim comments.
-7
-8 $ hg pull ../my-hello
-9 pulling from ../my-hello
-10 searching for changes
-11 adding changesets
-12 adding manifests
-13 adding file changes
-14 added 1 changesets with 1 changes to 1 files
-15 (run 'hg update' to get a working copy)
-16 $ hg tip
-17 changeset: 5:fa1321bf0c80
-18 tag: tip
-19 user: Bryan O'Sullivan <bos@serpentine.com>
-20 date: Sun Jun 17 18:05:50 2007 +0000
-21 summary: Added an extra line of output
-22
-
-As you can see from the before-and-after output of “hg tip”, we have successfully pulled changes into our repository. There remains one step before we can see these changes in the working directory.
-
-#### 2.8.2 Updating the working directory
-
-We have so far glossed over the relationship between a repository and its working directory. The “hg pull” command that we ran in section [2.8.1][12] brought changes into the repository, but if we check, there’s no sign of those changes in the working directory. This is because “hg pull” does not (by default) touch the working directory. Instead, we use the “hg update” command to do this.
-
-1 $ grep printf hello.c
-2 printf("hello, world!∖");
-3 $ hg update tip
-4 1 files updated, 0 files merged, 0 files removed, 0 files unresolved
-5 $ grep printf hello.c
-6 printf("hello, world!∖");
-7 printf("hello again!∖n");
-
-It might seem a bit strange that “hg pull” doesn’t update the working directory automatically. There’s actually a good reason for this: you can use “hg update” to update the working directory to the state it was in at any revision in the history of the repository. If you had the working directory updated to an old revision—to hunt down the origin of a bug, say—and ran a “hg pull” which automatically updated the working directory to a new revision, you might not be terribly happy.
-
-However, since pull-then-update is such a common thing to do, Mercurial lets you combine the two by passing the -u option to “hg pull”.
-
-1 hg pull -u
-
-If you look back at the output of “hg pull” in section [2.8.1][12] when we ran it without -u, you can see that it printed a helpful reminder that we’d have to take an explicit step to update the working directory:
-
-1 (run 'hg update' to get a working copy)
-
-To find out what revision the working directory is at, use the “hg parents” command.
-
-1 $ hg parents
-2 changeset: 5:fa1321bf0c80
-3 tag: tip
-4 user: Bryan O'Sullivan <bos@serpentine.com>
-5 date: Sun Jun 17 18:05:50 2007 +0000
-6 summary: Added an extra line of output
-7
-
-If you look back at figure [2.1][8], you’ll see arrows connecting each changeset. The node that the arrow leads from in each case is a parent, and the node that the arrow leads to is its child. The working directory has a parent in just the same way; this is the changeset that the working directory currently contains.
-
-To update the working directory to a particular revision, give a revision number or changeset ID to the “hg update” command.
-
-1 $ hg update 2
-2 2 files updated, 0 files merged, 0 files removed, 0 files unresolved
-3 $ hg parents
-4 changeset: 2:057d3c2d823c
-5 user: Bryan O'Sullivan <bos@serpentine.com>
-6 date: Tue Sep 06 13:15:43 2005 -0700
-7 summary: Introduce a typo into hello.c.
-8
-9 $ hg update
-10 2 files updated, 0 files merged, 0 files removed, 0 files unresolved
-
-If you omit an explicit revision, “hg update” will update to the tip revision, as shown by the second call to “hg update” in the example above.
+To get started, let’s clone our original hello repository, which does
+not contain the change we just committed. We’ll call our temporary
+repository hello-pull.
+
+ $ cd ..
+ $ git clone hello hello-pull
+ Initialized empty Git repository in /tmp/hello-pull/.git/
+ 0 blocks
+
+We could use the “git pull” command to apply changes from my-hello to
+our master branch in hello-pull. However, blindly pulling unknown
+changes into a repository is a somewhat scary prospect. The "git pull"
+command is coneptually the combination of two commands, "git fetch"
+and "git merge"; we can run those separately to examine the changes
+before applying them locally. First we do the fetch:
+
+ $ cd hello-pull
+ $ git fetch ../my-hello
+ remote: Generating pack...
+ Unpacking 3 objects...
+ 100% (3/3) done
+ remote: Done counting 5 objects.
+ Result has 3 objects.
+ Deltifying 3 objects...
+ 100% remote: (3/3) done
+ Total 3 (delta 1), reused 0 (delta 0)
+
+The fetched commits (or commit in this case) are available as the name
+FETCH_HEAD. [XXX: Shouldn't git-fetch print that name out to the user
+if the user didn't provide a specific branch name to fetch into.] And
+the difference between what we had before and what exists on
+FETCH_HEAD can easily be examined with the ..FETCH_HEAD range
+notation:
+
+ $ git log ..FETCH_HEAD
+ commit 839b58d021c618bd0e1d336d4d5878a0082672e6
+ Author: Carl Worth <cworth@cworth.org>
+ Date: Thu Sep 27 23:55:00 2007 -0700
+
+ Added an extra line of output and fixed the typo bug.
+
+Since these commits actually exist in the local repository now, we
+don't need to fetch or pull them from the remote repository again---we
+can now use "git merge" to apply the previously fetched commits. (A
+mercurial user might notice here that git does not have the race
+condition between "hg incoming" and "hg pull" that mercurial has since
+the commits are fetched only once.)
+
+ $ git merge FETCH_HEAD
+ Updating a1a0e8b..839b58d
+ Fast forward
+ hello.c | 3 ++-
+ 1 files changed, 2 insertions(+), 1 deletions(-)
+
+Notice that "git merge" reports that our branch pointer has been
+updated from a1a0e8b to 839b58d. Also, this is a "fast forward"
+meaning that the new commits are a linear sequence on top of the
+commit we already hand. In other words, there wasn't any divergence
+between these two repositories so no actual "merge" commit was
+created.
+
+This separation of fetch and merge is useful when you need to
+carefully review some changes before applying them. But often you're
+in a situation where you know you trust the remote repository and you
+simply want to pull those changes as conveniently as possible, (no
+extra commands, no typing a magic name like FETCH_HEAD). This is the
+case when the tracking upstream development of a project with git. And
+in that case, the above steps are as simple as just executing "git
+pull". So let's repeat all that the simpler way:
+
+ $ cd ..
+ $ git clone hello hello-tracking
+ Initialized empty Git repository in /tmp/hello-tracking/.git/
+ 0 blocks
+ $ cd hello-tracking
+ $ git pull ../my-hello
+ remote: Generating pack...
+ remote: Done counting 5 objects.
+ Result has 3 objects.
+ Deltifying 3 objects...
+ Unpacking 3 objects...
+ remote: 100% (3/3) done
+ Total 3 (delta 1), reused 0 (delta 0)
+ 100% (3/3) done
+ Updating a1a0e8b..839b58d
+ Fast forward
+ hello.c | 3 ++-
+ 1 files changed, 2 insertions(+), 1 deletions(-)
+
+It should be plain to see that the "git pull" command really did the
+combined sequence of "git fetch" and "git merge". Also, if you want to
+pull from the same repository you cloned from originally, (which is
+the common case for the upstream-tracking scenario), then "git pull"
+with no explicit repository is suffcient, and it will default to
+pulling from the same repository as the original clone.
+
+#### 2.8.2 Checking out previous revisions
+
+If any users of mercurial are reading this, they might wonder if
+there's a need for the equivalent of "hg update" after doing a "git
+pull". And the answer is no. Unlike mercurial, "git pull" and "git
+merge" will automatically update the workind-directory files as
+necessary.
+
+But there's another function provided by "hg update" which is to
+update the working-directory files to a particular revision. In git,
+this functionality is provided by the "git checkout" command. To
+checkout a particular branch, tag, or an arbitrary revions, simply
+give the appropriate name to the "git checkout" command. For example,
+to examine the files as they existed before the original typo
+introduction, we could do:
+
+ $ git checkout 0a633bf5
+ Note: moving to "0a633bf5" which isn't a local branch
+ If you want to create a new branch from this checkout, you may do so
+ (now or later) by using -b with the checkout command again. Example:
+ git checkout -b <new_branch_name>
+ HEAD is now at 0a633bf... Create a makefile
+
+The note that git gives us is to indicate that we are checking out a
+non-branch revision. This is perfectly fine if we are just exploring
+history, but if we actually wanted to use this revision as the basis
+for new commits, we would first have to create a new branch name as it
+describes.
+
+For now, let's return back to the tip of the master branch by just
+checking it out again:
+
+ $ git checkout master
+ Previous HEAD position was 0a633bf... Create a makefile
+ Switched to branch "master"