गिट: एक कंप्यूटर से धक्का नहीं दे सकता

Question

मेरे सहकर्मियों में से एक को अपनी मशीन पर गिट से परिवर्तन को धक्का देने में समस्या हो रही है। , लेकिन उसकी मशीन, से जब वह वह निम्न त्रुटि

 
    D:\Projects\test1\best-practices>git push 
    Counting objects: 4, done. 
    Compressing objects: 100% (2/2), done. 
    Writing objects: 100% (3/3), 273 bytes, done. 
    Total 3 (delta 1), reused 0 (delta 0) 
    error: unable to create temporary sha1 filename ./objects/42: Permission denied 

    fatal: failed to write object 
    error: unpack failed: unpacker exited with error code 
    To //civ3s012/gitrepos/best-practices/.git 
    ! [remote rejected] master -> master (n/a (unpacker error)) 
    error: failed to push some refs to '//civ3s012/gitrepos/best-practices/.git' 

सर्वर एक विंडोज़ मशीन है हो जाता है पुश करने के लिए कोशिश करता है के रूप में ग्राहक है - वह एक और मशीन में लॉग करता है, वह ठीक धक्का कर सकते हैं। किसी और को यह समस्या नहीं है - ऐसा लगता है कि यह एक सर्वर अनुमति समस्या है, लेकिन हमने उस पर शासन किया है जहां तक ​​हम कह सकते हैं। साथ ही, तथ्य यह है कि वह एक ही यूजरनेम का उपयोग करके एक अलग मशीन और पुश में लॉग इन कर सकता है, ऐसा लगता है कि यह सर्वर अनुमति नहीं है। कोई विचार क्या गलत हो सकता है?

Answer 1

मैं विंडोज़ उपयोगकर्ता नहीं हूं इसलिए मैं यहां थोड़ा सा अंधेरे में चिपक रहा हूं। ऐसा लगता है कि रिमोट फाइल सिस्टम माउंट किया गया है और आप बस उस पर दबाव डाल रहे हैं (ssh: // या git: // का उपयोग नहीं कर रहे हैं)। क्या वह एफएस किसी भी तरह से पढ़ा जाता है? क्या वह वहां फाइलें बना/संशोधित कर सकता है (git के बाहर)?

Answer 2

हो सकता है कि उसने अपने स्थानीय रेपो में एक शाखा बनाई है जो पहले से ही सर्वर पर मौजूद है और ref को अपडेट नहीं किया जा सकता क्योंकि यह किसी और द्वारा बनाया गया था?

Answer 3

मुझे पता है कि यह आसान-आसान sysadmin blowoff जवाब है, लेकिन क्या आपने सत्यापित किया है कि उसका हार्डड्राइव भरा नहीं है?

Answer 4

दूरदराज के भंडार को यह विन्यास चर जोड़ने का प्रयास करें:

$ git config core.sharedRepository "all" 
$ git config receive.denyNonFastForwards True 

ये आम तौर पर, git init में --shared विकल्प द्वारा निर्धारित कर रहे हैं जब रेपो की स्थापना की है।

मुझे नहीं पता कि विंडोज़ अनुमतियां कैसे इंटरैक्ट करती हैं, इसलिए मुझे यकीन नहीं है कि यह समाधान है। लेकिन मुझे पता है कि कभी-कभी एक लिनक्स उपयोगकर्ता ऐसी अनुमतियों के साथ फाइलें बना सकता है जो गिट रिमोट में इस तरह से विफल हो जाते हैं। ऐसा तब हुआ जब वे उचित समूह से संबंधित हैं लेकिन उनके पास प्राथमिक समूह के रूप में नहीं है। रेपो शेयरिंग को all पर सेट करना इस के आसपास हो जाता है।

यह एसवीएन या सीवीएस से आयातित साझा रेपो के साथ होता है।

Answer 5

एक और मस्तिष्क मृत उत्तर। क्या आपको यकीन है कि आपके पास उन फ़ाइलों को पढ़ने की अनुमति है? मेरे साथ कुछ बार हुआ है जहां मैं गलती से एक और उपयोगकर्ता के रूप में एक बदलाव करूँगा। फिर बाद में मैं धक्का नहीं दे सकता। चोटी तुम्हारा दोस्त है।

Answer 6

समस्या उस शेयर के लिए एक संग्रहीत पासवर्ड होने के कारण समाप्त हुई जिसने पढ़ने की अनुमति दी, लेकिन पहुंच नहीं लिखी। यहां तक ​​कि जब हमने उचित उपयोगकर्ता नाम और पासवर्ड के साथ ड्राइव को स्पष्ट रूप से घुमाया था, तब भी संग्रहीत पासवर्ड पृष्ठभूमि में उपयोग किया जाना चाहिए था, जिसने इसे ट्रैक करना मुश्किल बना दिया था। पासवर्ड को साफ़ करने के लिए, हम नियंत्रण कक्ष, उपयोगकर्ता खाते पर गए, उन्नत पर क्लिक किया, पासवर्ड प्रबंधित करें, और सर्वर के लिए लॉगऑन जानकारी को हटा दिया। उसके बाद, सबकुछ काम करता था जैसा कि इसे करना चाहिए। मैं पैट नोटज़ के जवाब को स्वीकार कर रहा हूं, क्योंकि यह केवल पढ़ने के लिए एफएस होने का अंत हो गया था। धन्यवाद!