Que dois-je / ne dois-je pas faire pour conserver .emacs et .emacs.d dans le contrôle de version?

Comme beaucoup de gens, je gère beaucoup de mes fichiers de points via un référentiel de contrôle de version (Mercurial sur Bitbucket, privé, dans mon cas). Cela s'avère pratique lors de la configuration d'une nouvelle machine ou de la propagation de configurations entre différentes machines.

Alors naturellement, j'ai ajouté mon .emacset .emacs.dà cette configuration.

Ensuite, j’ai installé des paquets et y *.elcai ajouté .hgignore, tout comme j’ignorais les *.pycfichiers de mon dépôt Python.

Existe-t-il d'autres éléments que je ne devrais pas suivre, par exemple des fichiers générés qui sont spécifiques à l'environnement et qui ne seront pas utiles / corrects lorsqu'ils sont clonés sur une autre plate-forme? (J'utilise Linux et OS X sur le bureau et FreeBSD sur le serveur.)

Existe-t-il des astuces de configuration couramment utilisées pour rendre ce type de partage plus utile? Avec la configuration de mes fichiers shell, je suis toujours à la recherche de bons moyens pour sélectionner des fichiers individuels dans différentes branches, par exemple.

Je stocke ma configuration Emacs dans Github car j'utilise deux ordinateurs différents, l'un au travail, l'autre à la maison.

Voici une liste de choses que je ne mets pas dans le contrôle de source:

Environnement spécifié configurations.

Par exemple, mes Emacs ouvrent un fichier org différent au démarrage sur une machine différente. Vous ne voulez pas valider ces paramètres dans le contrôle de source.

J'utilise (require 'local nil t)pour charger ces paramètres, mais ne commet jamais local.el.

Paquets gérés par le gestionnaire de paquets

Lorsque les packages sont gérés par le gestionnaire de packages, je suggère de ne pas les mettre dans le contrôle de source. Parce que :

1. Vous devez vous engager après chaque mise à jour.
2. Vous pouvez rater des fichiers importants stockés ailleurs, ce qui vous empêche de synchroniser correctement sur différents ordinateurs.

Au lieu de valider des paquets, je vous suggère de valider le mécanisme reconnu par votre gestionnaire de paquets.

Par exemple, j'utilise Cask pour gérer mes 3ème paquetages, donc je ne valide que le fichier cask, qui contient les paquets que je veux.

Lorsque j'utilise package.elavant, ma configuration vérifie si le paquet est installé / doit être mis à jour, ainsi aucun paquet n'est validé.

Cependant , il existe des packages qui n'existent dans aucun référentiel de packages, dans ce cas, je les commettrai dans le contrôle de code source, comme dans site-lisp.

Tous les fichiers générés par les packages

Par exemple, tous les AutoSave, les fichiers de sauvegarde, tramp, eshell, recentf, même custom.el. Je mets ces fichiers dans ~/.emacs/.gen, donc je peux simplement ignorer ce répertoire.

Fichiers qui changent fréquemment mais qui doivent être synchronisés

Tels qu'un fichier de dictionnaire personnel utilisé par aspell, une base de données de fichiers utilisée par elfeed, Dans ce cas, j'utilise Dropbox pour le synchroniser sur différents ordinateurs. Donc je n'oublierai pas de m'engager.

Assurez-vous simplement qu'aucun élément généré (comme les notes @ rangi-lin) ne se trouve dans le référentiel et, si vous partagez vos fichiers de points avec d'autres personnes, aucun élément de sécurité associé (comme les mots de passe et les clés d'API). Pour les versions ultérieures, j'ai divisé mes personnalisations dans un fichier séparé avec:

(setq custom-file (concat dotfiles-dir "custom.el"))
(load custom-file 'noerror)

Parfois, je déplace les personnalisations "sûres" vers une grosse setqdéclaration avant l'extrait de code ci-dessus.

Mon fichier .gitignore ressemble à:

/.org-id-locations
/ac-comphist.dat
/auto-save-list
/custom.el
/elpa/*
/image-dired/
/oauth2.plstore
/session.*
/tramp
/url/
/var/
*.elc

tl; dr

• utiliser .emacs.d/init.elau lieu de.emacs
• faites votre .gitignoreune liste blanche
• utiliser un gestionnaire de paquets

.emacs.d / init.el

J'utilise à la .emacs.d/init.elplace de .emacspuisque cette configuration me permet de mettre .emacs.dsous git. Cela ~/.emacsvous permet de créer un lien symbolique vers le référentiel git ou d’avoir git repo dans votre répertoire personnel. Si vous utilisez .emacs.d, tout est résolu.

.gitignore

Mon .gitignore est une liste blanche au lieu de la liste noire par défaut.

*

!.gitignore
!init.el

Cette configuration vous permet de vous concentrer sur ce dont vous avez vraiment besoin au lieu de ce dont vous n’avez pas besoin. .emacs.dn’est pas comme le référentiel de code source, ce qui signifie que non seulement votre code réside, mais également tous les autres fichiers générés automatiquement ou temporaires. Vous ne savez pas vraiment ce qui va se passer. Donc, " tout ignorer par défaut et ajouter des fichiers qui vous intéressent " est une meilleure stratégie, IMO.

BTW, je garde la plupart de la configuration dans le init.el, au lieu d'utiliser un schéma multi-fichier. La raison en est qu’un gros fichier me permet a) d’utiliser des outils standard tels que occurou isearch-forwardde passer à la configuration que je veux, b) d’utiliser outshinece qui rend mon init.el org-cycle-able, c) ne pas le changer .gitignoretout le temps.

Directeur chargé d'emballage

Sauf si vous avez des besoins particuliers en matière de synchronisation de la version Emacs et / ou de la version des packages sur tout votre système, ne mettez pas les packages dans git. Package.elc'est bien. use-packageest aussi bien. Le fût est gentil. Choisissez votre gestionnaire de paquets et validez uniquement votre fichier de configuration mais pas le paquet lui-même.

c'est à dire. L'un des besoins particuliers auquel je peux penser serait d'avoir deux systèmes, un développement et un déploiement, et ils doivent avoir exactement la même configuration Emacs.

J'ai les choses suivantes dans mon .hgignore

• fichier serveur emacs
• recentf file: Les chemins de fichiers sur une machine n'ont pas de sens sur une autre
• Répertoire elpa / melpa: utilisez le fichier init pour installer automatiquement les packages requis et enregistrer les temps de réponse.

Si vous souhaitez partager votre init avec d'autres personnes, vous pouvez envisager de supprimer tous les fichiers d'historique tels que celui créé par le mode savehist. En dehors de cela, je ne pense pas qu’il existe des astuces particulières. Toutes les instructions que vous suivez pour les projets de code de version fonctionnent également ici.

Au fil du temps, les forfaits ajoutent beaucoup d'éléments ~/.emacset je finis par les ajouter un à un à mes fichiers .gitignore. J'ai aussi un private.elqui contient les mots de passe, le code spécifique à la machine, etc. que je ne dépiste pas.

C'est ce que j'ai maintenant.

# Gitignore file

# Remove backup files
*#
*.
*.elc
*~
.#*

# Emacs packages
elpa/
var/

#  Emacs tmp files & Misc
/.mc-lists.el
/.DS_Store
/.emacs.desktop
/.emacs.desktop.lock
/.watsonresults
/ac-comphist.dat
/auto-save-list
/eshell/history
/eshell/lastdir
/newsticker/feeds/
/snippets/
/tramp
/url/cookies
/.python-environments/
/ido.last
/places
/private.el
/games/
/bookmarks
/projectile-bookmarks.eld
/projectile.cache

Cela dépend des packages / fonctionnalités que vous utilisez, cela peut donc être délicat. Outre les fichiers mentionnés par Vamsi, par exemple, si vous utilisez dired-immage, un répertoire est créé pour y mettre les vignettes en cache. Vous voudrez probablement également ignorer les fichiers .elc.

Je publie mon fichier .emacs.d, mais j'utilise un subrepo avec les modifications privées (mots de passe, etc.). Pour permettre aux autres de le cloner, la branche par défaut pointe vers un subrepo de marque de réservation et chaque machine a sa propre branche nommée.

Lors de la fusion entre des machines, je commence par intégrer graftles nouvelles modifications dans la defaultbranche, puis par la fusion defaultdans les autres branches du lieu de travail.

Par exemple, vous pouvez trouver mon fichier .emacs.d sur bitbucket , y compris un fichier lisez-moi avec un guide d'utilisation succinct.

Vous voudrez peut-être ajouter le pilote de fusion en mode org à cette configuration.

Après plusieurs itérations, j'ai déterminé que, si le contrôle de version est très pratique pour partager le code et suivre les modifications, ce n'est pas une excellente solution pour synchroniser une configuration en constante évolution sur plusieurs ordinateurs. La raison en est qu'il y a beaucoup de choses qui devraient être synchronisées et ne devraient pas être dans le contrôle de version. Quelques exemples:

1. .elcfichiers (les recompiler en cas de modification de la configuration est un problème majeur, et les bogues provenant de elcfichiers obsolètes sont souvent difficiles à déboguer).
2. L’ensemble du elparépertoire (et jusqu’à ce que l’épinglage de version devienne standard, sa reconstruction automatique n’est tout simplement pas assez fiable).
3. Fichiers générés automatiquement, tels que l' eshellhistorique et les gnusfichiers.
4. Informations privées telles que mots de passe et clés API.

(Notez que les problèmes multi-plateformes ne figurent pas dans la liste - il devrait être parfaitement correct d'avoir une configuration qui fonctionne sur plusieurs systèmes d'exploitation.) Au lieu d'utiliser git comme solution de synchronisation, je l'utilise uniquement comme solution de suivi de code. et synchroniser en utilisant Dropbox. Ainsi, tous les fichiers gênants qui ne devraient pas figurer dans le contrôle de version sont pris en charge.

Je ne , cependant, ont un objectif d'avoir ma configuration être reconditionné de source si ma configuration de Dropbox disparaît pour une raison quelconque, je garde une trace de tous les paquets installés et ainsi de suite dans la source. Mes informations personnelles sont également stockées dans un sous-module git. Mais pour la synchronisation au quotidien, git n'est tout simplement pas une bonne solution.