Cosa dovrei / non dovrei fare mantenendo .emacs e .emacs.d sotto controllo di versione?

Come molte persone, gestisco molti dei miei dotfile tramite un repository di controllo versione (Mercurial su Bitbucket, privato, nel mio caso). Ciò è utile quando si configura una nuova macchina o si propagano le configurazioni tra macchine diverse.

Quindi, naturalmente, ho aggiunto il mio .emacse .emacs.da questa configurazione.

Quindi ho installato alcuni pacchetti e ho finito con l'aggiunta *.elcal mio .hgignore, proprio come ho omesso i *.pycfile dai miei repository Python.

Ci sono altre cose che non dovrei tenere traccia, ad esempio i file generati che sono specifici dell'ambiente e che non saranno utili / corretti se clonati su un'altra piattaforma? (Uso Linux e OS X sul desktop e FreeBSD sul server.)

Esistono trucchi per la configurazione che vengono comunemente utilizzati per rendere questo tipo di condivisione più prezioso? Con la mia configurazione dei file shell, sto ancora cercando buoni modi per selezionare i singoli file tra i rami, ad esempio.

Conservo la mia configurazione di Emacs in Github perché uso due computer diversi, uno al lavoro e uno a casa.

Ecco un elenco di cose che non metto nel controllo del codice sorgente:

Configurazioni specificate nell'ambiente.

Ad esempio, i miei Emacs aprono file organizzativi diversi all'avvio su macchine diverse. Non vuoi impegnare queste impostazioni nel controllo del codice sorgente.

Uso (require 'local nil t)per caricare queste impostazioni, ma non mi impegno mai local.el.

Pacchetti gestiti dal gestore pacchetti

Quando i pacchetti sono gestiti dal gestore pacchetti, suggerisco di non metterli nel controllo del codice sorgente. Perché :

1. Devi impegnarti dopo ogni aggiornamento.
2. Puoi perdere importanti file archiviati da qualche altra parte, che ti rendono incapace di sincronizzare correttamente su diversi computer.

Invece di impegnare i pacchetti, ti suggerisco di impegnare il meccanismo riconosciuto dal gestore dei pacchetti.

Ad esempio, utilizzo Cask per gestire i miei 3 pacchetti, quindi commetto solo il file cask, che contiene i pacchetti specificati che desidero.

Quando lo utilizzo in package.elprecedenza, la mia configurazione verificherà se il pacchetto è installato / deve essere aggiornato, quindi nessun pacchetto viene eseguito il commit.

Tuttavia , ci sono alcuni pacchetti che non esistono in nessun repository di pacchetti, in questo caso lo commetterò al controllo del codice sorgente, come in site-lisp.

Tutti i file generati dai pacchetti

Ad esempio, tutte le salvataggio automatico, i file di backup, tramp, eshell, recentf, anche custom.el. Ho inserito questi file ~/.emacs/.gen, quindi posso semplicemente ignorare questa directory.

File che cambiano frequentemente ma devono essere sincronizzati

Come file di dizionario personale utilizzato da aspell, database di file utilizzato da elfeed, In questi casi, utilizzo Dropbox per sincronizzarlo su computer diversi. Quindi non dimenticherò di impegnarmi.

Assicurati solo che nessun oggetto generato (come @ rangi-lin notes) sia nel repository e, se condividi i tuoi dotfile con altri, nessun elemento relativo alla sicurezza (come password e chiavi API). Per il momento ho diviso le mie personalizzazioni in un file separato con:

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

Occasionalmente sposto personalizzazioni "sicure" su una grande setqaffermazione prima dello snippet sopra.

Il mio file .gitignore è simile a:

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

tl; dr

• utilizzare .emacs.d/init.elinvece di.emacs
• fai della tua .gitignoreuna lista bianca
• usa un gestore di pacchetti

.emacs.d / init.el

Uso .emacs.d/init.elinvece che da .emacsquando questa configurazione mi permette di mettere .emacs.dsotto git. Avere ~/.emacsti costringe a creare un link simbolico al repository git o ad avere repository git nella tua directory home. Se usi .emacs.d, tutto è risolto.

.gitignore

Il mio .gitignore è una lista bianca invece della lista nera predefinita.

*

!.gitignore
!init.el

Questa configurazione ti consente di concentrarti su ciò di cui hai veramente bisogno anziché su ciò che non ti serve. .emacs.dnon è come un repository di codice sorgente, il che significa che non solo risiede il tuo codice ma anche tutti gli altri file generati automaticamente o temporanei vanno lì. Non sai davvero cosa succederà. Quindi, " ignora tutto per impostazione predefinita e aggiungi i file che ti interessano " è una strategia migliore, IMO.

A proposito, mantengo la maggior parte della configurazione in init.el, invece di utilizzare lo schema multi-file. Il motivo è che un file di grandi dimensioni mi consente di a) utilizzare strumenti standard come occuro isearch-forwardper passare alla configurazione che desidero, b) usare ciò outshineche rende il mio init.el org-cycle-able, c) non cambiare il mio .gitignoretutto il tempo.

Gestore pacchetti

A meno che tu non abbia particolari esigenze per sincronizzare la versione di Emacs o la versione di Pacchetti su tutto il tuo sistema, non mettere i pacchetti sotto git. Package.elè ok. use-packageva anche bene. Cask è carino. Scegli il gestore dei pacchetti e impegna solo il tuo file di configurazione ma non il pacchetto stesso.

vale a dire. Una delle esigenze speciali a cui riesco a pensare sarebbe quella di avere due sistemi, uno sviluppo e una distribuzione e devono avere esattamente la stessa configurazione Emacs.

Ho le seguenti cose nel mio .hgignore

• file server emacs
• file recentf: i percorsi dei file su una macchina non hanno senso su un'altra
• directory elpa / melpa: utilizzare il file init per installare automaticamente i pacchetti richiesti e salvare i tempi di pull / push.

Se vuoi condividere il tuo init con altri, potresti prendere in considerazione la rimozione di qualsiasi file della cronologia come quello creato dalla modalità savehist. A parte questo, non credo che ci siano trucchi speciali per questo. Tutte le linee guida che segui per i progetti di codice di versione funzionano bene anche qui.

Nel tempo i pacchetti aggiungono molte cose ~/.emacse finisco per aggiungerli uno alla volta al mio .gitignore. Ho anche un file private.elche contiene password, codice specifico della macchina ecc. Che non tengo traccia.

Questo è quello che ho adesso.

# 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

Dipende dai pacchetti / funzionalità che usi, quindi può diventare complicato. Oltre ai file menzionati da Vamsi, ad esempio, se usi dired-immage, crea una directory lì per memorizzare nella cache le anteprime. Probabilmente vuoi ignorare anche i file .elc.

Pubblico il mio .emacs.d, ma uso un sottorepo con le modifiche private (password e simili). Per consentire ad altri di clonarlo, il ramo predefinito punta a un sottorepo segnaposto e ogni macchina ha il proprio ramo denominato.

Quando mi unisco tra le macchine, prima graftinserisco le nuove modifiche nel defaultramo e quindi unisco il defaultramo negli altri rami del posto di lavoro.

Ad esempio, puoi trovare il mio .emacs.d su bitbucket , incluso un readme con una breve guida all'uso.

Potresti voler aggiungere il driver di unione in modalità organizzazione a questa configurazione.

Dopo diverse iterazioni, ho stabilito che, sebbene il controllo della versione sia ottimo per condividere il codice e tenere traccia delle modifiche, non è un'ottima soluzione per sincronizzare una configurazione in rapida evoluzione tra i computer. Il motivo è che ci sono molte cose che dovrebbero essere sincronizzate e non dovrebbero essere nel controllo della versione. Qualche esempio:

1. .elcfile (ricompilarli quando si verifica una modifica della configurazione è una seccatura maggiore, e i bug di elcfile obsoleti sono spesso una seccatura per il debug).
2. L'intera elpadirectory (e fino a quando il pinning della versione non diventa standard, ricostruirlo automaticamente non è abbastanza affidabile).
3. File generati automaticamente come eshellcronologia e gnusfile.
4. Informazioni private come password e chiavi API.

(Si noti che i problemi multipiattaforma non sono nell'elenco: dovrebbe essere perfettamente corretto avere una configurazione che funzioni su più sistemi operativi.) Invece di usare git come soluzione di sincronizzazione, la uso esclusivamente come soluzione di tracciamento del codice e sincronizzare utilizzando Dropbox. In questo modo vengono curati tutti i file fastidiosi che non dovrebbero essere nel controllo della versione.

Io faccio , però, ho un obiettivo di avere la mia configurazione sia ricostruibile dalla fonte, se la mia configurazione Dropbox scompare per qualsiasi motivo, così ho tenere traccia di tutti i pacchetti installati e quant'altro nel sorgente. Le mie informazioni private sono archiviate anche in un sottomodulo git. Ma per la sincronizzazione quotidiana, git non è proprio un'ottima soluzione.