Your experiments with .hgignore and your thoughts about server vs. clone .hgignore give me the impression of a misunderstanding of how it works.

To clarify: The repo .hgignore file is a repo-specific listing of patterns to ignore.  As such, it needs to be shared, i.e. put under version control.

The ignore files (the repo .hgignore and optional files configured in ~/.hgrc or $SOMECLONE/.hg/hgrc) are consulted only for some commands:

- hg status (ignored files are not considered unknown)
- hg add . (a recursive add does not consider ignored files)
- hg addremove (etc.)

This explains why putting .hgignore in the .hgignore file cannot possibly work.

If *.rej and *.orig are ignored, they don’t show up in “hg status”, and are not added with “hg add somedir”.  My point is that this behavior is not useful: it does not protect from anything (who adds directories when merging changesets?  also, who does not run status and diff before commit?  they should), and does not help us check whether we’ve properly merged all files.  I prefer to see the *.rej files in hg status output, check them and delete them.

So, can I commit?  I’m willing to update the devguide and reply to possibly angry python-dev feedback with an explanation of how to ignore those files on a per-user or per-clone basis.