मेरे होमवर्क को `गिट पुल` कैसे खा गया?


53

मैं प्रिंसिपल के कार्यालय में एक बच्चे की तरह समझाता हूं कि कुत्ते ने मेरे होमवर्क को रात होने से पहले ही खा लिया था, लेकिन मैं चेहरे पर कुछ पागल डेटा हानि बग को घूर रहा हूं और मैं यह पता नहीं लगा सकता कि यह कैसे हुआ। मैं जानना चाहूंगा कि git मेरे भंडार को कैसे खा सकता है! मैंने कई बार झुर्रियों के माध्यम से पकड़ लिया है और यह कभी भी झपकी नहीं है। मैंने इसका इस्तेमाल एक 20 गिग सबवर्सन रेपो को 27 git repos में विभाजित करने के लिए किया है और गंदगी को बाहर निकालने के लिए उनमें से foo-branched फिल्टर किया है और यह कभी भी मुझ पर बाइट नहीं खोया है। रिफ्लोगी हमेशा वापस गिरने के लिए होता है। इस समय कालीन चला गया है!

मेरे दृष्टिकोण से, मैंने जो कुछ किया था, वह सब चला git pullऔर इसने मेरे पूरे स्थानीय भंडार को नंगा कर दिया। मेरा मतलब यह नहीं है कि "चेक आउट संस्करण गड़बड़" या "मैं जिस शाखा पर था" या ऐसा कुछ भी। मेरा मतलब है कि पूरी बात खत्म हो गई है

यहाँ घटना पर मेरे टर्मिनल का स्क्रीन-शॉट है:

घटना स्क्रीन शॉट

चलो मैं तुम्हें उसी के माध्यम से चलता हूं। मेरे कमांड प्रॉम्प्ट में वर्तमान git रेपो (prezto के vcs_info कार्यान्वयन का उपयोग करके) के बारे में डेटा शामिल है ताकि आप देख सकें कि git रेपो कब गायब हो गया। पहला आदेश सामान्य है:

  » caleb » jaguar » ~/p/w/incil.info » ◼  zend ★ »
❯❯❯ git co master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.

वहां आप देख सकते हैं कि मैं 'ज़ेंड' शाखा पर था, और मास्टर की जाँच की। अब तक सब ठीक है। आप मेरी अगली कमांड से पहले प्रॉम्प्ट में देखेंगे कि उसने सफलतापूर्वक शाखाएँ बदल दी हैं:

  » caleb » jaguar » ~/p/w/incil.info » ◼  master ★ »
❯❯❯ git pull
remote: Counting objects: 37, done.
remote: Compressing objects: 100% (37/37), done.
remote: Total 37 (delta 25), reused 0 (delta 0)
Unpacking objects: 100% (37/37), done.
From gitlab.alerque.com:ipk/incil.info
 + 7412a21...eca4d26 master     -> origin/master  (forced update)
   f03fa5d..c8ea00b  devel      -> origin/devel
 + 2af282c...009b8ec verse-spinner -> origin/verse-spinner  (forced update)
First, rewinding head to replay your work on top of it...
>>> elapsed time 11s

और बस ऐसे ही चला गया। यदि 10 सेकंड से अधिक बीत चुके हैं, तो अगले समय से पहले बीता समय मार्कर आउटपुट। Git ने नोटिस से परे कोई आउटपुट नहीं दिया कि वह रिप्ले करने के लिए रिवाइंड कर रहा था। कोई संकेत नहीं कि यह समाप्त हो गया।

अगले प्रॉम्प्ट में इस बारे में कोई डेटा शामिल नहीं है कि हम किस शाखा या गिट की स्थिति पर हैं।

यह नहीं देख पाने में असफल रहा कि मैंने एक और git कमांड चलाने की कोशिश की है, केवल यह बताया जाए कि मैं git रेपो में नहीं था। ध्यान दें पीडब्ल्यूडी नहीं बदला है:

  » caleb » jaguar » ~/p/w/incil.info »
❯❯❯ git fetch --all
fatal: Not a git repository (or any parent up to mount point /home)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

इसके बाद चारों ओर के नजारे ने दिखाया कि मैं पूरी तरह से खाली निर्देशिका में था। कुछ भी तो नहीं। कोई '.git' निर्देशिका, कुछ नहीं। खाली।

मेरा स्थानीय git संस्करण 2.0.2 पर है। यहाँ मेरे git config के कुछ tidbits हैं जो कि क्या हुआ बनाने के लिए प्रासंगिक हो सकते हैं:

[branch]
        autosetuprebase = always
        rebase = preserve
[pull]
        rebase = true
[rebase]
        autosquash = true
        autostash = true
[alias]
        co = checkout

उदाहरण के लिए मैंने git pullमर्ज के बजाय हमेशा रिबास करने के लिए सेट किया है, ताकि ऊपर के आउटपुट का हिस्सा सामान्य हो।

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

मैंने इसके लिए जाँच की है:

  • Dmesg या systemd जर्नल में संदेश। दूर से भी प्रासंगिक कुछ नहीं।
  • ड्राइव या फ़ाइल सिस्टम की विफलता (LVM + LUKS + EXT4 सभी सामान्य दिखते हैं) का कोई संकेत नहीं है। खोया + पाया कुछ भी नहीं है।
  • मैंने कुछ और नहीं चलाया। इतिहास में ऐसा कुछ भी नहीं है जो मैं ऊपर नहीं दिखा रहा हूं, और इस दौरान किसी अन्य टर्मिनल का उपयोग नहीं किया गया था। ऐसी कोई भी rmकमांड नहीं है जो गलत CWD आदि में निष्पादित हो सकती है।
  • एक और निर्देशिका में दूसरे git रेपो पर पोक करने से कोई स्पष्ट असामान्यता नहीं दिखाई देती है git pull

मुझे यहां और क्या चाहिए?


4
@ पैट्रिक जैसा कि मैंने पहले ही प्रश्न में समझाया था, कोई .gitमौजूद नहीं है। कुछ भी नहीं करता है- जो रूट रूट डायरेक्टरी हुआ करता था, उसमें कुछ भी नहीं है।
कालेब

2
@Alexander पुल ऑपरेशन सामान्य है (अन्य जो मर्ज के बजाय एक रिबेस है)। एक जबरन अपडेट के बारे में नोटिस यह संकेत दे रहा है कि मैं जिस रेपो को खींच रहा हूं, उसमें एक बल धक्का था जो इसे स्थानीय रेपो की तुलना में एक अलग स्थिति से रीसेट करता है। यह सामान्य है क्योंकि मैं अपने कंप्यूटरों के बीच सक्रिय रूप से विकसित और बार-बार विद्रोही सामग्री को सिंक्रनाइज़ कर रहा हूं, न कि एक सार्वजनिक शाखा जिसे अन्य डेवलपर्स देखेंगे।
कालेब

3
@ अपने शेल प्रॉम्प्ट में git ब्रांच इंडिकेशन शामिल है, जिसका अर्थ है PS1 का गठन जिसमें आपके लॉग में उजागर नहीं किए गए git कमांड शामिल हैं। वे मुख्य रूप से तस्वीर बदल सकते हैं और मुद्दा स्रोत हो सकते हैं। आपको अपने शेल प्रॉम्प्ट का निर्माण कैसे किया जाता है, यह बताने के लिए प्रश्न को अपडेट करना चाहिए कि वर्तमान शाखा को प्राप्त करने के लिए कौन सी कमांड चलती हैं, और पुनर्विचार करें कि वे आपके रेपो को कैसे खराब कर सकते हैं।
निचे

2
@ कालेब आपको वास्तव में गिट विकास मेलिंग सूची पर पूछना चाहिए; आप इसे बग रिपोर्ट के रूप में लिख सकते हैं, या बस अनौपचारिक रूप से पूछ सकते हैं - यह वैसे भी समान है। कुछ डेवलपर्स हैं जो प्रभावशाली रूप से अच्छी तरह से जानते हैं - वे शायद अंतर्ज्ञान से बता सकते हैं कि क्या हो सकता है। (यदि नहीं, तो वे केवल चुपचाप चर्चा का पालन करेंगे।) और वे जानते हैं कि क्या यह पहले खुश था। (इसे रिपोर्ट करने के लिए "बग" के लिए बग की रिपोर्ट करने का एक तरीका है)
वोल्कर साइगेल

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

जवाबों:


6

हां, gitमेरा होमवर्क खा लिया। यह सब।

मैंने ddइस डिस्क की छवि घटना के बाद बनाई और बाद में इसके साथ खिलवाड़ किया। सिस्टम लॉग से घटनाओं की श्रृंखला का पुनर्निर्माण करते हुए, मैं यह बताता हूं कि जो हुआ वह कुछ इस तरह था:

  1. pacman -Syuइस घटना के कुछ दिन पहले एक सिस्टम अपडेट कमांड ( ) जारी किया गया था।
  2. एक विस्तारित नेटवर्क आउटेज का अर्थ था कि यह पैकेज डाउनलोड करने की पुन: कोशिश कर रहा था। इंटरनेट की कमी से निराश होकर, मैंने सोने के लिए सिस्टम लगा दिया और बिस्तर पर चला गया।
  3. दिनों के बाद सिस्टम जाग गया था और उसने फिर से पैकेज ढूंढना और डाउनलोड करना शुरू कर दिया।
  4. पैकेज रिपॉजिट कुछ समय पहले ही समाप्त हो गया था जब मैं इस रिपॉजिटरी के साथ गड़बड़ कर रहा था।
  5. सिस्टम glibc इंस्टालेशन के बाद git checkoutऔर उसके बाद अपडेट हुआ git pull
  6. gitबाइनरी के बाद बदल दिया है git pullशुरू कर दिया और इससे पहले कि यह समाप्त हो गया।
  7. और सातवें दिन, gitअपने सभी मजदूरों से विश्राम किया। और दुनिया को मिटा दिया ताकि बाकी सबको भी आराम करना पड़े।

मुझे ठीक से पता नहीं है कि दौड़ की स्थिति क्या थी, जिससे यह हुआ, लेकिन एक ऑपरेशन के बीच में बायनेरिज़ को स्वैप करना निश्चित रूप से अच्छा नहीं है और न ही एक परीक्षण योग्य / दोहराने योग्य स्थिति है। आमतौर पर एक रनिंग बाइनरी की एक कॉपी मेमोरी में स्टोर की जाती है, लेकिन gitयह अजीब है और जिस तरह से यह खुद के संस्करणों को फिर से पैदा करता है, मुझे यकीन है कि इस गड़बड़ के लिए नेतृत्व किया गया है। जाहिर है कि यह सब कुछ नष्ट करने के बजाय मर जाना चाहिए था, लेकिन ऐसा ही हुआ।


1
git विफल हो सकता था क्योंकि git डिफेंडेंड कमांड का उपयोग कर बना है, इसके बजाय एक बाइनरी। एक साधारण Git पुल निष्पादित करता git-fetch, git-rebaseया git-mergeऔरgit gc
Ferrybig

2

संभवतः नष्ट किए जाने वाले फ़ाइल पथ को परिभाषित करने में विफल होने से।

आपके मामले ने मुझे एक सुंदर दिन याद दिलाया कि जब मेरे होममेड remove(path)तरीके ने रूट फ़ोल्डर को हटाने की कोशिश की थी, क्योंकि दिए गए पैरामीटर खाली स्ट्रिंग था जिसे ओएस ने सही (!) रूट फ़ोल्डर के रूप में ठीक किया था।

यह एक समान गिट बग हो सकता है। ऐसा है कि:

  1. Rebase कमांड एक फ़ाइल को हटाना चाहती है जैसे remove(project_folder + file_path)(छद्म कोड)
  2. किसी file_pathसमय खाली था।
  3. कमान का मूल्यांकन कुछ इस तरह से किया जाता है remove(project_folder)

1

भाग्य के साथ, आप इसे निम्न आदेश के साथ ठीक कर सकते हैं:

git reset --hard ORIG_HEAD  

जब संभावित खतरनाक बदलाव शुरू होते हैं, तो git ORIG_HEAD में आपकी वर्तमान स्थिति को चुरा लेता है। इसके साथ आप एक मर्ज या रिबेस को पूर्ववत कर सकते हैं।

गिट मैनुअल: एक मर्ज को पूर्ववत करना


4
मुझे नहीं लगता कि आपने पूरा प्रश्न पढ़ा है। इस प्रकार का फिक्स सवाल से पूरी तरह से बाहर है क्योंकि कोई गिट मेटा-डेटा नहीं है । इस तरह से एक रीसेट करने के लिए एक मौजूदा .it निर्देशिका और उसमें से कुछ वस्तुओं को काम करने की आवश्यकता होती है। मेरे पास कुछ नही है। यह केवल एक गड़बड़ काम करने वाली निर्देशिका नहीं है, यह अब किसी भी प्रकार का एक भंडार नहीं है।
कालेब

आह, मेरी क्षमायाचना। यह बहुत ही असामान्य है। अगर git repo चला गया है तो मुझे लगता है कि पुनर्प्राप्त करने का कोई तरीका नहीं होगा जब तक कि आप linux में फाइल को शैडो नहीं कर रहे हैं और फाइलों का fs बैकअप है। मैं अपना उत्तर हटा दूंगा क्योंकि यह अप्रासंगिक है।
राउटरिनेटर

हाँ, मुझे पता है कि यह एक असामान्य समस्या है (और मेरे पास बैकअप है)। यहाँ मेरा सवाल यह है कि यह कैसे गलत हो गया ... कहाँ git में बग देखने के लिए या मेरे फाइल-सिस्टम ड्राइवर या जो कुछ भी इस तरह के एक ऑपरेशन के बीच में एक निर्देशिका खाने के लिए borked हो सकता था।
कालेब

मैं भी बहुत उत्सुक हूं। मेरे रेपोस के साथ ऐसा होने के लिए कुछ करना होगा।
रॉटिनेटर

-1

लगता है कि कोई git push --forceइस रेपो पर भागा , और आपने उन परिवर्तनों को नीचे खींच लिया। रेपो को नए सिरे से क्लोन करने की कोशिश करें, जिससे आपको फिर से एक साफ-सुथरी अवस्था में वापस जाना चाहिए।


1
मजबूर धक्का ने अंतिम मुट्ठी भर लोगों को विद्रोह कर दिया। यही कारण है कि मैं नीचे खींच लिया था (काम कर निर्देशिका अब एक काम कर निर्देशिका नहीं है!) और भले ही यह फिर से क्लोनिंग कोई मतलब नहीं होता था।
कालेब

4
मुझे नहीं लगता कि आप किसी के निकाल सकते हैं .gitएक मजबूर धक्का के साथ निर्देशिका
Grzegorz
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.