Is there an ignore-on-commit option in mercurial?

Question

Is there any way to ignore changes to some files on a commit with mercurial?

I've got a specific situation where we have a default oracle tnsnames.ora file that points to 127.0.0.1, but some developers will modify it to point to other systems, but we don't want to change the default file.

In subversion, I've simple added this to the ignore-on-commit changelist. Is there a way of doing this in mercurial?

Solution 1

If the files you want to omit from the "hg commit" command are already "tracked", you should use the -X option. The pattern passed to -X is pretty flexible, making it possible to run for example:

% hg stat
A etc/foo.conf
M src/bar.c
M lib/libbar/loader.c
% hg commit -X '**.conf'

to avoid committing any file with a ".conf" extension, regardless of how deep in the source tree it lives. In the workspace shown above this would commit "src/bar.c" and "lib/libbar/loader.c" but not "etc/foo.conf".

To exclude multiple patterns of filenames, use multiple -X options, i.e.:

% hg commit -X '**.conf' -X '**.sh'

Solution 2

Traditionally, this is solved by not versioning the file itself, but by versioning a copy of it as a template for others to use.

So you would hg mv tnsnames.ora tnsnames.ora-template, then commit, then do a straight filesystem copy of tnsnames.ora-template to tnsnames.ora, and add tnsnames.ora to the .hgignore file.

Subsequent changes to the template will still get pushed out, but they won't actually change the working environment unless someone copies the template to the actual file.

Solution 3

You could alias commit to something like 'hg commit -X excluded_file.ext' I've never used mercurial, so I'm just going by the man page here.

Comments

[Nick Randell]

The tnsnames.ora file is already checked in. I want to ignore my local changes because they are for my machine only. This is why .hgignore doesn't work

[SND]

So if you have app.config and you rename it to app.config-template there will no longer be an app.config in the repository. This will cause problems with an automated build. I presume the build process needs to be informed of this 'template' and rename it back. This isn't so great.

[Zed]

You don't want to rename, you want to copy and modify. You can either do that from your autobuild scripts or you can do it from a hook, but either way if you have files that are going to be different from clone to clone there is going to have to be some intelligence applied somewhere.

[Kugel]

Is there any way to make this permanent? I don't want to -X on each commit.

[Erik Reppen]

@Kugel Doesn't look like it. Mercurial is striking me as a lousy choice for a codebase with like 20 config files that all have user-specific stuff in them. I shouldn't have to write scripts to get version control to work for me rather than against me. And no, the 20 config files wasn't my idea either. I'm guessing that guy also chose Mercurial too.

[Andriy K]

@Kugel: it's possible to create alias for the command with the same name, as described in selenic.com/mercurial/hgrc.5.html#alias thus overriding it. Despite it is said that it's almost always bad idea, this can be the case when it isn't.

[rkm]

can't you try something in .hgignore?

[David C]

This worked for me, but afterward, I couldn't do an hg fetch because it says I still have outstanding uncommited changes. .hgignore wont help because it's already being tracked. hg forget removes it from the repository, which is not desirable for something like a connection string config file.

[Kevin Shea]

This, along with some patches is how I get around a problem like this. However, watch out if you use TortoiseHG as this seems to commit with the list of file changes, basically overriding the config file. If I've made a mistake somewhere, please point it out :-)

[Jay Sheridan]

I've learned that the quotes are very important for the -X option. If you don't have them, mercurial treats your globs as if they were specified files to commit.