Was soll / soll ich nicht tun, wenn .emacs und .emacs.d in der Versionskontrolle bleiben?

Wie viele andere auch verwalte ich viele meiner Punktedateien über ein Versionskontroll-Repository (in meinem Fall Mercurial on Bitbucket, privat). Dies ist praktisch, wenn Sie eine neue Maschine einrichten oder Konfigurationen auf verschiedene Maschinen übertragen.

Also habe ich natürlich mein .emacsund .emacs.dzu diesem Setup hinzugefügt .

Dann installierte ich einige Pakete und fügte sie *.elczu meinen hinzu .hgignore, genauso wie ich *.pycDateien aus meinen Python-Repos weglasse .

Gibt es andere Dinge, die ich nicht verfolgen sollte, z. B. generierte Dateien, die umgebungsspezifisch sind und beim Klonen auf eine andere Plattform nicht nützlich / korrekt sind? (Ich verwende Linux und OS X auf dem Desktop und FreeBSD auf dem Server.)

Gibt es Setup-Tricks, die üblicherweise verwendet werden, um diese Art des Teilens wertvoller zu machen? Bei der Einrichtung meiner Shell-Datei suche ich immer noch nach guten Möglichkeiten, um beispielsweise einzelne Dateien über Zweige hinweg auszuwählen.

Ich speichere meine Emacs-Konfiguration in Github, weil ich zwei verschiedene Computer verwende, einen bei der Arbeit, einen zu Hause.

Hier ist eine Liste über Dinge, die ich nicht in die Quellcodeverwaltung gesteckt habe:

Umgebungsspezifische Setups.

Beispielsweise öffnen meine Emacs beim Start auf einem anderen Computer eine andere Organisationsdatei. Sie möchten diese Einstellungen nicht in die Quellcodeverwaltung übernehmen.

Ich verwende (require 'local nil t)diese Einstellungen zum Laden, aber verpflichte mich nie local.el.

Pakete, die vom Paketmanager verwaltet werden

Wenn Pakete vom Paketmanager verwaltet werden, empfehle ich, diese Pakete nicht der Quellcodeverwaltung zu unterstellen. Weil :

1. Sie müssen nach jedem Update ein Commit durchführen.
2. Sie können wichtige Dateien übersehen, die an einem anderen Ort gespeichert sind. Dadurch können Sie nicht mehr ordnungsgemäß zwischen verschiedenen Computern synchronisieren.

Ich schlage vor, anstelle von Commit-Paketen den von Ihrem Paketmanager erkannten Mechanismus zu verwenden .

Zum Beispiel verwalte ich meine dritten Pakete mit Cask , so dass ich nur die Cask-Datei festschreibe, die die angegebenen gewünschten Pakete enthält.

Bei der vorherigen Verwendung package.elüberprüft meine Konfiguration, ob das Paket installiert ist bzw. aktualisiert werden muss, sodass kein Paket festgeschrieben wird.

Es gibt jedoch einige Pakete, die in keinem Paket-Repository vorhanden sind. In diesem Fall übergebe ich sie der Quellcodeverwaltung, z. B. in site-lisp.

Alle von Paketen generierten Dateien

Zum Beispiel können alle die automatische Speicherung, Backup - Dateien, tramp, eshell, recentf, auch custom.el. Ich habe diese Dateien in ~/.emacs/.gen, so dass ich dieses Verzeichnis einfach ignorieren kann.

Dateien, die häufig geändert werden, jedoch synchronisiert werden müssen

Wie persönliche durch verwendete Wörterbuchdatei aspell, Datei - Datenbank verwendet elfeed, In diesen Fällen verwende ich Dropbox , um es auf verschiedene Computer synchronisiert. Also werde ich nicht vergessen, mich zu verpflichten.

Stellen Sie einfach sicher, dass keine generierten Inhalte (wie @ rangi-lin-Notizen) im Repo sind und, wenn Sie Ihre Punktedateien mit anderen teilen, keine verwandten Sicherheitsprodukte (wie Passwörter und API-Schlüssel). Für später habe ich meine Anpassungen in eine separate Datei aufgeteilt mit:

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

Gelegentlich verschiebe ich "sichere" Anpassungen zu einer großen setqAussage vor dem obigen Ausschnitt.

Meine .gitignore-Datei sieht folgendermaßen aus:

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

tl; dr

• Verwenden Sie .emacs.d/init.elanstelle von.emacs
• Machen Sie Ihre .gitignoreeine weiße Liste
• benutze einen Paketmanager

.emacs.d / init.el

Ich benutze .emacs.d/init.elstatt, .emacsda dieses Setup mir erlaubt, .emacs.dunter Git zu setzen . Mit können ~/.emacsSie einen symbolischen Link zum Git-Repository erstellen oder Git-Repo in Ihrem Home-Verzeichnis haben. Wenn Sie verwenden .emacs.d, ist alles gelöst.

.gitignore

Mein .gitignore ist eine weiße Auflistung anstelle der standardmäßigen schwarzen Auflistung.

*

!.gitignore
!init.el

Mit dieser Konfiguration können Sie sich auf das konzentrieren, was Sie wirklich brauchen, anstatt auf das, was Sie nicht brauchen. .emacs.dist nicht wie ein Quellcode-Repository, was bedeutet, dass nicht nur Ihr Code gespeichert ist, sondern auch alle anderen automatisch generierten oder temporären Dateien dort abgelegt werden. Sie wissen nicht genau, wie es weitergeht. " Ignorieren Sie alle Dateien standardmäßig und fügen Sie die gewünschten Dateien hinzu " ist die bessere Strategie, IMO.

Übrigens behalte ich den größten Teil der Konfiguration in der init.el, anstatt das Schema mit mehreren Dateien zu verwenden. Der Grund dafür ist, dass eine große Datei es mir ermöglicht, a) Standardwerkzeuge zu verwenden occuroder isearch-forwardzu der gewünschten Konfiguration zu wechseln, b) das zu verwenden outshine, was meine init.el org-cycle-fähig macht , c) meine nicht die .gitignoreganze Zeit zu ändern .

Paket-Manager

Stellen Sie keine Pakete unter git, es sei denn, Sie müssen Emacs-Version und / oder Paketversion auf Ihrem gesamten System synchronisieren . Package.elist gut. use-packageist auch in Ordnung. Fass ist schön. Wählen Sie Ihren Paketmanager aus und übergeben Sie nur Ihre Konfigurationsdatei, nicht das Paket selbst.

dh Eine der besonderen Anforderungen, die ich mir vorstellen kann, wäre, zwei Systeme zu haben, eine Entwicklung und eine Bereitstellung, und sie müssen genau dieselbe Emacs-Konfiguration haben.

Ich habe die folgenden Dinge in meinem .hgignore

• Emacs-Server-Datei
• recentf-Datei: Dateipfade auf einem Computer sind auf einem anderen nicht sinnvoll
• elpa / melpa-Verzeichnis: Verwenden Sie die init-Datei, um die erforderlichen Pakete automatisch zu installieren und Pull- / Push-Zeiten zu speichern.

Wenn Sie Ihre Init-Datei für andere Benutzer freigeben möchten, sollten Sie möglicherweise Verlaufsdateien entfernen, z. B. die, die im Modus "Speichern" erstellt wurden. Abgesehen davon glaube ich nicht, dass es irgendwelche besonderen Tricks gibt. Alle Richtlinien, die Sie für die Versionierung von Code-Projekten befolgen, funktionieren auch hier.

Im Laufe der Zeit fügen Pakete eine Menge Dinge hinzu ~/.emacsund am Ende füge ich sie einer nach dem anderen zu meinen hinzu .gitignore. Ich habe auch eine, private.eldie Passwörter, maschinenspezifische Codes usw. enthält, die ich nicht verfolge.

Das habe ich jetzt.

# 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

Es hängt davon ab, welche Pakete / Funktionen Sie verwenden, daher kann es schwierig werden. Wenn Sie beispielsweise dired-immage verwenden, wird neben den von Vamsi erwähnten Dateien ein Verzeichnis erstellt, in dem Miniaturansichten zwischengespeichert werden. Möglicherweise möchten Sie auch .elc-Dateien ignorieren.

Ich veröffentliche meine .emacs.d, benutze aber ein Subrepo mit den privaten Änderungen (Passwörter und so). Damit andere Benutzer es klonen können, verweist der Standardzweig auf ein Platzhaltersubrep und jeder Computer verfügt über einen eigenen benannten Zweig.

Beim Zusammenführen von Maschinen füge ich zuerst graftdie neuen Änderungen in der defaultZweigstelle und dann die defaultZweigstelle in den anderen Zweigstellen am Arbeitsplatz zusammen.

Als Beispiel finden Sie meine .emacs.d auf bitbucket , einschließlich einer Readme- Datei mit einer kurzen Bedienungsanleitung .

Möglicherweise möchten Sie den Zusammenführungstreiber für den Organisationsmodus zu diesem Setup hinzufügen .

Nach mehreren Iterationen habe ich festgestellt, dass die Versionskontrolle zwar hervorragend zum Teilen von Code und zum Nachverfolgen von Änderungen geeignet ist, nicht jedoch zum Synchronisieren einer sich schnell ändernden Konfiguration auf mehreren Computern. Der Grund dafür ist , dass es viele Dinge , die sollte synchronisiert werden und sollten nicht in der Versionskontrolle sein. Einige Beispiele:

1. .elcDateien (das erneute Kompilieren bei Konfigurationsänderungen ist ein großer Aufwand, und Fehler in veralteten elcDateien sind häufig ein Problem beim Debuggen).
2. Das gesamte elpaVerzeichnis (und bis das Versions-Pinning zum Standard wird, ist es nicht zuverlässig genug, es automatisch neu zu erstellen).
3. Automatisch generierte Dateien wie eshellVerlauf und gnusDateien.
4. Private Informationen wie Kennwörter und API-Schlüssel.

(Beachten Sie, dass plattformübergreifende Probleme nicht in der Liste aufgeführt sind. Es sollte in Ordnung sein, eine Konfiguration zu haben, die auf mehreren Betriebssystemen funktioniert.) Anstatt git als Synchronisierungslösung zu verwenden, verwende ich sie ausschließlich als Code-Tracking-Lösung und synchronisieren mit Dropbox. Auf diese Weise werden alle lästigen Dateien behoben, die nicht in der Versionskontrolle enthalten sein sollten.

Ich habe jedoch das Ziel, dass meine Konfiguration aus dem Quellcode wiederhergestellt werden kann, wenn meine Dropbox-Konfiguration aus irgendeinem Grund verschwindet. Daher verfolge ich alle installierten Pakete und alles, was nicht im Quellcode enthalten ist. Meine privaten Informationen werden ebenfalls in einem Git-Modul gespeichert. Für die tägliche Synchronisierung ist Git jedoch keine großartige Lösung.