2010-09-10 5 views
8

J'ai un référentiel pour une application sur laquelle je travaille qui inclut un fichier de configuration. Actuellement, je distribue avec une extension .dist et je demande à l'utilisateur de renommer le fichier avant de le modifier.Ajouter un fichier de configuration ignoré pour git repo comme exemple

nate:~/myAwesomeApp% git ls-files 
.gitignore 
README 
config.dist 
glorious_support_lib.p 
bestProgramEvar.f90 

Ceci est bien et dandy, et la configuration actuelle est ignorée.

nate:~/myAwesomeApp% cat .gitignore 
config 

Il serait doux, cependant, si je pouvais distribuer ce fichier de configuration sous son vrai nom et prêt à modifier, tout en laissant ignoré de sorte qu'une nouvelle copie clonée du référentiel a la distribution « fonctionnelle », et il ne sera pas écrasé, mis à mal, ou autrement molesté, et de telle sorte que les utilisateurs ne sont pas à vous soucier de pousser ou de publier leurs super-secret détails de configuration aux interwebs via une git commit -a -m 'hurrrr derp! oopsies!' && git push involontaire

Y-a-t'il une façon de le faire? D'avoir git garder autour d'une seule version originale du fichier qui est cloné, mais par la suite ignoré?

Je suis sûr que cela a déjà été demandé, mais pour la vie de moi, mon google-fu a échoué. Lay l'école en profondeur, SO.

Répondre

2

Vous pouvez également la version et la distribution:

  • un .gitattributes fichiers déclarant un filter driver (pour seulement 'config.dist')
  • un script bavure qui permet de détecter que le contenu et générer le final (et privé, comme dans "non-versionné" fichier config)

Maintenant que je s bending un peu ce qu'est un pilote de filtre (il s'agit de modifier le contenu d'un fichier, regardless of its "state", i.e its full path and name). Mais ça peut marcher.
Le .gitattributes contiendrait:

config.dist filter=generateConfig 

alt text

Et vous pouvez enregistrer votre script maculage (appliqué au cours de l'étape de la commande lors de la création/mise à jour du répertoire de travail) comme:

git config --global filter.generateConfig.smudge /path/to/generateConfig 
6

J'inclurais probablement un script 'install' qui copiait 'config.dist' en 'config'.

Je ne pense pas qu'il existe un moyen d'avoir un fichier à la fois non-ignoré et ignoré.

+0

C'est essentiellement ce que je fais maintenant. Ce serait juste gentil s'il y avait une capacité "ignorer après commettre xxxxxx". – sleepynate

+0

@sleepynate Peut-être qu'un post commit commit un crochet vérifiant le commit xxxxxx et ajoutant quelque chose à .gitignore? – takeshin

4

C'est une bonne question, mais je pense qu'il n'y a pas de solution git pour cela.

Peu solutions de contournement:

  • configurer votre application pour lire config.dist quand config n'est pas (par exemple PHPUnit utilise cette technique)
  • script build
  • utiliser pour ce faire renomme pour vous (par exemple fourmi ou phing)
  • utiliser des crochets git pour renommer les configs
+0

Je pense que 'post-checkout' fonctionne sur clone .. mais le crochet descend-il avec le repo sur le clone initial? Comment cela ressemble-t-il? – sleepynate

+0

@sleepynate Ce sera difficile à faire. Juste testé - les hooks ne sont pas clonés avec le repo sur 'git clone [repo]'. J'ai pensé aux crochets git utilisés pendant le développement. Je n'ai pas considéré le clonage comme une technique de distribution de l'application. – takeshin

+0

Oh désolé. Je vais modifier pour plus de clarté. C'est pour l'utilisateur final quand ils clonent. j'ai déjà un 'si [! -e config]; alors cp config.dist config; fi' – sleepynate

1

Comme d'autres l'ont souligné, il n'y a pas de solution magique pour cela dans Git. Et autant que je sache, c'est la même chose avec d'autres systèmes de contrôle de version. Les hameçons ne sont pas non plus une solution ici, s'ils fonctionnaient de cette façon, ce qui constituerait une menace sérieuse pour la sécurité - juste en clonant un repo, un code malveillant pourrait s'exécuter dans votre machine.

Mais pour utiliser votre application, l'utilisateur doit faire au moins une chose en plus de le cloner avec git: en cours d'exécution de votre application.

  • Si la modification du fichier de configuration n'est pas nécessaire pour l'exécution de l'application, si votre programme ne if [ ! -e config ] ; then cp config.dist config ; fi au démarrage, cela devrait être assez à mon humble avis. De plus, vous devriez avoir un avertissement à l'intérieur de config.dist qui dit que vous ne devriez pas modifier ce fichier, mais en faire une copie à la place.

  • Si la modification du fichier de configuration est nécessaire, puis à partir du programme sans fichier de configuration peut démarrer un certain mode d'installation, qui demande à l'utilisateur d'entrer dans les options de configuration nécessaires et les enregistre.

  • Une troisième possibilité est que votre application est incapable de modifier le fichier de configuration au démarrage (il s'agit peut-être de quelques fichiers JavaScript + HTML). Dans ce cas, je ne vois pas d'autre choix que d'avoir un script de construction séparé ou de laisser l'utilisateur le faire manuellement.