Mercurial: The Definitive Guide

The Working Directory

In the working directory, Mercurial stores a snapshot of the files from the repository as of a particular changeset.

The working directory “knows” which changeset it contains. When you update the working directory to contain a particular changeset, Mercurial looks up the appropriate revision of the manifest to find out which files it was tracking at the time that changeset was committed, and which revision of each file was then current. It then recreates a copy of each of those files, with the same contents it had when the changeset was committed.

The dirstate is a special structure that contains Mercurial’s knowledge of the working directory. It is maintained as a file named .hg/dirstate inside a repository. The dirstate details which changeset the working directory is updated to, and all of the files that Mercurial is tracking in the working directory. It also lets Mercurial quickly notice changed files, by recording their checkout times and sizes.

Just as a revision of a revlog has room for two parents, so that it can represent either a normal revision (with one parent) or a merge of two earlier revisions, the dirstate also has slots for two parents. When you use the hg update command, the changeset that you update to is stored in the “first parent” slot, and the null ID in the second. When you hg merge with another changeset, the first parent remains unchanged, and the second parent is filled in with the changeset you’re merging with. The hg parents command tells you what the parents of the dirstate are.

What Happens When You Commit

The dirstate stores parent information for more than just book-keeping purposes. Mercurial uses the parents of the dirstate as the parents of a new changeset when you perform a commit.

Figure 4-5. The working directory can have two parents

Figure 4-5 shows the normal state of the working directory, where it has a single changeset as parent. That changeset is the tip, the newest changeset in the repository that has no children.

Figure 4-6. The working directory gains new parents after a commit

It’s useful to think of the working directory as “the changeset I’m about to commit.” Any files that you tell Mercurial that you’ve added, removed, renamed, or copied will be reflected in that changeset, as will modifications to any files that Mercurial is already tracking; the new changeset will have the parents of the working directory as its parents.

After a commit, Mercurial will update the parents of the working directory, so that the first parent is the ID of the new changeset, and the second is the null ID. This is shown in Figure 4-6. Mercurial doesn’t touch any of the files in the working directory when you commit; it just modifies the dirstate to note its new parents.

Creating a New Head

It’s perfectly normal to update the working directory to a changeset other than the current tip. For example, you might want to know what your project looked like last Tuesday, or you could be looking through changesets to see which one introduced a bug. In cases like this, the natural thing to do is update the working directory to the changeset you’re interested in, and then examine the files in the working directory directly to see their contents as they were when you committed that changeset. The effect of this is shown in Figure 4-7.

Figure 4-7. The working directory, updated to an older changeset

Having updated the working directory to an older changeset, what happens if you make some changes, and then commit? Mercurial behaves in the same way as I outlined above. The parents of the working directory become the parents of the new changeset. This new changeset has no children, so it becomes the new tip. And the repository now contains two changesets that have no children; we call these heads. You can see the structure that this creates in Figure 4-8.

Figure 4-8. After a commit made while synced to an older changeset

Note

If you’re new to Mercurial, you should keep in mind a common “error,” which is to use the hg pull command without any options. By default, the hg pull command does not update the working directory, so you’ll bring new changesets into your repository, but the working directory will stay synced at the same changeset as before the pull. If you make some changes and commit afterwards, you’ll thus create a new head, because your working directory isn’t synced to whatever the current tip is. To combine the operation of a pull, followed by an update, run hg pull -u.

I put the word “error” in quotes because all that you need to do to rectify the situation where you created a new head by accident is hg merge, then hg commit. In other words, this almost never has negative consequences; it’s just something of a surprise for newcomers. I’ll discuss other ways to avoid this behavior, and why Mercurial behaves in this initially surprising way, later on.

Merging Changes

When you run the hg merge command, Mercurial leaves the first parent of the working directory unchanged, and sets the second parent to the changeset you’re merging with, as shown in Figure 4-9.

Figure 4-9. Merging two heads

Mercurial also has to modify the working directory, to merge the files managed in the two changesets. Simplified a little, the merging process goes like this, for every file in the manifests of both changesets:

• If neither changeset has modified a file, do nothing with that file.

• If one changeset has modified a file and the other hasn’t, create the modified copy of the file in the working directory.

• If one changeset has removed a file and the other hasn’t (or has also deleted it), delete the file from the working directory.

• If one changeset has removed a file but the other has modified the file, ask the user what to do: keep the modified file, or remove it?

• If both changesets have modified a file, invoke an external merge program to choose the new contents for the merged file. This may require input from the user.

• If one changeset has modified a file and the other has renamed or copied the file, make sure that the changes follow the new name of the file.

There are more details—merging has plenty of corner cases—but these are the most common choices that are involved in a merge. As you can see, most cases are completely automatic, and indeed most merges finish automatically, without requiring your input to resolve any conflicts.

When you’re thinking about what happens when you commit after a merge, once again the working directory is “the changeset I’m about to commit.” After the hg merge command completes, the working directory has two parents; these will become the parents of the new changeset.

Mercurial lets you perform multiple merges, but you must commit the results of each individual merge as you go. This is necessary because Mercurial only tracks two parents for both revisions and the working directory. While it would be technically feasible to merge multiple changesets at once, Mercurial avoids this for simplicity. With multi-way merges, the risks of user confusion, nasty conflict resolution, and making a terrible mess of a merge would grow intolerable.

Merging and Renames

A surprising number of revision control systems pay little or no attention to a file’s name over time. For instance, it used to be common that if a file got renamed on one side of a merge, the changes from the other side would be silently dropped.

Mercurial records metadata when you tell it to perform a rename or copy. It uses this metadata to do the right thing during a merge. For instance, if I rename a file, and you edit it without renaming it, when we merge our work the file will be renamed and have your edits applied.