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

65

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.

Paul Bissex
źródło
Po prostu, pomimo tego, co powiedziano poniżej, jeśli używasz tej samej wersji emacs na wszystkich swoich komputerach, synchronizacja katalogu Elpa jest całkowicie w porządku.
Malabarba
Nie wykluczają *.elc. stackoverflow.com/a/24539894/324105
phils

Odpowiedzi:

36

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ć.

Rangi Lin
źródło
2
Chodzi o Cask, o ile pracujesz tylko z komputerami, które obsługują Cask, zwłaszcza z Windows.
T. Verron
Niektóre osoby mogą zatwierdzać pakiety po każdej aktualizacji, jeśli nie, sugeruję, aby nie przechowywać całego pakietu. Pozwól menedżerowi pakietów wykonać zadanie.
Rangi Lin,
@ T.Verron Udało mi się sprawić, że Cask pracował nad Cygwinem, ale sprawiło mi to trochę problemów. BTW, teraz używam Emacsa Preludium i odkryłem, że ta prelude-require-packagesfunkcja działa jak Beczka biedaka (z tą zaletą, że działa również z Windows).
rsenna
Czy beczka cygwina działa z emacsem w32? Jeśli chodzi o makra emulujące to zachowanie, pomocne może być również narzędzie wbudowane package-installwymienione w emacs.stackexchange.com/a/410/184 .
T. Verron
2
@JorgeArayaNavarro Można go zatwierdzić, jeśli będą takie same na różnych komputerach. :) ale tak nie jest w moim przypadku. Co więcej, ponieważ będzie on edytowany automatycznie, czasami zapominam o zatwierdzeniu, dlatego nie poddaję custom.elkontroli źródła.
Rangi Lin
8

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
remvee
źródło
8

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.

Yasushi Shoji
źródło
Trzymanie wszystkiego w jednym init.elpliku działa tak długo, jak długo ten plik nie staje się zbyt duży. Emacs nie jest dobry w obsłudze dużych plików, a po chwili zaczyna się czołgać podczas edycji dużych plików init.el. Kolejną zaletą dzielenia konfiguracji na wiele plików jest to, że grają one lepiej z git, który w niektórych sytuacjach może uznać zmiany w jednym pliku za konflikt scalania, ale nie tak, jeśli zmiany są w osobnych plikach. Wreszcie, dużo łatwiej jest komentować tylko pojedyncze wymagania niż duże fragmenty pliku init.
izkon
6

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.

Vamsi
źródło
3

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
Jaseem
źródło
1

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.

rlazo
źródło
1

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 .

Arne Babenhauserheide
źródło
1

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.

shosti
źródło