Co powinienem / nie powinienem robić, gdy przechowuję .emacs i .emacs.d w kontroli wersji?

Podobnie jak wiele osób, zarządzam wieloma plikami dotfiles za pośrednictwem repozytorium kontroli wersji (w moim przypadku Mercurial na Bitbucket, prywatny). Jest to przydatne podczas konfigurowania nowej maszyny lub propagowania konfiguracji między różnymi maszynami.

Więc oczywiście dodałem mój .emacsi .emacs.ddo tego zestawu.

Potem zainstalowałem kilka pakietów i dodałem *.elcdo siebie .hgignore, tak jak pomijam *.pycpliki z repozytoriów Pythona.

Czy są inne rzeczy, których nie powinienem śledzić, np. Generowane pliki, które są specyficzne dla środowiska i nie będą użyteczne / poprawne po sklonowaniu na inną platformę? (Używam Linuxa i OS X na pulpicie, a FreeBSD na serwerze.)

Czy są jakieś sztuczki związane z konfiguracją, które są powszechnie stosowane, aby udostępnianie tego rodzaju było bardziej wartościowe? Z moją konfiguracją plików powłoki wciąż szukam dobrych sposobów, aby na przykład wybierać pojedyncze pliki między gałęziami.

Przechowuję moją konfigurację Emacsa w Github, ponieważ używam dwóch różnych komputerów, jednego w pracy, jednego w domu.

Oto lista rzeczy, których nie poddaję kontroli źródła:

Ustawienia określone przez środowisko.

Na przykład, mój Emacs otwiera inny plik org podczas uruchamiania na innym komputerze. Nie chcesz zatwierdzać tych ustawień w celu kontroli źródła.

Używam (require 'local nil t)do ładowania tych ustawień, ale nigdy nie zatwierdzam local.el.

Pakiety zarządzane przez menedżera pakietów

Gdy pakietami zarządza menedżer pakietów, sugeruję nie poddawać tych pakietów kontroli źródła. Dlatego :

1. Musisz zatwierdzić po każdej aktualizacji.
2. Możesz pominąć ważny plik przechowywany gdzie indziej, co uniemożliwi prawidłową synchronizację między różnymi komputerami.

Zamiast zatwierdzać pakiety, sugeruję zatwierdzić mechanizm rozpoznany przez menedżera pakietów.

Na przykład używam Cask do zarządzania moimi 3. pakietami, więc zatwierdzam tylko plik cask, który zawiera określone pakiety, które chcę.

Kiedy używam package.elwcześniej, moja konfiguracja sprawdzi, czy pakiet jest zainstalowany / czy wymaga aktualizacji, więc żaden pakiet nie jest zatwierdzony.

Jednak istnieją pewne pakiety, które nie istnieją w żadnym repozytorium pakietów, w tym przypadku przekażę je do kontroli źródła, na przykład w site-lisp.

Wszystkie pliki generowane przez pakiety

Na przykład, wszystkie autozapis, pliki kopii zapasowych, tramp, eshell, recentf, nawet custom.el. Wrzucam te pliki ~/.emacs/.gen, więc mogę po prostu zignorować ten katalog.

Pliki, które często się zmieniają, ale wymagają synchronizacji

Takich jak osobisty plik słownika używany przez aspellbazę danych plików używaną przez. elfeedW takim przypadku używam Dropbox do synchronizacji między różnymi komputerami. Więc nie zapomnę popełnić.

Po prostu upewnij się, że w repozytorium nie ma żadnych wygenerowanych rzeczy (takich jak @ rangi-lin notes), a jeśli udostępniasz swoje pliki dotf innym osobom, nie ma powiązanych zabezpieczeń (takich jak hasła i klucze API). Później podzieliłem moje dostosowania na osobny plik z:

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

Czasami przenoszę „bezpieczne” modyfikacje do dużej setqinstrukcji przed fragmentem powyżej.

Mój plik .gitignore wygląda następująco:

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

tl; dr

• użyj .emacs.d/init.elzamiast.emacs
• zrób swoją .gitignorebiałą listę
• użyj menedżera pakietów

.emacs.d / init.el

Używam .emacs.d/init.elzamiast, .emacsponieważ ta konfiguracja pozwala mi przejść .emacs.dna git. Posiadanie ~/.emacssprawia, że ​​możesz utworzyć symboliczne łącze do repozytorium git lub mieć repozytorium git w swoim katalogu domowym. Jeśli używasz .emacs.d, wszystko jest rozwiązane.

.gitignore

Mój .gitignore to biała lista zamiast domyślnej czarnej listy.

*

!.gitignore
!init.el

Ta konfiguracja pozwala skoncentrować się na tym, czego naprawdę potrzebujesz, a nie na tym, czego nie potrzebujesz. .emacs.dnie jest jak repozytorium kodu źródłowego, co oznacza, że ​​rezyduje nie tylko twój kod, ale również wszystkie inne automatycznie generowane lub tymczasowe pliki. Naprawdę nie wiesz, co się stanie. Zatem „ domyślnie ignoruj ​​wszystko i dodawaj pliki, na których Ci zależy ”, to lepsza strategia, IMO.

BTW, utrzymuję większość konfiguracji w init.el, zamiast używać schematu wielu plików. Powodem jest to, że duży plik pozwala mi: a) korzystać ze standardowych narzędzi, takich jak occurlub isearch-forwardprzejść do konfiguracji, którą chcę, b) używać, outshinektóra sprawia, że ​​mój init.el org-cycle-able, c) nie zmieniać mojego przez .gitignorecały czas.

Menedżer pakietów

Jeśli nie masz specjalnych potrzeb w zakresie synchronizacji wersji Emacsa i / lub wersji Pakietów we wszystkich systemach, nie poddawaj pakietów git. Package.eljest w porządku. use-packagejest również w porządku. Beczka jest miła. Wybierz menedżera pakietów i zatwierdz tylko plik konfiguracyjny, ale nie sam pakiet.

to znaczy. Jedną ze specjalnych potrzeb, jakie mogę wymyślić, byłoby posiadanie dwóch systemów, rozwoju i wdrożenia, i muszą one mieć dokładnie taką samą konfigurację Emacsa.

Mam następujące rzeczy w moim .hgignore

• plik serwera emacs
• plik niedawny: ścieżki do plików na jednym komputerze nie mają sensu na innym
• katalog elpa / melpa: Użyj pliku init, aby automatycznie zainstalować wymagane pakiety i zapisać czasy ściągania / wypychania.

Jeśli chcesz udostępnić swój init innym, możesz rozważyć usunięcie wszelkich plików historii, takich jak ten utworzony w trybie savehist. Poza tym nie sądzę, żeby były w tym jakieś specjalne sztuczki. Tutaj obowiązują również wszelkie wytyczne dotyczące projektów kodu wersji.

Z biegiem czasu pakiety dodają wiele rzeczy ~/.emacsi kończę, dodając je jeden po drugim do mojego .gitignore. Mam też private.elhasło, które zawiera kod specyficzny dla maszyny itp., Których nie śledzę.

Oto co mam teraz.

# 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

To zależy od tego, jakich pakietów / funkcji używasz, więc może to być trudne. Oprócz plików wymienionych przez Vamsi, na przykład, jeśli używasz dired-immage, tworzy tam katalog do buforowania miniatur. Prawdopodobnie chcesz też zignorować pliki .elc.

Publikuję moje .emacs.d, ale używam subrepo z prywatnymi zmianami (hasła i tym podobne). Aby umożliwić innym klonowanie, domyślna gałąź wskazuje na zastępcze podrepo, a każda maszyna ma własną nazwaną gałąź.

Podczas łączenia między maszynami najpierw graftwprowadzam nowe zmiany w defaultoddziale, a następnie łączę defaultgałąź z innymi oddziałami w miejscu pracy.

Jako przykład możesz znaleźć mój .emacs.d na bitbucket , w tym plik Readme z krótkim przewodnikiem użytkowania.

Do tej konfiguracji możesz dodać sterownik scalania w trybie organizacji .

Po kilku iteracjach ustaliłem, że chociaż kontrola wersji doskonale nadaje się do udostępniania kodu i śledzenia zmian, nie jest to świetne rozwiązanie do synchronizowania szybko zmieniającej się konfiguracji między komputerami. Powodem jest to, że istnieje wiele rzeczy, które należy zsynchronizować i nie powinny one mieć kontroli wersji. Kilka przykładów:

1. .elcpliki (ponowna kompilacja ich w przypadku zmiany konfiguracji jest dużym problemem, a błędy związane z nieaktualnymi elcplikami często stanowią problem podczas debugowania).
2. Cały elpakatalog (i dopóki przypinanie wersji nie stanie się standardem, automatyczne przebudowywanie go po prostu nie jest wystarczająco niezawodne).
3. Pliki generowane automatycznie, takie jak eshellhistoria i gnuspliki.
4. Prywatne informacje, takie jak hasła i klucze API.

(Należy zauważyć, że problemów między platformami nie ma na liście - jedna konfiguracja, która działa w wielu systemach operacyjnych, powinna być w porządku). Zamiast używać git jako rozwiązania do synchronizacji, używam go wyłącznie jako rozwiązania do śledzenia kodu i synchronizacja za pomocą Dropbox. W ten sposób załatwiane są wszystkie irytujące pliki, które nie powinny znajdować się w kontroli wersji.

I nie mają jednak cel posiadania moja konfiguracja być rebuildable od źródła czy moja konfiguracja Dropbox znika z jakiegokolwiek powodu, więc śledzić wszystkich zainstalowanych pakietów i etażerka w źródle. Moje prywatne informacje są również przechowywane w podmodule git. Ale do codziennej synchronizacji git po prostu nie jest świetnym rozwiązaniem.