डिफ़ चेकर

हाइलाइटिंग के नीचे, कोई डिफ़ टूल एक ख़ास मैचिंग समस्या हल कर रहा होता है: दो लाइन-लिस्ट दिए जाने पर, वह सबसे लंबा क्रम ढूँढना जो दोनों दस्तावेज़ों में एक ही सापेक्ष क्रम में मौजूद है — उस साझा क्रम में सब कुछ बिना बदलाव के छोड़ दिया जाता है, और बाक़ी सब जोड़ा या हटाया गया माना जाता है। यही वह अंतर्ज्ञान है जिस पर "लॉन्गेस्ट कॉमन सबसीक्वेंस" नाम की अवधारणा बनी है, जिस पर हर सामान्य-मक़सद डिफ़ एल्गोरिद्म बना है, ख़ुद Git का इस्तेमाल किया गया एल्गोरिद्म भी शामिल है। यह एक ऐसी बात समझाता है जो वरना अजीब लगती है: किसी दस्तावेज़ के नीचे से टेक्स्ट का कोई ब्लॉक ऊपर ले जाना आमतौर पर एक "मूव" ऑपरेशन की बजाय एक बड़े हटाव और बड़े जोड़ के रूप में बताया जाता है — एल्गोरिद्म सिर्फ़ साझा क्रम ढूँढ रहा है, और कोई हटाया गया ब्लॉक उस क्रम को उसकी पुरानी और नई दोनों पोज़िशन पर तोड़ देता है।

यह भी समझाता है कि Lines मोड में किसी लंबी लाइन का एक-कैरेक्टर एडिट पूरी लाइन को क्यों बदला हुआ चिन्हित करता है: एल्गोरिद्म पूरी लाइनों की तुलना अविभाज्य इकाइयों के रूप में करता है, तो "एक अक्षर छोड़कर वही लाइन" और "पूरी तरह अलग लाइन" को एक जैसा माना जाता है — दोनों बराबरी की जाँच में नाकाम रहते हैं और दोनों एक लाइन हटाई गई, एक लाइन जोड़ी गई गिने जाते हैं। यही वह स्थिति है जहाँ Word मोड में स्विच करना मदद करता है, क्योंकि यह वही अंतर्निहित अवधारणा एक स्तर नीचे दोहराता है, हर लाइन की बजाय हर शब्द को मिलान की इकाई मानते हुए।

Lines मोड सही डिफ़ॉल्ट है हर उस चीज़ के लिए जहाँ लाइन ख़ुद अपने आप में एक मायने रखने वाली इकाई है — सोर्स कोड, JSON ऑब्जेक्ट, CSV रो, लॉग एंट्री — क्योंकि इन फ़ॉर्मेट में एक लाइन आमतौर पर एक पूरा आइडिया दिखाती है, और यह जानना कि कोई ख़ास लाइन बदली, यह अपने आप में उपयोगी जानकारी है, चाहे उसके अंदर कौन-सा कैरेक्टर हिला हो। Word मोड तभी ज़्यादा उपयोगी बनता है जब मायने रखने वाली इकाई किसी लाइन से छोटी हो: प्रोज़ का कोई पैराग्राफ़, कॉन्ट्रैक्ट की कोई शर्त, या किसी लंबे दस्तावेज़ का कोई वाक्य, जहाँ दिलचस्प बदलाव आमतौर पर एक शब्द या वाक्यांश होता है और आस-पास का वाक्य वैसा ही रहता है। ऐसे टेक्स्ट की लाइन-दर-लाइन तुलना करने पर एक शब्द के एडिट के लिए पूरा पैराग्राफ़ "बदला हुआ" चिन्हित हो जाएगा, जो तकनीकी रूप से सही है लेकिन आपको यह कुछ नहीं बताता कि असल में क्या बदला जब तक आप पूरा पैराग्राफ़ ख़ुद दोबारा न पढ़ें।

एक व्यावहारिक नियम: किसी स्ट्रक्चर्ड या लाइन-आधारित चीज़ के लिए पहले Lines मोड आज़माएँ, और ख़ास तौर पर तब Word मोड पर स्विच करें जब Lines मोड का नतीजा लाल और हरे के दो बड़े ब्लॉक दिखाए जो लगभग एक जैसे लगते हों — यह पैटर्न इस बात का संकेत है कि असली फ़र्क़ छोटा है और वरना बिना बदले टेक्स्ट के अंदर दबा हुआ है।

मर्ज करने से पहले सोर्स कोड के दो रिविज़न की तुलना करना पाठ्यपुस्तक जैसा इस्तेमाल है, लेकिन यही तकनीक कोड रिव्यू से कहीं आगे भी अच्छी तरह लागू होती है: किसी कॉन्फ़िगरेशन फ़ाइल के दो एक्सपोर्ट की तुलना करके यह पता लगाना कि किसी वर्किंग डिप्लॉयमेंट और किसी टूटे हुए के बीच बिल्कुल कौन-सी सेटिंग बदली, किसी CSV एक्सपोर्ट के दो वर्ज़न जाँचकर यह पक्का करना कि सिर्फ़ उम्मीद की गई रो ही बदली हैं, या किसी कॉन्ट्रैक्ट ड्राफ़्ट की पिछले रिविज़न से तुलना करके बिना पूरा दस्तावेज़ दोबारा साथ-साथ पढ़े हर वह शर्त ढूँढना जो दूसरे पक्ष ने बदली। इन सभी मामलों में डिफ़ टूल की क़ीमत एक जैसी है — यह "क्या ये दोनों चीज़ें अलग हैं, और अगर हाँ तो कहाँ" को मैनुअल साथ-साथ पढ़ने की मेहनत से एक तुरंत मिलने वाले विज़ुअल जवाब में बदल देता है।