-
patch theory पर आधारित होने के बावजूद तेज़ और scalable
-
Commutation
→ हर change को version id बदले बिना, क्रम की परवाह किए बिना लागू किया जा सकता है
→ git rebase या hg transplant की तुलना में कहीं अधिक सरल workflow
→ branch जैसी channels सुविधा है, लेकिन दूसरे सिस्टमों की तरह यह उतनी महत्वपूर्ण नहीं है। उदाहरण के लिए, feature branch Pijul में बस एक change है
→ history को साफ-सुथरा रखना default setting है
- Merge correctness
→ Pijul merge के समय कुछ गारंटी देता है
→ सबसे महत्वपूर्ण बात यह है कि lines का क्रम हमेशा बना रहता है। यह 3-way merge से अलग है, जहाँ कभी-कभी lines आपस में गड़बड़ा जाती हैं
→ जब क्रम तय नहीं किया जा सकता, जैसे simultaneous editing में, तो conflict होता है; यह उन सिस्टमों से अलग है जो इसे "Automatic" या "No Conflict" मान लेते हैं
- First-class conflicts
→ Pijul में conflict को "merge failure" नहीं, बल्कि एक standard case के रूप में model किया गया है
→ खास तौर पर, दो changes के बीच होने वाला conflict एक single change के रूप में resolve होता है
- Partial Clones
→ Commutation का उपयोग करके repository के केवल छोटे subset को clone किया जा सकता है। वास्तव में उस subset पर changes लागू करना भी संभव है
→ Partial Clone पर किया गया काम ऐसे changes बनाता है जिन्हें बड़े repositories में आसानी से भेजा जा सकता है
3 टिप्पणियां
ईमानदारी से कहूँ तो Git भले ही कामकाजी दुनिया में standard की तरह इस्तेमाल होता है, लेकिन यह काफ़ी असुविधाजनक रहा है — — अब समय आ गया है कि Rust-आधारित Pijul पर धीरे-धीरे स्विच किया जाए
svn और git के बीच (डिस्ट्रिब्यूटेड रिपॉजिटरी होने की बात को छोड़कर) सबसे बड़ा फर्क यह है कि svn जहाँ diff को मैनेज करता है, वहीं git snapshots को मैनेज करता है। इसलिए जब इसे patch theory कहा जा रहा है, तो मुझे लगता है कि शायद यह diff को मैनेज करने वाली दिशा में होगा।
Patch theory (Theory of Patches) के बारे में आप distributed version control system Darcs में देख सकते हैं.
Darcs और Git की तुलना करते समय इसे इस तरह समझाया जाता है.
Git में जिन बदलावों के सेट को आप रिकॉर्ड करते हैं, उसे “commit” कहा जाता है, जबकि Darcs में उसे “patch” कहा जाता है.