- .hgignore n'a pas besoin d'être créé avant d'init
- Le fichier de configuration sera utilisée par les autres, vous feriez mieux de commettre l' .hgignore alors que d'autres n'ont pas à le créer, mais ce n'est pas nécessaire pour mercurial ignorer vos fichiers locaux (voir l'exemple)
- Oui .hgignore doit être dans le répertoire racine
Exemple Simple.
Init le repo:
$ mkdir test
$ cd test
$ hg init
Créer un fichier
$ touch foo
$ hg st
? foo
Maintenant, créez une .hgignore, dans le répertoire racine de votre repo:
$ echo 'foo' > .hgignore
foo est maintenant ignorée:
$ hg st
? .hgignore
Notons que .hgignore n'a pas besoin d'être engagé pour que cela fonctionne.
Un peu plus compliqué
Si le fichier de configuration et un .hgignore (en ignorant le fichier de config), se sont engagés dans l'opération, alors oui, le fichier de configuration changements seront suivis (en d'autres mots, .hgignore n'aura aucun effet)
La création de config et de la commettre
$ touch config
$ hg ci config -Am 'adding conf'
L'ignorer:
$ echo 'config' >> .hgignore
Commettre .hgignore:
$ hg ci .hgignore -Am '.hgignore'
Alors si vous cloner le repo:
$ cd ..
$ hg clone test other-user
$ cd other-user
et modifier la config:
$ echo 'new config param' >> config
puis hg montrera les changements:
$ hg st
M config
La façon de traiter ce problème?
Vous souhaitez probablement l'un des principaux fichiers de configuration par défaut, qui est versionné, dans le référentiel, global.cfg
Et vous demandez aux utilisateurs de créer un local.cfg où ils vont mettre leur milieu local. Et le script sera source de l' local.cfg le cas échéant: les paramètres locaux de remplacer le. Bien sûr, ajouter une ligne d' .hgignore d'ignorer local.cfg ;)
Alternative: aucun fichier de config, seulement un config.example que les utilisateurs de copier et de modifier localement. Le con ici c'est que vous n'aurez pas à garder une trace facilement des modifications entre les versions.
