• Choose a category
• All
• Classic-Fiction

adding changesets

adding manifests

adding file changes

added 1 changesets with 1 changes to 1 files

(run 'hg update' to get a working copy)

$ hg tip

changeset: 5:12efb75cbece

tag: tip

user: Bryan O'Sullivan

date: Tue May 05 06:44:49 2009 +0000

summary: Added an extra line of output

As you can see from the before-and-after output of hg tip, we have successfully pulled changes into our repository. However, Mercurial separates pulling changes in from updating the working directory. There remains one step before we will see the changes that we just pulled appear in the working directory.

* * *

Pulling specific changes

It is possible that due to the delay between running hg incoming and hg pull, you may not see all changesets that will be brought from the other repository. Suppose you’re pulling changes from a repository on the network somewhere. While you are looking at the hg incoming output, and before you pull those changes, someone might have committed something in the remote repository. This means that it’s possible to pull more changes than you saw when using hg incoming.

If you only want to pull precisely the changes that were listed by hg incoming, or you have some other reason to pull a subset of changes, simply identify the change that you want to pull by its changeset ID, e.g., hg pull -r7e95bb.

* * *

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 Pulling Changes from Another Repository 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:

$ grep printf hello.c

printf("hello, world!\");

$ hg update tip

1 files updated, 0 files merged, 0 files removed, 0 files unresolved

$ grep printf hello.c

printf("hello, world!\");

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 an hg pull that automatically updated the working directory to a new revision, you might not be terribly happy.

Since pull-then-update is such a common sequence of operations, Mercurial lets you combine the two by passing the -u option to hg pull.

If you look back at the output of hg pull in Pulling Changes from Another Repository 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.

To find out what revision the working directory is at, use the hg parents command:

$ hg parents

changeset: 5:12efb75cbece

tag: tip

user: Bryan O'Sullivan

date: Tue May 05 06:44:49 2009 +0000

summary: Added an extra line of output

If you look back at Figure 2-1, 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:

$ hg update 2

2 files updated, 0 files merged, 0 files removed, 0 files unresolved

$ hg parents

changeset: 2:fef857204a0c

user: Bryan O'Sullivan

date: Sat Aug 16 22:05:04 2008 +0200

summary: Introduce a typo into hello.c.

$ hg update

2 files updated, 0 files merged, 0 files removed, 0 files unresolved

$ hg parents

changeset: 5:12efb75cbece

tag: tip

user: Bryan O'Sullivan

date: Tue May 05 06:44:49 2009 +0000

summary: Added an extra