- .hgignore does not need to be created before init
- It the config file will be used by others, you'd better commit the .hgignore so others dont have to create it, but this is not needed for mercurial to ignore your local files (see example)
- Yes .hgignore has to be in the root directory
Simple example.
Init the repo:
$ mkdir test
$ cd test
$ hg init
Create a file
$ touch foo
$ hg st
? foo
Now create a .hgignore, in the root directory of your repo:
$ echo 'foo' > .hgignore
foo
is now ignored:
$ hg st
? .hgignore
Note that .hgignore does not need to be committed for this to work.
A bit more tricky
If both the config file and a .hgignore (ignoring the config file) are committed in the repo, then yes, the config file changes will be tracked (in other words, .hgignore will have no effect)
Creating config and commit it
$ touch config
$ hg ci config -Am 'adding conf'
Ignore it:
$ echo 'config' >> .hgignore
Commit .hgignore:
$ hg ci .hgignore -Am '.hgignore'
Then if you clone the repo:
$ cd ..
$ hg clone test other-user
$ cd other-user
and modify config:
$ echo 'new config param' >> config
then hg will show the changes:
$ hg st
M config
How to deal with this?
You probably want to have a main default configuration file, that is versioned, in the repository, global.cfg
And you will ask users to create a local.cfg
where they will put their local settings. And your script will source the local.cfg
if present: the local settings override the global ones. Of course, add a line to .hgignore
to ignore local.cfg
;)
Alternative: no global config file, only a config.example
that users copy and modify locally. The con here is that you will not keep track easily of changes between versions.