• Choose a category
• All
• Classic-Fiction

Now that we have a grasp of viewing history in Mercurial, let’s take a look at making some changes and examining them.

The first thing we’ll do is isolate our experiment in a repository of its own. We use the hg clone command, but we don’t need to clone a copy of the remote repository. Since we already have a copy of it locally, we can just clone that instead. This is much faster than cloning over the network, and cloning a local repository uses less disk space in most cases, too.[1]

$ cd ..

$ hg clone hello my-hello

updating working directory

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

$cd my-hello

As an aside, it’s often good practice to keep a “pristine” copy of a remote repository around, which you can then make temporary clones of to create sandboxes for each task you want to work on. This lets you work on multiple tasks in parallel, each isolated from the others until it’s complete and you’re ready to integrate it back. Because local clones are so cheap, there’s almost no overhead to cloning and destroying repositories whenever you want.

In our my-hello repository, we have a file hello.c that contains the classic “hello, world” program.

$ cat hello.c

/*

* Placed in the public domain by Bryan O'Sullivan. This program is

* not covered by patents in the United States or other countries.

*/

#include

int main(int argc, char **argv)

{

printf("hello, world!\");

return 0;

}

Let’s edit this file so that it prints a second line of output:

# ... edit edit edit ...

$ cat hello.c

/*

* Placed in the public domain by Bryan O'Sullivan. This program is

* not covered by patents in the United States or other countries.

*/

#include

int main(int argc, char **argv)

{

printf("hello, world!\");

printf("hello again!\n");

return 0;

}

Mercurial’s hg status command will tell us what Mercurial knows about the files in the repository:

$ ls

Makefile hello.c

$ hg status

M hello.c

The hg status command prints no output for some files, but a line starting with M for hello.c. Unless you tell it to, hg status will not print any output for files that have not been modified.

The M indicates that Mercurial has noticed that we modified hello.c. We didn’t need to inform Mercurial that we were going to modify the file before we started, or that we had modified the file after we were done; it was able to figure this out itself.

It’s somewhat helpful to know that we’ve modified hello.c, but we might prefer to know exactly what changes we’ve made to it. To do this, we use the hg diff command:

$ hg diff

diff -r 2278160e78d4 hello.c

--- a/hello.c Sat Aug 16 22:16:53 2008 +0200

+++ b/hello.c Tue May 05 06:44:49 2009 +0000

@@ -8,5 +8,6 @@

int main(int argc, char **argv)

{

printf("hello, world!\");

+ printf("hello again!\n");

return 0;

}

* * *

Understanding patches

Remember to take a look at Understanding Patches if you don’t know how to read the output above.

* * *

* * *

[1] The saving of space arises when source and destination repositories are on the same filesystem, in which case Mercurial will use hardlinks to do copy-on-write sharing of its internal metadata. If that explanation meant nothing to you, don’t worry: everything happens transparently and automatically, and you don’t need to understand it.

Recording Changes in a New Changeset

We can modify files, build and test our changes and use hg status and hg diff to review our changes, until we’re satisfied with what we’ve done and arrive at a natural stopping point where we want to record our work in a new changeset.

The hg commit command lets us create a new changeset; we’ll usually refer to this as “making a commit” or “committing.”

Setting Up a Username

When you try to run hg commit for the first time, it is not guaranteed to succeed. Mercurial records your name and address with each change that you commit, so that you and others will later be able to tell who made each change. Mercurial tries to automatically figure out a sensible username to