views:

366

answers:

1

I've been working for a long time with a .hgignore file that was fine and recently added one new type of files to ignore. When running "hg status", I noticed this:

M .hgignore

So Mercurial considers the .hgignore to be a file that needs to be tracked (if it's a the root of the project).

Now I've read various docs but my points weren't specifically adressed so here are some very detailed questions which hopefully can help me figure this out (it would be great is someone answering could quote and address these three points [even with a simply yes/no answer for each question]):

  • Should .hgignore be at the root of the project? (I guess it should, seen that a developer can potentially be working on several projects which would all have different .hgignore requirements)

  • Can .hgignore be ignored be Mercurial?

  • If it can be ignored, should .hgignore be ignored by Mercurial (which is different than the previous question)

In the case where .hgignore should not be ignored, can't some really bad thing happens if you suddenly rollback way earlier, when a really old and incomplete .hgignore was used?

I think I saw weird things happening with certain per-user IDE project files (I'm not saying all IDEs project files are per-user only, but some definitely are) that were supposed to be ignored, but then the user rolls back to an old version, where an old .hgignore gets used, and then suddenly files supposed to be ignored are committed because the old .hgignore didn't exclude these.

+9  A: 

You don't generally ignore the .hgignore file because you want it to be part of the repository so all of your users end up with it.

As far as rolling far back and then accidentally committing files you shouldn't - well, that really could happen at any point anyway. Commit responsibly.

To your other questions:

  • Yes, .hgignore should be at the root of the repository.
  • Yes, .hgignore can ignore itself.
  • No, .hgignore should not be ignored (unless you decide you don't want it in the repository).
Chris Shaffer