¿Qué debo / no debo hacer al mantener .emacs y .emacs.d en el control de versiones?

Como muchas personas, administro muchos de mis archivos de puntos a través de un repositorio de control de versiones (Mercurial en Bitbucket, privado, en mi caso). Esto es útil cuando se configura una nueva máquina o se propagan configuraciones entre diferentes máquinas.

Así que, naturalmente, agregué mi .emacsy .emacs.da esta configuración.

Luego instalé algunos paquetes y terminé agregando *.elca mi .hgignore, al igual que omito *.pycarchivos de mis repositorios de Python.

¿Hay otras cosas que no debería rastrear, por ejemplo, archivos generados que son específicos del entorno y que no serán útiles / correctos cuando se clonen a otra plataforma? (Uso Linux y OS X en el escritorio y FreeBSD en el servidor).

¿Hay algún truco de configuración que se use comúnmente para hacer que este tipo de intercambio sea más valioso? Con la configuración de mi archivo de shell, todavía estoy buscando buenas formas de seleccionar archivos individuales a través de ramas, por ejemplo.

Almaceno mi configuración de Emacs en Github porque uso dos computadoras diferentes, una en el trabajo y otra en casa.

Aquí hay una lista de cosas que no pongo en el control de código fuente:

Entornos de configuraciones especificadas.

Por ejemplo, mis Emacs abren diferentes archivos de organización al inicio en diferentes máquinas. No desea comprometer esta configuración en el control de origen.

Yo uso (require 'local nil t)para cargar estas configuraciones, pero nunca me comprometo local.el.

Paquetes gestionados por el administrador de paquetes

Cuando los paquetes son administrados por el administrador de paquetes, sugiero no poner esos paquetes en control de origen. Porque :

1. Tienes que comprometerte después de cada actualización.
2. Puede perder archivos importantes que se almacenan en otro lugar, lo que hace que no pueda sincronizarse correctamente en diferentes computadoras.

En lugar de confirmar paquetes, le sugiero que confirme el mecanismo reconocido por su administrador de paquetes.

Por ejemplo, uso Cask para administrar mis paquetes 3, así que solo confirmo el archivo cask, que contiene los paquetes especificados que quiero.

Cuando lo uso package.elantes, mi configuración verificará si el paquete está instalado / necesita actualizarse, por lo que no se confirma ningún paquete.

Sin embargo , hay algunos paquetes que no existen en ningún repositorio de paquetes, en este caso, lo comprometeré con el control de origen, como en site-lisp.

Todos los archivos generados por paquetes

Por ejemplo, toda la copia de seguridad automática, los archivos de copia de seguridad, tramp, eshell, recentf, incluso custom.el. Puse estos archivos en ~/.emacs/.gen, por lo que puedo ignorar este directorio.

Archivos que cambian con frecuencia pero que deben sincronizarse

Como el archivo de diccionario personal utilizado por aspell, la base de datos de archivos utilizada por elfeed, en este caso, uso Dropbox para sincronizarlo en diferentes computadoras. Entonces no me olvidaré de comprometerme.

Solo asegúrese de que no haya cosas generadas (como @ rangi-lin notes) en el repositorio y, si está compartiendo sus archivos de puntos con otros, no hay cosas de seguridad relacionadas (como contraseñas y claves API). Para más adelante, he dividido mis personalizaciones en un archivo separado con:

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

Ocasionalmente muevo personalizaciones "seguras" a una gran setqdeclaración antes del fragmento de arriba.

Mi archivo .gitignore se ve así:

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

tl; dr

• usar en .emacs.d/init.ellugar de.emacs
• haz tu .gitignorelista blanca
• usar un administrador de paquetes

.emacs.d / init.el

Lo uso en .emacs.d/init.ellugar de .emacsya que esta configuración me permite ponerlo .emacs.dbajo git. Tener ~/.emacste hace crear un enlace simbólico al repositorio de git o tener un repositorio de git en tu directorio de inicio. Si lo usas .emacs.d, todo está resuelto.

.gitignore

Mi .gitignore es una lista blanca en lugar de la lista negra predeterminada.

*

!.gitignore
!init.el

Esta configuración le permite concentrarse en lo que realmente necesita en lugar de lo que no necesita. .emacs.dno es como el repositorio de código fuente, lo que significa que no solo reside su código sino que también todos los demás archivos generados automáticamente o temporales van allí. Realmente no sabes lo que pasará. Entonces, " ignora todo de manera predeterminada y agrega los archivos que te interesan " es una mejor estrategia, en mi opinión.

Por cierto, mantengo la mayor parte de la configuración en init.el, en lugar de usar el esquema de varios archivos. La razón es que un archivo grande me permite a) usar herramientas estándar como occuro isearch-forwardmoverme a la configuración que quiero, b) usar lo outshineque hace que mi init.el org-cycle-able, c) no cambie mi .gitignoretodo el tiempo.

Gerente de empaquetación

A menos que tenga necesidades especiales para sincronizar la versión de Emacs y / o la versión de paquetes en todo su sistema, no coloque los paquetes en git. Package.elestá bien. use-packageTambién está bien. Barril es agradable. Elija su administrador de paquetes y confirme solo su archivo de configuración, pero no el paquete en sí.

es decir. Una de las necesidades especiales en las que puedo pensar sería tener dos sistemas, un desarrollo y una implementación, y deben tener exactamente la misma configuración de Emacs.

Tengo las siguientes cosas en mi .hgignore

• archivo del servidor emacs
• archivo reciente: las rutas de archivo en una máquina no tienen sentido en otra
• Directorio elpa / melpa: use el archivo init para instalar automáticamente los paquetes requeridos y guardar los tiempos de extracción / inserción.

Si desea compartir su init con otros, puede considerar eliminar cualquier archivo de historial como el creado por el modo savehist. Aparte de eso, no creo que haya ningún truco especial para esto. Todas las pautas que siga para los proyectos de código de versiones funcionan bien aquí también.

Con el tiempo, los paquetes agregan muchas cosas ~/.emacsy termino agregándolas una por una a mi .gitignore. También tengo uno private.elque contiene contraseñas, código específico de la máquina, etc., que no rastreé.

Esto es lo que tengo ahora.

# 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

Depende de los paquetes / características que utilice, por lo que puede ser complicado. Además de los archivos mencionados por Vamsi, por ejemplo, si usa dired-immage, crea un directorio allí para almacenar en miniatura las miniaturas. Probablemente quiera ignorar los archivos .elc también.

Publico mi .emacs.d, pero uso un subrepo con los cambios privados (contraseñas y demás). Para permitir que otros lo clonen, la rama predeterminada apunta a un subrepo de marcador de posición, y cada máquina tiene su propia rama con nombre.

Al fusionar entre máquinas, primero graftlos nuevos cambios en la defaultrama y luego fusiono la defaultrama con las otras ramas del lugar de trabajo.

Como ejemplo, puede encontrar mi .emacs.d en bitbucket , incluido un archivo Léame con una breve guía de uso.

Es posible que desee agregar el controlador de combinación del modo org a esta configuración.

Después de varias iteraciones, he determinado que, si bien el control de versiones es excelente para compartir código y rastrear cambios, no es una excelente solución para sincronizar una configuración que cambia rápidamente en las computadoras. La razón es que hay muchas cosas que deberían sincronizarse y no deberían estar en el control de versiones. Algunos ejemplos:

1. .elcarchivos (recompilarlos cuando hay un cambio de configuración es una molestia importante, y los errores de los elcarchivos obsoletos a menudo son difíciles de depurar).
2. Todo el elpadirectorio (y hasta que la fijación de versiones se vuelva estándar, la reconstrucción automática simplemente no es lo suficientemente confiable).
3. Archivos autogenerados como eshellhistorial y gnusarchivos.
4. Información privada como contraseñas y claves API.

(Tenga en cuenta que los problemas multiplataforma no están en la lista; debería estar perfectamente bien tener una configuración que funcione en múltiples sistemas operativos). En lugar de usar git como una solución de sincronización, lo uso únicamente como una solución de seguimiento de código y sincronizar usando Dropbox. De esa forma, se ocupan todos los archivos molestos que no deberían estar en el control de versiones.

Yo no , sin embargo, tienen el objetivo de tener la configuración de mi ser reparables de la fuente si mi configuración de Dropbox desaparece por cualquier razón, así que mantener un registro de todos los paquetes instalados y otras cosas en la fuente. Mi información privada también se almacena en un submódulo git. Pero para la sincronización diaria, git simplemente no es una gran solución.