2011-10-26 15 views
6

जब कोई गिट रिबेस एक संघर्ष पाता है तो इसका क्या अर्थ है, लेकिन फ़ाइल में कोई स्पष्ट समस्या नहीं है? प्रश्न में फ़ाइल में कोई संघर्ष मार्कर नहीं है, और git mergetool कहता है "विलय करने के लिए कुछ भी नहीं"।गिट विद्रोह संघर्ष विलय करने के लिए कुछ भी नहीं?

विकल्प रहे है या जोड़ने रीसेट:

# Unmerged paths: 
# (use "git reset HEAD <file>..." to unstage) 
# (use "git add/rm <file>..." as appropriate to mark resolution) 
# 
# both modified:  filename.js 

कैसे मैं कैसे पता है कि इस बारे में और जो रास्ता लेने के लिए है?

git ls-files -s filename.js 3 पंक्तियों देता है:

100644 d2c915b1d632b8ef8fbcf056824fb7fac7824ab9 1 filename.js 
100644 9010798f1d19ac712196b1fc9b0870fd332b1275 2 filename.js 
100644 b3ab7ec50812c73a3ec97bf0985f3226ec13cbc8 3 filename.js 

ठीक मैनुअल के अनुसार, इस आदेश हमें मोड बिट्स, वस्तु का नाम, और मंच संख्या बताता है। मोड बिट्स वही हैं। तो 1, 2, और 3 क्या हैं, और वे "दोनों संशोधित" क्यों हैं, लेकिन संघर्ष मार्कर नहीं दिखा रहे हैं?

+1

यह सफेद जगह अंतर हो सकता है। – birryree

+0

यह देखने के लिए कि क्या संस्करण वास्तव में अलग हैं, 'git ls-files -s filename.js' आज़माएं। –

+0

@ जोशली मैंने आपकी टिप्पणी के जवाब में अपना प्रश्न अपडेट किया। आउटपुट 3 ब्लब्स दिखाता है, लेकिन मुझे यकीन नहीं है कि वहां से कहां जाना है, मुझे मतभेद कैसे मिलेंगे, या बताएं कि कौन सा "एड" या "रीसेट" है? –

उत्तर

7

सूचकांक में संस्करणों में चिह्नित 1, 2, और 3 निम्नलिखित अर्थ है:

  1. फ़ाइल के रूप में दो करता आप विलय कर रहे हैं की एक आम पूर्वज में था।
  2. फ़ाइल HEAD में थी, यानी जब आप विलय करते थे तो आपकी वर्तमान प्रतिबद्धता थी।
  3. फ़ाइल इस प्रतिबद्धता में है कि आप HEAD में विलय करने का प्रयास कर रहे हैं।

इस जानकारी के लिए मेरा स्रोत the git manual's useful section on resolving conflicts है।

both modifiedgit status में आउटपुट इंगित करता है कि निश्चित रूप से फाइल दो अलग-अलग तरीकों से बदल दी गई है कि आप अपने सामान्य पूर्वजों के बाद विलय कर रहे हैं।

यह मेरे लिए रहस्यमय है कि आप फ़ाइल में संघर्ष मार्कर क्यों नहीं देखते हैं, हालांकि - git ls-files -s के उत्पादन में ब्लब्स के अलग-अलग ऑब्जेक्ट नाम (हैंश) हैं जो इंगित करता है कि बाइट-बाय-बाइट वे निश्चित रूप से करते हैं अलग सामग्री अगर आप फ़ाइल से खुश हैं क्योंकि यह आपकी कामकाजी प्रतिलिपि में है, तो आप केवल git add filename.js और फिर git rebase --continue कर सकते हैं। हालांकि, किसी भी मामले में आप यह जानना चाहेंगे कि ये अंतर क्या था। ऐसा करने के लिए, मैं निम्नलिखित की कोशिश करेंगे:

git diff :2:filename.js filename.js 

... जो HEAD में संस्करण के बीच मतभेद और अपने वर्तमान कार्यशील प्रतिलिपि दिखाई देगा। इसी तरह, आप की कोशिश कर सकते हैं:

git diff :3:filename.js filename.js 

... कि में संस्करण विलय कर दिया जा रहा था और अपने काम की नकल के बीच अंतर को देखने के लिए।

1

1, 2 और git ls-files -s की 3 का प्रतिनिधित्व करता है एक 3-way merge की "मंच": 1 आम पूर्वज है, 2 वर्तमान शाखा प्रमुख है और 3 अन्य शाखा प्रमुख है।लिनक्स पर, आप फ़ाइलों के बीच क्या अलग है यह देखने के लिए निम्न आदेशों को आजमा सकते हैं:

$ git cat-file blob d2c915b1d632b8ef8fbcf056824fb7fac7824ab9 | xxd -ps 
$ git cat-file blob 9010798f1d19ac712196b1fc9b0870fd332b1275 | xxd -ps 
$ git cat-file blob b3ab7ec50812c73a3ec97bf0985f3226ec13cbc8 | xxd -ps 
संबंधित मुद्दे