गिट: झूठी विलय संघर्ष?

Question

मैं कुछ वर्षों के लिए गिट का उपयोग कर रहा हूं, और प्रत्येक बार एक विलय करने के दौरान, गिट कुछ विचित्र संघर्षों की रिपोर्ट करता है। यहाँ .htaccess फ़ाइल का एक उदाहरण है, जब मैं Drupal कोर के नए 7.24 रिलीज में विलय कर दिया से:

# Protect files and directories from prying eyes. 
<FilesMatch "\.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl)(~|\.sw[op]|\.bak|\.orig|\.save)?$|^(\..*|Entries.*|Repository|Root|Tag|Template)$|^#.*#$|\.php(~|\.sw[op]|\.bak|\.orig\.save)$"> 
<<<<<<< HEAD 
    Order allow,deny 
</FilesMatch> 

# Hide important scripts from malicious users. 
<FilesMatch "^(autoinstall\.php|install\.php|update\.php)$"> 
======= 
>>>>>>> 7.24 
    Order allow,deny 
</FilesMatch> 

कैसे वहाँ एक संघर्ष यहाँ है? यह व्हाइटस्पेस/एंडलाइन मतभेदों का एक संभावित मामला भी नहीं है: संघर्ष के 7.24 खंड में कुछ भी नहीं है।

गिट इस बारे में शिकायत क्यों कर रहा है? मैं शायद कुछ मौलिक गलत समझ रहा हूँ ...

Answer 1

आप केवल दो तरफ देख रहे संघर्ष को नहीं रोक सकते हैं। एक संघर्ष तब होता है जब दोनों पक्ष आम पूर्वजों से अलग-अलग परिवर्तन करते हैं।

तथ्य यह है कि एक तरफ "कुछ नहीं" कोई फर्क नहीं पड़ता - पूर्वजों में कुछ था, और दोनों पक्षों ने इसे बदल दिया।

आप संघर्ष फ़ाइलों में पूर्वजों को दिखाकर संघर्ष के बारे में अधिक डेटा प्राप्त कर सकते हैं; आप सेट कर सकते हैं:

git config merge.conflictstyle diff3 

जो आपको संघर्ष के सभी तीन पक्ष दिखाएगा।

Answer 2

Git अपने मर्ज के लिए एक साझा पूर्वज का चयन करता है:

0 
|_________ 
    |  | 
    a  b 
    |_____|_ 
      | 
      M 

Git पता लगाता है कि a और b दोनों 0 से परिवर्तन कर रहे हैं, तो यह इसे रोकने मर्ज मुद्दे का कारण बनता है स्वचालित रूप से मर्ज किए गए फ़ाइल M का उत्पादन करने से।

क्या आपने इसे उचित 3-तरफा विलय टूल में देखा है जैसे p4merge? यह आपको यह दिखाने में मदद कर सकता है कि कौन सा गिट सोचता है कि साझा पूर्वजों और यह विरोधाभासी परिवर्तन के रूप में क्या समझता है।

Answer 3

वहाँ क्या संभावना यहाँ फर्जी संघर्षों के साथ हो रहा है की एक सभ्य व्याख्या दी गई है: The criss-cross merge case (2005-04-28)

A 
|\ 
| \ 
| \ 
| \ 
| \ 
|  \ 
|  \ 
B8  C3 
|\  /| 
| \ /| 
| \/| 
| X | 
|/\ | 
|/ \ | 
|/  \| 
D8  E3 
\  | 
    \  | 
    \ | 
    \ | 
    \ | 
     \ | 
     \| 
     ? 

[...]

समस्या तीन तरह मर्ज के लिए कोई भी पूर्वज यह है कि है जो सही काम करता है।

संयोग से, यह पोस्ट ब्रैम कोहेन - बिटकटेंट के लेखकों में से एक द्वारा लिखी गई थी। बाद में उन्होंने his own alternative to Git विकसित करने की कोशिश की कि उन्हें उम्मीद है कि इस तरह के मुद्दों के आसपास हो जाएगा। समस्या का उनका विश्लेषण स्पॉट पर है, लेकिन मुझे नहीं लगता कि वह वास्तव में इसे हल करने में सक्षम था। इसके पीछे दिलचस्प कारण क्यों हैं कि यह संभवतः असफल क्यों है, लेकिन उस खरगोश छेद के लिए एक स्टैक ओवरफ्लो पोस्ट सही जगह नहीं है।