DiffX – अगली पीढ़ी का स्केलेबल Diff फ़ॉर्मैट

 (diffx.org)
2 पॉइंट द्वारा GN⁺ 2025-06-05 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • मौजूदा Unified Diff फ़ॉर्मैट में ऐसी सीमाएँ हैं जो डेवलपमेंट environment की आवश्यकताओं को पूरी तरह प्रतिबिंबित नहीं कर पातीं
  • DiffX मौजूदा फ़ॉर्मैट के साथ पूरी तरह संगत है, और future-oriented संरचना तथा metadata extensibility प्रदान करता है
  • कई commit जानकारी, binary files, character encoding और metadata को संरचित तरीके से संग्रहीत किया जा सकता है
  • मानकीकृत parsing rules के आने से patch, code review आदि जैसे विभिन्न tools के साथ आसान integration संभव है
  • मौजूदा tools और workflows में इसे बिना समस्या के इस्तेमाल किया जा सकता है, और केवल नई सुविधाओं के लिए संबंधित tool support की आवश्यकता होती है

डेवलपर और Diff फ़ाइलें

  • सॉफ़्टवेयर डेवलपर आमतौर पर Git, Subversion, CVS आदि में diff फ़ाइलों के जरिए कोड बदलावों की जाँच करते हैं
  • Diff फ़ाइलें text insertion(+)·deletion(-) के साथ फ़ाइल नाम, path, timestamp और कुछ metadata शामिल करने वाली संरचना होती हैं
  • अधिकतर tools और users Unified Diff फ़ॉर्मैट का उपयोग करते हैं, और यह तरीका अपेक्षाकृत सरल ढंग से differences को विज़ुअलाइज़ करता है

Unified Diff की सीमाएँ

  • Unified Diff केवल file identification, change range, और जोड़ी/हटाई गई lines को standardize करता है, लेकिन encoding, revision, extended metadata आदि को standardize नहीं करता
  • विभिन्न source management systems का समर्थन, reliable parsing, और समृद्ध जानकारी निकालना कठिन है
  • निम्न जैसी समस्याएँ लगातार सामने आती रहती हैं
    • एक साथ कई commits को व्यक्त नहीं किया जा सकता
    • binary files के लिए समर्पित standard फ़ॉर्मैट का अभाव है
    • character encoding का पता न होने से information loss और confusion होता है
    • arbitrary metadata के standardization की कमी के कारण हर tool का रूप अलग होता है

सुधार की दिशा

  • मौजूदा Unified Diff में संरचना और standards की कमी है, लेकिन यह लचीला है और पहले से ही विभिन्न environments में व्यापक रूप से उपयोग किया जाता है
  • Git Diff फिलहाल de facto standard की भूमिका निभा रहा है, लेकिन फिर भी फ़ॉर्मैट की आधिकारिक specification और universal extensibility की कमी है
  • मौजूदा Unified Diff के फायदों को बनाए रखते हुए, extensibility और standardized structure जोड़ने वाले नए फ़ॉर्मैट की आवश्यकता बढ़ रही है

DiffX क्या है

  • DiffX एक extensible Diff फ़ॉर्मैट है, जो मौजूदा tools के साथ पूरी तरह संगत है, human readability बनाए रखता है, और साथ ही metadata तथा संरचना को व्यवस्थित रूप से समाहित कर सकता है
  • syntax उदाहरण:
    • फ़ाइल, commit, और पूरे diff के लिए metadata और body को संरचित और extensible तरीके से संग्रहीत किया जाता है
    • उदाहरण output में #diffx: जैसी syntax, section, metadata(JSON), file path, और commit जानकारी शामिल होती है

DiffX की मुख्य विशेषताएँ

  • मानकीकृत parsing rules प्रदान करता है, जिससे tools विश्वसनीय तरीके से जानकारी पढ़ और लिख सकते हैं
  • metadata storage और management का औपचारिक समर्थन: पूरे diff, commit, और file unit स्तर पर उपयोग संभव है
  • मौजूदा parser, patcher, code review आदि सभी tools के साथ संगत है (नई सुविधाओं के लिए support चाहिए, लेकिन मौजूदा सुविधाओं की compatibility बनी रहती है)
  • एक ही फ़ाइल में कई commits, binary diff, text encoding जानकारी आदि कई तरह की सामग्री को कुशल संरचना में व्यक्त किया जा सकता है
  • tools में diff खोलकर आवश्यक जानकारी दर्ज, संशोधित, और फिर से सहेजने वाली mutability का समर्थन करता है

DiffX के लक्ष्य और गैर-लक्ष्य

  • यह सभी tools पर इस फ़ॉर्मैट का समर्थन थोपने या compatibility समस्याएँ पैदा करने का लक्ष्य नहीं रखता
  • यह vendor lock-in पैदा नहीं करता और मौजूदा workflows को नहीं तोड़ता
  • यह मौजूदा Diff फ़ाइलों की समस्याओं को हल कर, development, review, और analysis tools में अधिक सुसंगत और विश्वसनीय उपयोग अनुभव प्रदान करता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-06-05
Hacker News राय

  • मुझे ..meta और ...meta जैसे पदानुक्रमित और जटिल फ़ॉर्मैट पसंद नहीं हैं। अभिव्यक्ति की स्पष्टता के लिए diff को सिर्फ़ तीन स्तरों—पूरे diff, फ़ाइल, और chunk—में बाँटकर, हर एक को अलग नाम देना ज़्यादा समझने योग्य फ़ॉर्मैट बनाता। meta block के बिना भी एक नज़र में लक्ष्य पहचाना जा सकता है, इसलिए गलती या error भी कम होंगे। पूरे diff का metadata और फ़ाइल-स्तर metadata का एक ही field संरचना होना भी तर्कसंगत नहीं लगता। और JSON तथा key=value दो अलग फ़ॉर्मैट की ज़रूरत क्यों है, यह भी समझ नहीं आता; अगर संभालने वाली चीज़ें कम हैं, तो सिर्फ़ एक फ़ॉर्मैट इस्तेमाल करना implementation या existing tools के integration के लिए कहीं बेहतर है (grep, sed या jq में से एक ही काफ़ी होगा)। अतिरिक्त रूप से, list में trailing comma की अनुमति होती तो अच्छा रहता, और diff मूलतः partial apply होने योग्य संरचना है, तो यह फ़ॉर्मैट उस पर क्या असर डालता है यह जानना चाहूँगा (उदाहरण के लिए, diff का सिर्फ़ एक हिस्सा apply करना ho तो preamble कॉपी करना और block भी अलग से कॉपी करना पड़ता है, जो झंझट लगता है)। यह भी जिज्ञासा है कि revision फ़ाइल का गुण है या commit checksum।

    • हमने संरचना के लिए कई approaches आज़माए, और अंततः parsing के नज़रिए से सरलता के लिए #<section_level><section_type> रूप चुना। हर meta block में बस vertical level जाँचना होता है, और dots की संख्या देखकर स्वाभाविक रूप से पता चल जाता है कि metadata किस स्तर का है। key/value header फ़ॉर्मैट का उद्देश्य सिर्फ़ वे सरल properties रखना था जिन्हें parser पहले से जानता हो, जबकि मुक्त metadata को अलग meta block में रखने के लिए डिज़ाइन किया गया। मौजूदा JSON के अलावा, आगे चलकर किसी और serialization पद्धति की ज़रूरत पड़े तो header में फ़ॉर्मैट निर्दिष्ट करके extensibility भी रखी जा सकती है। यह सरलता और flexibility के बीच संतुलन बनाने की कोशिश का परिणाम है। trailing comma मैं व्यक्तिगत रूप से जोड़ना चाहूँगा, लेकिन base-level JSON compatibility की वजह से JSON5 parser को अनिवार्य बनाना मुश्किल है। diff अब भी split किया जा सकता है, और Unified Diff जिन हिस्सों को अनदेखा करता है उनमें जानकारी रखने के कारण GNU patch जैसे tools में इसे ignore किया जाता है, इसलिए कोई समस्या नहीं। हालाँकि, अगर इसे दो DiffX फ़ाइलों में बाँटना हो तो header फिर से जोड़ना पड़ेगा, जिससे थोड़ी जटिलता आ सकती है। कुछ SCM के diff split होने पर कुछ metadata (जैसे parent commit जानकारी) खो सकते हैं, या apply target के आधार पर information loss हो सकता है। revision हर SCM में अलग होता है; कहीं commit ID, कहीं file-specific ID, कहीं उनका संयोजन, और कभी अतिरिक्त जानकारी की ज़रूरत होती है। यह संरचना SCM-विशिष्ट अलग-अलग ज़रूरतों को पूरा करने के लिए सोची गई है।

  • मेरी नज़र में नीचे दिए गए चार बिंदुओं में से, diff फ़ाइल के सामान्यीकरण के हिसाब से वास्तव में उचित सिर्फ़ binary patch notation का मानकीकरण है। बाकी सभी बातें किसी विशेष source control management system (SCM) के अंदरूनी data या protocol की समस्याएँ हैं, जो केवल उसके client, server, या backup system में ही मायने रखती हैं। बाकी सब अनावश्यक लगता है।

    • एक diff में कई commits सूचीबद्ध नहीं किए जा सकते

    • binary patch के लिए कोई standard नहीं है

    • text encoding पहचानी नहीं जा सकती (यह चुपचाप बड़ी समस्या बनती है)

    • arbitrary metadata के लिए कोई standard format नहीं है

    • हम 20 साल से 12 से अधिक SCM को जोड़ने वाला code review product बना रहे हैं, और इस दौरान हमने कल्पना से परे diff फ़ॉर्मैट और SCM-विशिष्ट समस्याओं का सामना किया है। end user को आम तौर पर इन बातों की चिंता नहीं करनी पड़ती, लेकिन tool development के दृष्टिकोण से ये ऐसे pain points थे जिन्हें हल करना ही पड़ता है। कुछ SCM के पास अपना diff फ़ॉर्मैट ही नहीं होता, या उसमें बहुत सी जानकारी गायब होती है (उदाहरण: deleted file दिखाना संभव नहीं), जिससे दूसरे tools फ़ाइलों को सही से पहचान नहीं पाते। इसी वजह से ऐसे सुधार ज़रूरी लगे।

    • आजकल कम आम है, लेकिन मैं भी अभी तक patch(1) जैसे tools कभी-कभी इस्तेमाल करता हूँ। कई platforms के developers साथ काम करें तो filename case-sensitivity, character encoding जैसी वजहों से तरह-तरह की समस्याएँ अब भी पैदा होती हैं।

  • अगर JSON को length जानकारी के साथ self-delimited फ़ॉर्मैट में रखा जाए, तो JSON के अंदर सिर्फ़ एक space बदलने पर JSON तो वैध रहेगा, लेकिन DiffX पूरे रूप में टूट सकता है। संरचनात्मक रूप से यह काफ़ी clunky और messy संयोजन लगता है (custom header और JSON payload का मिश्रण, dots गिने बिना अलग meta blocks में अंतर न कर पाना, दो parsers की ज़रूरत आदि)। metadata के लिए extensible diff को standardize करने का विचार अच्छा है, लेकिन यह implementation अभी trial-and-error जैसा लगता है।

  • मुझे लगता है patch फ़ॉर्मैट पहले से ही ये समस्याएँ हल कर रहा है। git format-patch विवरण लिंक

    • आज पहली बार पता चला कि ऐसा कोई फ़ॉर्मैट भी है, देखा। (मैं बस एक सामान्य internet user हूँ, लेखक नहीं।)

    • git में यह संभव है, लेकिन Review Board जैसे product को SVN, CVS, Perforce जैसे कई VCS के साथ integrate करना पड़ता है, इसलिए शायद इस फ़ॉर्मैट की पृष्ठभूमि वही है। मैंने भी Review Board और SVN का इस्तेमाल किया है, और कई developers के git-svn और svn मिलाकर काम करने पर review के समय diff upload में अक्सर समस्याएँ आती थीं। अगर दोनों तरफ़ support होने वाला कोई standard diff फ़ॉर्मैट होता, तो tool का उपयोग बहुत आसान होता।

  • मुझे वास्तव में यह ठीक से महसूस नहीं होता कि बताए गए मुद्दे मौजूद भी हैं (binary files को छोड़कर)।

    • encoding अलग हो तो भी patch algorithm वही रहता है, इसलिए उसकी चिंता करने की ज़रूरत नहीं (characters का valid utf-8 होना भी ज़रूरी नहीं)।

    • एक diff में कई commits रखने की भी ज़रूरत नहीं लगती; कई diff में बाँटना ज़्यादा सहज है।

    • metadata शायद सिर्फ़ system के अंदर ही उपयोगी होता है।

    • encoding के मामले में भी patch data को वैसे भी ascii-आधारित binary data की तरह handle करना चाहिए। mixed encoding में भी फ़ाइल modification हो सकती है, इसलिए encoding तय कर देने का बहुत अर्थ नहीं।

    • मुझे यह बिल्कुल समस्या नहीं लगती। जो लोग वास्तव में diff का बहुत इस्तेमाल करते हैं, उनके वास्तविक अनुभव सुनना बेहतर होगा। पहले से ठीक चल रहे फ़ॉर्मैट को बेवजह overengineering नहीं करना चाहिए।

    • binary data की समस्या निश्चित रूप से मौजूद है, ऐसा मैं मानता हूँ।

    • आम तौर पर ये समस्याएँ तब सामने आती हैं जब आप खुद tools बनाते हैं या किसी विशेष SCM से interface करना पड़ता है।

      1. encoding की समस्या filename और body दोनों में होती है। Git filename encoding का ध्यान रखता है, लेकिन ज़्यादातर SCM ऐसा नहीं करते, इसलिए एक environment में auto-generate हुआ diff दूसरे environment में filename नहीं ढूँढ पाता (मैंने यह Perforce, Subversion आदि में देखा है)। body में भी SCM के local encoding के कारण diff टूट सकता है। Windows-Linux के बीच आते-जाते line endings के मिल जाने से patch apply नहीं हुआ, या BOM की वजह से GNU patch टूट गया—ऐसा भी हुआ है।
      2. कई commits को एक साथ handle करते समय या tool में भेजते समय file omission या consistency जैसी कई समस्याएँ आ सकती हैं, और अलग-अलग diff पर sanity check करना झंझट है। tools किन फ़ॉर्मैट को support करते हैं, यह भी अलग-अलग होता है, इसलिए असुविधा होती है।
      3. repository में फ़ाइलें ढूँढने के लिए हर system को commit-level ID, file-level ID, दोनों का संयोजन, relationship जानकारी जैसे कई identifiers चाहिए होते हैं। symbolic links, file mode, और SCM-विशिष्ट गुण जैसी चीज़ें, जो Unified diff में नहीं होतीं, कभी-कभी अनिवार्य होती हैं।

  • पूरा दस्तावेज़ पढ़ना कठिन लगता है। मेरे लिए ‘diff’ का अर्थ दो वस्तुओं (फ़ाइल, directory आदि) के बीच का अंतर है, लेकिन TFA में जिस diff की बात है वह मेरे हिसाब से ‘patch’ है। यहाँ चर्चा असल में diff नहीं बल्कि patch metadata management की है। अगर metadata को JSON जैसे किसी अनिवार्य फ़ॉर्मैट में standardize किया जाए तो ठीक है, लेकिन यह अस्पष्ट self-describing length-delimited संरचना समस्या को छिपाने जैसी लगती है। standardization अच्छी बात है, लेकिन कोई और अधिक स्पष्ट रूप से संगठित समाधान चाहिए। मुझे यह भी दिलचस्प लगता है कि git diff शैली असल में de facto standard के अधिक करीब लगती है।

    • आख़िरी वाक्य से पूरी तरह सहमत हूँ, कई diff में बाँटकर लिखना ही काफ़ी है।

  • जिज्ञासा है कि यह फ़ॉर्मैट किस समस्या को हल करना चाहता है। कहा जा रहा है कि patch/diff फ़ॉर्मैट पर्याप्त अच्छे नहीं हैं, पर सुधार आखिर किसके लिए है? क्या GNU Patch community में शिकायतें बढ़ रही हैं, या और कोई कारण है? और अधिक स्पष्ट होना चाहिए। वास्तव में बेहतर patch फ़ॉर्मैट की ज़रूरत क्यों है, यह सवाल बना रहता है।

    • मैंने इस पर एक लंबी लिखाई अलग से संकलित की है जो यहाँ नहीं समा सकती। संक्षेप में, यह उन developers के लिए चिंता का विषय है जो खुद SCM बनाते हैं या SCM के साथ integrate करने वाले tools बनाते हैं। सामान्य users को इसकी चिंता करने की ज़रूरत नहीं। diff फ़ॉर्मैट भी हर SCM में अलग होता है—कुछ बहुत अच्छे बने हैं, कुछ बहुत अधूरे हैं, और कुछ में फ़ॉर्मैट है ही नहीं। Review Board जैसे product, जिन्हें कई SCM को cover करना पड़ता है, उनके लिए ऐसा unified standard व्यवहारिक रूप से बहुत ज़रूरी है। यह वास्तव में SCM vendors के साथ काम करते हुए मिले feedback को दर्शाने वाली सुधार कोशिश है।

    • यह Review Board-केंद्रित फ़ॉर्मैट जैसा लगता है। यह product कई VCS को support करता है, और source review में diff केंद्रीय भूमिका निभाता है, इसलिए शायद इसे अपनाया गया।

  • सबसे सामान्य और स्पष्ट diff प्रस्तुति यह है कि दोनों फ़ाइलें सीधे शामिल कर दी जाएँ। आज के समय में data size इतनी बड़ी समस्या नहीं, इसलिए diff a b | patch c की जगह apply a b c जैसा कुछ बनाया जा सकता है; उसके अंदरूनी representation का स्वरूप फिर मायने नहीं रखता। diff इंसानों के लिए पढ़ना कठिन है, और color side-by-side view कहीं बेहतर है, इसलिए शुरुआत से ही दोनों फ़ाइलें लेकर process करना ज़्यादा सहज है। मुझे नहीं लगता कि non-standardized diff को अलग से भेजना ज़रूरी है।

    • दो फ़ाइलों से बनने वाला diff सिर्फ़ एक ही प्रकार का नहीं होता; अलग-अलग उद्देश्यों के लिए कई तरह के diff बन सकते हैं। diff फ़ॉर्मैट होने से diff generation और apply logic को अलग किया जा सकता है, जिससे n*m समस्या n+m में बदल जाती है।

    • program updates जैसी स्थिति में हर बार पूरे 130GB को फिर से डाउनलोड करना परेशान करने वाला है, लेकिन लगभग समान फ़ाइलें compress भी आसानी से हो जाती हैं, इसलिए दो versions के बीच का अंतर भेजने का व्यावहारिक लाभ भी बड़ा है। सिर्फ़ original file का hash भेजकर compressed body ट्रांसफ़र करने जैसे और कुशल तरीके भी संभव लगते हैं।

    • बिना किसी dedicated container के दो फ़ाइल-जोड़ों का transport और management आसान नहीं है, और अगर 10 फ़ाइल changes + deletion + addition जैसे कई बदलावों को email आदि से भेजना हो, तो यह फिर से pre-VCS दौर की तरह tar/zip जैसी जटिल संरचनाओं की ओर लौटने जैसा लगेगा।

    • भले पूरे files भेजना diff से ज़्यादा सहज लगे, लेकिन वास्तविक उपयोग और environment के हिसाब से diff का महत्व अब भी बहुत है। आजकल LLM के साथ code edits जैसे outputs बनाते समय diff के रूप में अनुरोध करने पर tokens की बड़ी बचत होती है, और response latency 5-10 गुना तक कम हुई है—यानी उल्लेखनीय efficiency gain मिलता है। दोनों फ़ाइलें भेजना token waste और cost बढ़ाता है। code sandbox या remote machine पर जल्दी apply करना हो, तो diff बड़ा optimization लाभ देता है। अगर file A, A2 और diff AxA2 हो, तो A2 को reconstruct करना भी आसान है और storage optimization भी संभव है। merge के समय conflict हो तो तभी manual intervention किया जा सकता है। संक्षेप में, diff शानदार है।

  • अब भी यह शिकायत है कि diff tools newline unit पर बहुत अधिक निर्भर हैं। जब एक लाइन बहुत लंबी हो (उदाहरण: JSON, लंबे arrays आदि), तो review करना मुश्किल हो जाता है।

    • मैं भी सहमत हूँ। structured data (जैसे AST diff) के लिए बेहतर diff representations पर और काम किया जा सकता है। यह फ़ॉर्मैट (DiffX) मौजूदा Unified Diff फ़ॉर्मैट के extensible रूप पर केंद्रित है, और अगर AST जैसी अधिक विशिष्ट representation व्यापक हो जाए, तो उसे भी आसानी से embed और support करने लायक डिज़ाइन किया गया है।

    • आमतौर पर इस्तेमाल होने वाला रूप human readability और tool parsing के बीच समझौता है, इसलिए थोड़ा अधूरा-सा है। इस बार metadata extension से समस्या का कुछ हिस्सा हल करने की कोशिश हुई लगती है, लेकिन सच में अच्छा समाधान शायद ऐसा नया फ़ॉर्मैट होगा जो plain text न होते हुए भी पढ़ने में आसान और parse करने योग्य हो। लंबे lines या structured data के लिए मौजूदा से बेहतर diff algorithm बनाना कठिन चुनौती है, पर मुझे लगता है इसे हल किया जा सकता है।

    • git line diff से अधिक सूक्ष्म word diff भी support करता है, और उसका default delimiter whitespace है।

  • इस बात पर सवाल है कि metadata फ़ॉर्मैट के रूप में सिर्फ़ JSON ही support क्यों है। सामान्य प्रयोजन के लिए डिज़ाइन किए गए metadata standard में JSON उल्टा जटिल लगता है।

    • आप क्यों मानते हैं कि JSON अनावश्यक रूप से जटिल है, यह थोड़ा विस्तार से सुनना चाहूँगा।