नोट: मुझे लगता है कि आप प्रत्येक उपयोगकर्ता को अपने उपयोगकर्ता के रूप में सर्वर में लॉग इन करने के साथ एक एसएसएच-आधारित एक्सेस तंत्र का उपयोग कर रहे हैं (यानी आपके पास एकाधिक उपयोगकर्ताओं को रिपॉजिटरी तक पहुंचने के लिए एक खाते में लॉगिन नहीं है)। यदि यह धारणा सत्य नहीं है, तो निम्न उत्तर पूरी तरह से उपयोगी नहीं हो सकता है।
अपने व्यक्तिगत भंडार की core.sharedrepository
स्थापित करने और umask आप इसे उपयोग करने का उपयोग स्वामित्व और अनुमतियाँ एक दूरस्थ भंडार पर इस्तेमाल के लिए अप्रासंगिक हैं।
रिमोट रिपोजिटरी में core.sharedrepository
से 0660
सेट करना आप जो चाहते हैं उसे प्राप्त करने का सही तरीका है। रिमोट साइड पर पहुंचने वाले उपयोगकर्ता के उमास्क भी अप्रासंगिक है क्योंकि गिट core.sharedrepository
के लिए मान को देखते हुए मास्क ओवरराइड करेगा। आपको यह सुनिश्चित करने की ज़रूरत है कि सभी फाइलें और निर्देशिकाएं आपके सामान्य समूह द्वारा समूह-स्वामित्व वाली हैं और अनुमतियां सही हैं (2770
सभी निर्देशिकाओं के लिए (या बस 770
बीएसडी-आईएसएच सिस्टम के लिए); 440
objects/??
और /objects/pack/
के तहत फ़ाइलों के लिए; अन्य फ़ाइलों के लिए 660
)।
यह सामान्य है कि एक नई फ़ाइल उपयोगकर्ता द्वारा स्वामित्व वाली उपयोगकर्ता द्वारा स्वामित्व वाली है। गैर-बीएसडी सिस्टम पर आपको निर्देशिकाओं पर सेटगिड बिट (2000
बिट) की आवश्यकता होती है ताकि नई प्रविष्टियां अपनी मूल निर्देशिका के समूह-स्वामी को प्राप्त कर सकें। उपयोगकर्ता-मालिक को शायद ही कभी विरासत में मिला है (फ्रीबीएसडी को इसे सेट्यूड बिट के साथ करने के लिए कॉन्फ़िगर किया जा सकता है, लेकिन इसका उपयोग सामान्य कॉन्फ़िगरेशन में नहीं किया जाता है)। इस प्रकार, सभी फाइलों और निर्देशिकाओं में समान, सामान्य, समूह-स्वामी होना चाहिए, लेकिन प्रत्येक संग्रह को लिखना (जैसे पुश) कुछ फ़ाइलों और/या निर्देशिकाओं को छोड़ देगा जो उपयोगकर्ता के स्वामित्व वाले उपयोगकर्ता (यानी यह आवश्यक नहीं है कि कोई भी उपयोगकर्ता (आपका rUser
?) सभी फ़ाइलों और निर्देशिकाओं का उपयोगकर्ता-स्वामी हो; किसी भी उपयोगकर्ता को रिपोजिटरी तक पहुंच की आवश्यकता हो, सामान्य समूह का सदस्य होना चाहिए)।
प्रत्येक उपयोगकर्ता स्पष्ट रूप से किसी भी फाइल निर्देशिका वे बनाने उपयोगकर्ता के स्वामी होगा /, लेकिन वे भी उपयोगकर्ता के स्वयं के सबसे फ़ाइलों वे संशोधित करेगा कि क्योंकि Git "परमाणु पुनर्लेखन" का उपयोग करता है (यह करने के लिए नई सामग्री लिखता है एक ही निर्देशिका में एक नई, अलग फ़ाइल, और उसके बाद इसे मूल फ़ाइल के ऊपर नामित करता है)।
शायद गिट नई फाइलों के लिए उमास्क को ओवरराइड करने के तरीके में एक बग है। वास्तव में कौन सी फाइलें अनुमतियां प्राप्त कर रही हैं जो बहुत व्यापक हैं? भंडार पर पहुंच के लिए रिमोट एंड पर गिट का कौन सा संस्करण है? आप रिमोट एंड पर क्या ओएस चल रहे हैं?
मैं इस समस्या को गिट 1.7.4.1 के साथ दो उपयोगकर्ताओं और मेरे यूनिक्स मशीन पर एक आम समूह के साथ पुन: उत्पन्न करने में असमर्थ था।
आप परिदृश्य को थोड़ा सा सरल बनाने का प्रयास कर सकते हैं। सर्वर से सीधे रिमोट रिपॉजिटरी को धक्का देने का प्रयास करें (यानी स्थानीय क्लोन बनाएं और फेंकने वाली शाखा में धक्का दें)। स्थानीय-केवल पहुंच करने से आपके धारणाओं (umask; uids; gids; उपयोगकर्ता-, और समूह-स्वामित्व, और पुश करने से पहले और बाद में फ़ाइलों और निर्देशिकाओं की अनुमतियों को जांचना आसान हो जाता है) जब आपके बीच मध्य में किसी प्रकार का परिवहन होता है (या तो गिट के अपने एसएसएच-आधारित ट्रांसपोर्ट, या एक नेटवर्क फाइल सिस्टम जो पूर्ण निष्ठा के साथ आईडी और अनुमतियों को मैप नहीं कर सकता है)।
स्रोत
2011-03-11 08:35:43
आप रिमोट रिपोजिटरी का उपयोग कैसे कर रहे हैं? ऐसा लगता है कि आप एक एसएसएच-आधारित विधि ('होस्ट: पथ' या' ssh: // होस्ट/पथ 'भंडार URL का उपयोग कर रहे हैं)। यदि आप इसके बजाय नेटवर्क फाइल सिस्टम का उपयोग कर रहे हैं, तो यह जटिल चीजें हो सकती है। –
मैं एसएसएच का उपयोग कर उपयोग कर रहा हूं, और रिमोट फाइल सिस्टम वास्तव में एक एनएफएस फाइल सिस्टम है (मुझे यकीन नहीं है कि फाइल सिस्टम यहां कुछ भी क्यों प्रभावित करेगा)। – user10