संस्करण नियंत्रण में .emacs और .emacs.d को रखते समय मुझे क्या करना चाहिए?

Question

कई लोगों की तरह, मैं एक संस्करण नियंत्रण रिपॉजिटरी (मेरे मामले में निजी पर बिटबकेट पर मरकरी) के माध्यम से अपने बहुत सारे डॉटफ़ाइल्स का प्रबंधन करता हूं। यह एक नई मशीन स्थापित करने या विभिन्न मशीनों के बीच कॉन्फ़िगरेशन के प्रसार के लिए आसान है।

इसलिए स्वाभाविक रूप से मैंने अपना .emacsऔर .emacs.dइस सेटअप में जोड़ा ।

फिर मैंने कुछ पैकेजों को स्थापित किया, और मुझे *.elcअपने साथ जोड़ना समाप्त कर दिया .hgignore, जैसे मैं *.pycअपने पायथन रेपोस से फाइलों को छोड़ देता हूं।

क्या अन्य चीजें हैं जो मुझे ट्रैक नहीं करनी चाहिए, उदाहरण के लिए उत्पन्न फाइलें जो पर्यावरण विशिष्ट हैं और किसी अन्य प्लेटफॉर्म पर क्लोन किए जाने पर उपयोगी / सही नहीं होंगी? (मैं डेस्कटॉप पर लिनक्स और ओएस एक्स और सर्वर पर फ्रीबीएसडी का उपयोग करता हूं।)

क्या कोई सेटअप ट्रिक्स हैं जो आमतौर पर इस तरह के साझाकरण को अधिक मूल्यवान बनाने के लिए उपयोग किए जाते हैं? अपने शेल फ़ाइल सेटअप के साथ, मैं अभी भी उदाहरण के लिए शाखाओं में व्यक्तिगत फ़ाइलों को चेरी-लेने के अच्छे तरीकों की तलाश कर रहा हूं।

Comments

सिर्फ FYI करें, इसके बावजूद कि नीचे क्या कहा गया है, यदि आप अपने सभी कंप्यूटरों पर समान Emacs संस्करण का उपयोग करते हैं, तो Elpa निर्देशिका को सिंक्रनाइज़ करना पूरी तरह से ठीक है।

— मालाबार

बाहर न करें *.elc। stackoverflow.com/a/24539894/324105

— phils

Answer 1

मैं अपने Emacs कॉन्फ़िगरेशन को Github में संग्रहीत करता हूं क्योंकि मैं दो अलग-अलग कंप्यूटरों का उपयोग करता हूं, एक काम पर, एक घर पर।

यहाँ उन चीजों के बारे में एक सूची दी गई है जिन्हें मैं स्रोत नियंत्रण में नहीं रखता हूँ:

पर्यावरण निर्दिष्ट सेटअप।

उदाहरण के लिए, मेरे Emacs अलग मशीन पर स्टार्ट-अप पर अलग-अलग org फ़ाइल खोलते हैं। आप इन सेटिंग्स को स्रोत नियंत्रण में नहीं करना चाहते हैं।

मैं (require 'local nil t)इन सेटिंग्स को लोड करने के लिए उपयोग करता हूं , लेकिन कभी भी प्रतिबद्ध नहीं हूं local.el।

संकुल प्रबंधक द्वारा प्रबंधित पैकेज

जब पैकेज प्रबंधक द्वारा प्रबंधित किए जाते हैं, तो मैं सुझाव देता हूं कि उन पैकेजों को स्रोत नियंत्रण में न रखें। चूंकि :

1. आपको हर अपडेट के बाद कमिट करना होगा।
2. आप महत्वपूर्ण फ़ाइल को कहीं और स्टोर कर सकते हैं, जो आपको विभिन्न कंप्यूटरों को ठीक से सिंक्रनाइज़ करने में असमर्थ बनाती है।

प्रतिबद्ध पैकेजों के बजाय, मेरा सुझाव है कि आप अपने पैकेज प्रबंधक द्वारा मान्यता प्राप्त तंत्र को प्रतिबद्ध करें ।

उदाहरण के लिए, मैं अपने 3 जी पैकेजों को प्रबंधित करने के लिए पीपा का उपयोग करता हूं, इसलिए मैं केवल पीपा फाइल तैयार करता हूं, जिसमें निर्दिष्ट पैकेज हैं जो मुझे चाहिए।

जब मैं package.elपहले उपयोग करता हूं , तो मेरा कॉन्फ़िगरेशन यह जांच करेगा कि क्या पैकेज स्थापित है / अपडेट करने की आवश्यकता है, इसलिए कोई पैकेज प्रतिबद्ध नहीं है।

हालांकि , कुछ पैकेज हैं जो किसी भी पैकेज रिपॉजिटरी में मौजूद नहीं हैं, इस मामले में, मैं इसे स्रोत नियंत्रण के लिए प्रतिबद्ध करूंगा, जैसे कि में site-lisp।

संकुल द्वारा उत्पन्न सभी फाइलें

उदाहरण के लिए, सभी स्वतः सहेजना, बैकअप फ़ाइलें, tramp, eshell, recentf, यहां तक कि custom.el। मैंने इन फ़ाइलों को डाल दिया है ~/.emacs/.gen, इसलिए मैं इस निर्देशिका को अनदेखा कर सकता हूं।

फ़ाइलें जो बार-बार बदलती हैं, लेकिन उन्हें सिंक्रनाइज़ करने की आवश्यकता होती है

जैसे कि व्यक्तिगत डिक्शनरी फ़ाइल का उपयोग किया जाता है aspell, फ़ाइल डेटाबेस का उपयोग किया जाता है elfeed, इन मामलों में, मैं इसे अलग-अलग कंप्यूटरों में सिंक्रनाइज़ करने के लिए ड्रॉपबॉक्स का उपयोग करता हूं। इसलिए मैं कमिट करना नहीं भूलूंगा।

Comments

पीपा के बारे में बात ठीक है जब तक आप केवल उन मशीनों के साथ काम करते हैं जो पीपा का समर्थन करते हैं, विशेष रूप से विंडोज नहीं।

— टी। वेरॉन

कुछ लोग हर अपडेट के बाद पैकेज देने के लिए ठीक हो सकते हैं, अगर नहीं तो मेरा सुझाव है कि पूरे पैकेज को स्टोर न करें। पैकेज मैनेजर को काम करने दें।

— रंगी लिन

@ T.Verron मैं Cygwin पर पीपा काम करने के लिए कर रहा था, लेकिन यह मुझे दिया कुछ परेशानी। BTW, मैं अब Emacs Prelude का उपयोग कर रहा हूं , और मैंने पाया कि prelude-require-packagesफ़ंक्शन एक गरीब आदमी के पीपा के रूप में काम करता है (विंडोज के साथ भी काम करने का लाभ)।

— रासना

क्या cygwin पीपा w32 emacs के साथ काम करता है? यह इस व्यवहार की नकल मैक्रो की बात आती है, निर्मित package-installमें उल्लेख किया emacs.stackexchange.com/a/410/184 सहायक के रूप में अच्छी तरह से हो सकता है।

— टी। वेरॉन

@JorgeArayaNavarro यह पूरी तरह से ठीक है अगर वे अलग-अलग मशीनों में समान होंगे। :) लेकिन यह मेरे मामले में नहीं है। क्या अधिक है, क्योंकि यह स्वचालित रूप से संपादित किया जाएगा, कभी-कभी मैं प्रतिबद्ध करना भूल जाता हूं, यही कारण है कि मैं custom.elस्रोत नियंत्रण में नहीं रखता हूं ।

— रंगी लिन

Answer 2

बस यह सुनिश्चित करें कि कोई उत्पन्न सामान (जैसे @ रांगी-लिन नोट) रेपो में नहीं है, और यदि आप अपना डॉटफ़ाइल्स दूसरों के साथ साझा कर रहे हैं, तो कोई संबंधित सुरक्षा सामान (जैसे पासवर्ड और एपीआई कुंजी) नहीं। बाद में मैंने अपने अनुकूलन को एक अलग फ़ाइल में विभाजित किया है:

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

कभी-कभी मैं setqऊपर के स्निपेट से पहले "सुरक्षित" अनुकूलन को एक बड़े बयान में ले जाता हूं ।

मेरी .gitignore फ़ाइल इस प्रकार है:

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

Answer 3

tl; डॉ

• के .emacs.d/init.elबजाय का उपयोग करें.emacs
• अपनी .gitignoreएक सफेद सूची बनाएं
• एक पैकेज प्रबंधक का उपयोग करें

---

.emacs.d / init.el

मैं .emacs.d/init.elइसके बजाय इसका उपयोग करता हूं .emacsक्योंकि यह सेटअप मुझे .emacs.dगिट के नीचे रखने की अनुमति देता है । होने के ~/.emacsलिए आप एक रिपॉजिटरी के लिए प्रतीकात्मक लिंक बनाने के लिए या अपने घर निर्देशिका में गिट रेपो बनाने के लिए बनाता है। यदि आप उपयोग करते हैं .emacs.d, तो सभी हल हो जाते हैं।

.gitignore

डिफ़ॉल्ट ब्लैक लिस्टिंग के बजाय मेरा .ITignore श्वेत सूचीकरण है।

*

!.gitignore
!init.el

यह कॉन्फ़िगरेशन आपको इस बात पर ध्यान केंद्रित करने की अनुमति देता है कि आपको वास्तव में क्या ज़रूरत है इसके बजाय आपको क्या ज़रूरत है। .emacs.dस्रोत कोड रिपॉजिटरी की तरह नहीं है, जिसका अर्थ है कि न केवल आपका कोड रहता है, बल्कि अन्य सभी ऑटो-जनरेट या अस्थायी फाइलें भी वहां जाती हैं। आप वास्तव में नहीं जानते कि अंदर क्या जाएगा। इसलिए, " डिफ़ॉल्ट रूप से सभी को अनदेखा करें और आपके द्वारा देखभाल की जाने वाली फ़ाइलों को जोड़ें " बेहतर रणनीति है, आईएमओ।

BTW, मैं init.elबहु-फ़ाइल योजना का उपयोग करने के बजाय, अधिकांश कॉन्फ़िगरेशन रखता हूं । इसका कारण यह है कि एक बड़ी फ़ाइल मुझे) मानक उपकरण जैसे कि occurया isearch-forwardमैं चाहता हूं कि विन्यास के लिए स्थानांतरित करने के लिए अनुमति देता है , ख) का उपयोग करता है outshineजो मेरे-योग्य बनाता है init.el org-cycle, ग) मेरे .gitignoreहर समय नहीं बदलता है ।

पैकेज प्रबंधक

जब तक आपको अपने सभी सिस्टम पर Emacs संस्करण और या संकुल संस्करण को सिंक करने की विशेष आवश्यकता नहीं है, तब तक git के तहत संकुल नहीं डालें। Package.elठीक है। use-packageभी ठीक है। पीपा अच्छा है। अपने पैकेज मैनेजर को चुनें और केवल अपनी कॉन्फ़िगरेशन फ़ाइल को कमिट करें, लेकिन पैकेज को ही नहीं।

अर्थात। विशेष जरूरतों में से एक मैं सोच सकता हूं कि दो प्रणालियां होंगी, एक विकास और परिनियोजन और उनके पास बिल्कुल वैसा ही Emacs विन्यास होना चाहिए।

Comments

init.elजब तक कोई फ़ाइल बहुत बड़ी नहीं हो जाती, तब तक हर चीज़ को एक फ़ाइल में रखना काम करता है। Emacs बड़ी फ़ाइलों को संभालने में अच्छा नहीं है, और थोड़ी देर के बाद यह बड़े संपादन करते समय क्रॉल करना शुरू कर देता है init.el। एक से अधिक फ़ाइलों में अपने कॉन्फिगरेशन को विभाजित करने का एक और फायदा यह है कि वे गिट के साथ बेहतर खेलते हैं, जो कुछ स्थितियों में किसी एकल फ़ाइल में परिवर्तन को मर्ज संघर्ष मान सकते हैं, लेकिन ऐसा नहीं है यदि परिवर्तन अलग फ़ाइलों में हैं। अंत में, यह बहुत आसान है कि आपकी इनिट फ़ाइल के बड़े हिस्से की तुलना में सिर्फ सिंगल की आवश्यकता है।

— izkon

Answer 4

मेरी .hignignore में निम्नलिखित बातें हैं

• emacs सर्वर फ़ाइल
• हाल की फ़ाइल: एक मशीन पर फ़ाइल पथ दूसरे पर समझ में नहीं आता है
• elpa / melpa निर्देशिका: आवश्यक पैकेजों को स्वचालित रूप से स्थापित करने और पुल / पुश समय को बचाने के लिए init फ़ाइल का उपयोग करें।

यदि आप दूसरों के साथ अपनी init साझा करना चाहते हैं, तो आप किसी भी इतिहास फ़ाइलों को हटाने पर विचार कर सकते हैं जैसे कि savehist मोड द्वारा बनाई गई। इसके अलावा मुझे नहीं लगता कि इसके लिए कोई विशेष तरकीबें हैं। वर्जनिंग कोड प्रोजेक्ट्स के लिए आपके द्वारा अपनाई गई कोई भी गाइडलाइन यहां भी अच्छी तरह से काम करती है।

Answer 5

समय के साथ पैकेज बहुत सारी चीजें ~/.emacsजोड़ते हैं और मैं उन्हें एक-एक करके अपने में जोड़ लेता हूं .gitignore। मेरे पास एक private.elपासवर्ड भी है, मशीन विशिष्ट कोड आदि जो मैं ट्रैक नहीं करता हूं।

मेरे पास अब यही है।

# 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

Answer 6

यह निर्भर करता है कि आप किन पैकेजों / सुविधाओं का उपयोग करते हैं, इसलिए यह मुश्किल हो सकता है। उदाहरण के लिए, वाम्सी द्वारा उल्लिखित फ़ाइलों के अलावा, यदि आप डॉटेड-इम्मेज का उपयोग करते हैं, तो यह थंबनेल को कैश करने के लिए एक निर्देशिका बनाता है। आप संभावित .elc फ़ाइलों को भी अनदेखा करना चाहते हैं।

Answer 7

मैं अपने .emacs.d को प्रकाशित करता हूं, लेकिन निजी परिवर्तन (पासवर्ड और इस तरह) के साथ एक उपप्रो का उपयोग करता हूं। दूसरों को इसे क्लोन करने की अनुमति देने के लिए, डिफ़ॉल्ट शाखा एक प्लेसहोल्डर सब्रेपो को इंगित करती है, और प्रत्येक मशीन की अपनी नामित शाखा होती है।

मशीनों के बीच विलय होने पर, मैं पहले शाखा graftमें नए परिवर्तन करता हूं defaultऔर फिर defaultशाखा को अन्य कार्यस्थल शाखाओं में विलय करता हूं ।

उदाहरण के लिए, आप बिटबकैट पर मेरे .emacs.d को पा सकते हैं , जिसमें एक छोटा उपयोग गाइड भी है।

आप इस सेटअप में org- मोड मर्ज ड्राइवर जोड़ना चाह सकते हैं ।

Answer 8

कई पुनरावृत्तियों के बाद, मैंने निर्धारित किया है कि, जबकि कोड को साझा करने और परिवर्तनों को ट्रैक करने के लिए संस्करण नियंत्रण बहुत अच्छा है, यह कंप्यूटरों में तेजी से बदलते कॉन्फ़िगरेशन को सिंक करने के लिए एक महान समाधान नहीं है। कारण यह है कि कई चीजें हैं जिन्हें सिंक किया जाना चाहिए और संस्करण नियंत्रण में नहीं होना चाहिए । कुछ उदाहरण:

1. .elcफ़ाइलें (कॉन्फ़िगरेशन परिवर्तन होने पर उन्हें पुन: कनेक्ट करना एक बड़ी परेशानी है, और पुरानी elcफ़ाइलों से बग अक्सर डिबग करने के लिए दर्द होते हैं)।
2. संपूर्ण elpaनिर्देशिका (और जब तक संस्करण-पिनिंग मानक नहीं हो जाती, स्वचालित रूप से इसका पुनर्निर्माण करना अभी विश्वसनीय नहीं है)।
3. ऑटो-जनरेटेड फाइल्स जैसे कि eshellहिस्ट्री और gnusफाइल्स।
4. पासवर्ड और एपीआई कुंजी जैसी निजी जानकारी।

(ध्यान दें कि क्रॉस-प्लेटफ़ॉर्म समस्याएं सूची में नहीं हैं - एक कॉन्फ़िगरेशन होना चाहिए जो कई ऑपरेटिंग सिस्टम पर काम करता है।) एक सिंक समाधान के रूप में गिट का उपयोग करने के बजाय, मैं इसे कोड ट्रैकिंग समाधान के रूप में पूरी तरह से उपयोग करता हूं। और ड्रॉपबॉक्स का उपयोग कर सिंक करें। इस तरह, सभी कष्टप्रद फाइलें जो संस्करण नियंत्रण में नहीं होनी चाहिए, का ध्यान रखा जाता है।

मैं है , हालांकि, मेरी ड्रॉपबॉक्स विन्यास जो भी कारण के लिए गायब हो जाता है, तो मेरी विन्यास स्रोत से Rebuildable होना होने का एक लक्ष्य है, इसलिए मैं सभी इंस्टॉल किए गए पैकेज की और whatnot स्रोत में ट्रैक रखें। मेरी निजी जानकारी एक गिट सबमॉड्यूल में भी संग्रहीत है। लेकिन दिन-ब-दिन सिंक करने के लिए, बस एक बढ़िया समाधान नहीं है।