यह ध्यान में रखते हुए कि गिट को प्रतीकात्मक लिंक को पहचान नहीं है जो भंडार के बाहर इंगित करता है, क्या हार्ड लिंक का उपयोग करने में कोई समस्या है?गिट और हार्ड लिंक
क्या गिट उन्हें तोड़ सकता है? क्या आप मुझे विस्तृत जानकारी के लिए इंगित कर सकते हैं?
गिट में निर्देशिकाओं का प्रतिनिधित्व करने वाला 'पेड़' ऑब्जेक्ट, फाइल का नाम और (सबसेट) अनुमतियों को संग्रहीत करता है। यह इनोड नंबर (या अन्य प्रकार की फ़ाइल आईडी) स्टोर नहीं करता है। इसलिए हार्ड लिंकगिट में कम से कम नहीं किया जा सकता है, कम से कम तीसरे पक्ष के उपकरण जैसे metastore या git-cache-meta (और मुझे यकीन नहीं है कि यह उन उपकरणों के साथ भी संभव है)।
गिट उन फ़ाइलों को छूने की कोशिश नहीं करता है जिन्हें अद्यतन करने की आवश्यकता नहीं है, लेकिन आपको यह ध्यान रखना होगा कि गिट हार्डलिंक को संरक्षित करने की कोशिश नहीं करता है, इसलिए उन्हें गिट द्वारा तोड़ दिया जा सकता है।
बारे सांकेतिक लिंक के बाहर भंडार ओर इशारा करते हुए: Git उन लोगों के साथ कोई समस्या नहीं है और सांकेतिक लिंक की सामग्री की रक्षा करना चाहिए ... लेकिन इस तरह के लिंक की उपयोगिता, मेरे लिए संदिग्ध है के रूप में उन सिमलिंक टूटी हुई है या किया जाएगा कि क्या फाइल सिस्टम लेआउट गिट भंडार, और गिट के नियंत्रण में नहीं है पर निर्भर करता है।
रेपो के बाहर पथों के लिए सिम्लिंक उपयोगी हो सकता है। मैंने उनको डेटाबेस या मीडिया फ़ाइलों को इंगित करने के लिए वेबपैस में उपयोग किया है जो रेपो द्वारा ट्रैक नहीं किए गए हैं। इस तरह, वेब ऐप की कॉन्फ़िगरेशन फ़ाइल एक स्थिर पथ को इंगित कर सकती है, लेकिन उस पथ का वास्तविक स्थान स्थानीय विकास और सर्वर वातावरण के बीच भिन्न हो सकता है। – mipadi
@ मिपाडी: बीटीडब्ल्यू। आधुनिक गिटवेब में भंडार के बाहर सामान्यीकरण के बाद अग्रणी सिम्लिंक प्रदर्शित करने के लिए विशेष मामला है। –
हाँ, रेपो के बाहर सिम्लिंक ठीक हैं। मैंने उन्हें एक विशाल डेटा निर्देशिका को इंगित करने के लिए उपयोग किया जिसे मुझे संस्करण (या इच्छित) की आवश्यकता नहीं थी। आम तौर पर मैं सापेक्ष लिंक का उपयोग करता हूं। तो मामले में रेपो और डेटा निर्देशिका को कुछ मूल निर्देशिका में एक दूसरे के बगल में बैठना पड़ा। आप ../foo के साथ सिम्लिंक के साथ अद्भुत चाल कर सकते हैं। –
जंक्शन अंक से नहीं सांकेतिक लिंक कर रहे हैं; इसलिए, प्रतीकात्मक लिंक बस msysGit में असमर्थित हैं।
इसके अलावा, हार्ड लिंक कभी भी गिट द्वारा ट्रैक नहीं किए गए थे।
यह समस्या विंडोज-ओरिएंटेड थी (क्योंकि यह msysgit के बारे में है) और symlink के संभावित समर्थन के बारे में बहस।
लेकिन हार्ड लिंक के बारे में टिप्पणी सामान्य रूप से गिट से संबंधित है।
Google 'गिट हार्ड लिंक को संरक्षित करता है' और यह दिखाता है कि गिट को पता नहीं है कि डिजाइन द्वारा शायद हार्ड लिंक संरचना AFAIK को कैसे संरक्षित किया जाए।
मेरा वेब परियोजनाएं इस प्रकार हार्ड लिंक का उपयोग करें:
www/products/index.php
www/products/dell_latitude_id577/index.php #(hard linked to above)
www/products/dell_inspiron_id323/index.php #(hard linked again to above)
[email protected]:www/products$ ls -l index.php
-rwxr-xr-x 3 me me 1958 Aug 22 22:10 index.php*
अगर मैं index.php के लिए मैं एक ही स्थान पर और हार्ड लिंक (उत्पाद विवरण पृष्ठ) बदल परिवर्तन करने के लिए परिवर्तन को इंगित करना चाहता था - गिट को छोड़कर क्लोनिंग और अन्य कंप्यूटरों पर खींचने के दौरान इस संबंध को सुरक्षित नहीं किया जाता है।
[email protected]:www$ git pull
किसी अन्य मशीन पर प्रत्येक हार्ड लिंक के लिए एक नई index.php तैयार करेगा।
आपको अपने वेबपैप में किसी प्रकार का रूटिंग लागू करना चाहिए। हार्ड लिंकिंग विचित्र है। – Nowaker
हाँ, कम से कम symlinks का उपयोग करें। :) –
ठीक है, अब यह एक देर जबाब = डी है
मुझे पता चला है कि, हुक का उपयोग कर, आप git pull घटना पर कब्जा कर सकते हैं .git/hooks/post-merge स्क्रिप्ट ईवेंट हैंडलर लेखन (जब वहाँ खींचने के लिए कुछ है ...) फ़ाइल।
सबसे पहले, आपको chmod +x पर जाना होगा।
फिर, प्रत्येक पुल पर हार्ड लिंक को फिर से बनाने के लिए ln कमांड डालें। सुट हुह!
यह काम करता है, मुझे बस इसकी आवश्यकता है कि मेरी परियोजना के लिए और ls -i दिखाता है कि pull के बाद फ़ाइलों को स्वचालित रूप से लिंक किया गया था।
.git/hooks/post-merge के मेरे उदाहरण:
#!/bin/sh
ln -f $GIT_DIR/../apresentacao/apresentacao.pdf $GIT_DIR/../capa/apresentacao.pdf
ln -f $GIT_DIR/../avaliacoesMono/avaliacao_monografias_2011_Nilo.pdf $GIT_DIR/../capa/avaliacoes.pdf
ln -f $GIT_DIR/../posters/poster_Nilo_sci.pdf $GIT_DIR/../capa/poster.pdf
ln -f $GIT_DIR/../monografia/monografia_Nilo.pdf $GIT_DIR/../capa/monografia_Nilo.pdf
महत्वपूर्ण: यदि आप देख सकते हैं, अपने भंडार में किसी भी फ़ाइल का पथ $GIT_DIR साथ शुरू करना चाहिए, फिर फ़ाइल को आंशिक रिश्तेदार पथ जोड़ें।
यह भी महत्वपूर्ण है: -f आवश्यक है, क्योंकि आप गंतव्य फ़ाइल को पुनर्निर्माण कर रहे हैं।
तो ऐसा लगता है कि जब भी आप अपने रेपो में हार्डलिंक जोड़ते हैं तो आपको अपनी पोस्ट-मर्ज हुक स्क्रिप्ट में मैन्युअल रूप से एक लाइन जोड़ने की आवश्यकता होती है। अच्छा होगा अगर आपके प्री-प्रतिबद्ध हुक ने इसे पूरी तरह से स्वचालित बनाया - आपकी प्रतिबद्धता में कठोर (और प्रतीकात्मक) लिंक का पता लगाना और अपनी पोस्ट-मर्ज फ़ाइल में उचित लाइनें लिखना। गिट को रेपो में इनोड जानकारी स्टोर नहीं करना पड़ेगा, यह हुक में इसके बिट्स स्टोर करेगा! लेकिन क्या गड़बड़ है अगर जुड़ा हुआ फ़ाइल किसी अन्य गिट रेपो में ट्रैक किया गया था ... क्या एक स्थान पर फ़ाइल को एक संपादन में अन्य रिपो को आसानी से प्रचारित किया जाएगा? एक गोलाकार पुश/पुल पाश के साथ लगातार विलय? – hobs
चालाक दृष्टिकोण, लेकिन यह दुर्भाग्यपूर्ण है कि गिट हार्ड लिंक को ट्रैक नहीं करता है, यहां तक कि संभावित रूप से उन्हें उन फाइल सिस्टम पर प्रतियों के रूप में प्रतिनिधित्व करता है जो हार्ड लिंक का समर्थन नहीं करते हैं। –
आप क्या करने की कोशिश कर रहे हैं और क्यों? एक हार्ड लिंक एक सामान्य फ़ाइल से अलग नहीं है। यदि आप कभी भी किसी अन्य संग्रह से एक नया संस्करण खींचने के लिए थे, तो यह आपके पास उस व्यक्ति को ओवरराइट करेगा - रेपो के बाहर कुछ जोड़ने का क्या मतलब है? –
गिट सिम्लिंक को पहचान लेगा जो भंडार के बाहर एक पथ को इंगित करता है। – mipadi
कोई मिपाडी, रेपो में फ़ाइलों को लहरा रहा है और उनके "वास्तविक" स्थान में symjbolic लिंक –