• Choose a category
• All
• Classic-Fiction

You can read a -I filter as “process only the files that match this filter.”

$ hg status -I '*.in'

? MANIFEST.in

The -X filter is best read as “process only the files that don’t match this pattern.”

$ hg status -X '**.py' src

? src/watcher/_watcher.c

? src/xyzzy.txt

Permanently Ignoring Unwanted Files and Directories

When you create a new repository, chances are that over time it will grow to contain files that ought to not be managed by Mercurial, and which you don’t want to see listed every time you run hg status. For instance, “build products” are files that are created as part of a build but that should not be managed by a revision control system. The most common build products are output files produced by software tools such as compilers. As another example, many text editors litter a directory with lock files, temporary working files, and backup files, which it also makes no sense to manage.

To have Mercurial permanently ignore such files, create a file named .hgignore in the root of your repository. You should hg add this file so that it gets tracked with the rest of your repository contents, since your collaborators will probably find it useful too.

By default, the .hgignore file should contain a list of regular expressions, one per line. Empty lines are skipped. Most people prefer to describe the files they want to ignore using the glob syntax that we described above, so a typical .hgignore file will start with this directive:

syntax: glob

This tells Mercurial to interpret the lines that follow as glob patterns, not regular expressions.

Here is a typical-looking .hgignore file.

syntax: glob

# This line is a comment, and will be skipped.

# Empty lines are skipped too.

# Backup files left behind by the Emacs editor.

*~

# Lock files used by the Emacs editor.

# Notice that the "#" character is quoted with a backslash.

# This prevents it from being interpreted as starting a comment.

.\#*

# Temporary files used by the vim editor.

.*.swp

# A hidden file created by the Mac OS X Finder.

.DS_Store

Case Sensitivity

If you’re working in a mixed development environment that contains both Linux (or other Unix) systems and Macs or Windows systems, you should keep in the back of your mind the knowledge that they treat the case (“N” versus “n”) of filenames in incompatible ways. This is not very likely to affect you, and it’s easy to deal with if it does, but it could surprise you if you don’t know about it.

Operating systems and filesystems differ in the way they handle the case of characters in file and directory names. There are three common ways to handle case in names:

Completely case insensitive. Uppercase and lowercase versions of a letter are treated as identical, both when creating a file and during subsequent accesses. This is common on older DOS-based systems.

Case preserving, but insensitive. When a file or directory is created, the case of its name is stored, and can be retrieved and displayed by the operating system. When an existing file is being looked up, its case is ignored. This is the standard arrangement on Windows and Mac OS. The names foo and FoO identify the same file. This treatment of uppercase and lowercase letters as interchangeable is also referred to as case folding.

Case sensitive. The case in a name is significant at all times. The names foo and FoO identify different files. This is the way Linux and Unix systems normally work.

On Unix-like systems, it is possible to have any or all of the above ways of handling case in action at once. For example, if you use a USB thumb drive formatted with a FAT32 filesystem on a Linux system, Linux will handle names on that filesystem in a case preserving, but insensitive, way.

Safe, Portable Repository Storage

Mercurial’s repository storage mechanism is case safe. It translates filenames so that they can be safely stored on both case-sensitive and case-insensitive filesystems. This means that