गिट-एसवीएन लाइन अंतराल कैसे संभालता है?

Question

मैं core.autocrlf, core.eol + गीताट्रिब्यूट्स (Tim's post is excellent) के माध्यम से गिट स्वयं लाइन अंतराल को कैसे संभालता है, इस बारे में बहुत खुश हूं।

मेरे पास एक विंडोज गिट रेपो है जिसमें autocrlftrue पर सेट है। इसलिए, सभी टेक्स्ट फ़ाइलों को रेपो में LF के रूप में संग्रहीत किया जाता है और CRLF के रूप में कार्य निर्देशिका में रहते हैं। इस रेपो को एक एसवीएन रेपो से क्लोन किया गया था, जिसे हम अभी भी धक्का देने के लिए उपयोग करते हैं (एसवीएन रेपो सीआई आदि को ट्रिगर करने के लिए हमारे केंद्रीय, धन्य रेपो है)।

लेकिन मुझे नहीं पता कि git-svn पुश/पुल ऑपरेशंस के दौरान लाइन अंतराल को कैसे संभालता है।

क्या कोई इस बात में समझा सकता है कि git-svn इस उदाहरण में क्या करता है?

Answer 1

मुझे इसमें भी रूचि है। मान आप एक रेपो Git SVN क्लोन के माध्यम से बनाया गया था कि है, मुझे लगता है कि आप इसे विभाजित कर सकते हैं तीन अलग अलग सवाल में:

1. किसी भी Git न्यू लाइन सामान्य/परिवर्तन Git SVN पर होता है समय लाने, SVN से प्रतिबद्ध बढ़ने में गिट रेपो के लिए?
2. क्या कोई गिट न्यूलाइन सामान्यीकरण/परिवर्तन गिट प्रतिबद्ध समय पर होता है [यानी। एक सामान्य स्थानीय गिट के दौरान svn remotes के साथ एक रेपो करने के लिए प्रतिबद्ध]? समय मर्ज/रीबेस कैसे करें?
3. क्या कोई गिट न्यूलाइन सामान्यीकरण/परिवर्तन गिट svn dcommit समय पर होता है, धक्का/पुनः चलाने/svit के खिलाफ जो भी गिट करता है?

मैं सुनने के लिए क्या सैद्धांतिक रूप से इन सवालों के लिए सही हो चाहिए था खुशी होगी, लेकिन अब मैं एक छोटे से प्रयोग # 1 कम से कम इस मामले में कोई नई पंक्ति सामान्य है कि वहाँ दिखाने के लिए लगता है कि आपने क्या किया:

rem We'll make a svn repo with CRLF newlines, clone it into git with 
rem autocrlf enabled, and try to see if that results in LF-only newlines 
rem getting stored in the git repo 

cd c:\code 

rem Step 1. Prepare SVN repo with CRLF type newlines. 
rem The pre-1.4 flag is to prevent an error during git clone. 

svnadmin create --pre-1.4-compatible svnrepo 
svn checkout file:///C:/code/svnrepo svnworking 
cd svnworking 
echo "First line" > file.txt 
echo "Second line" >> file.txt 
echo "Third line" >> file.txt 
rem NOTE: At this point file.txt has CRLF newlines 
svn add file.txt 
svn commit -m "Add file.txt" 
rem NOTE: At this point file.txt still has CRLF newlines 
cd .. 

rem Step 2. Clone the svn repo into git and inspect work copy newline type 
git svn clone file:///C:/code/svnrepo gitrepo 
rem The following outputs true on my machine 
git config --get core.autocrlf 
cd gitrepo 
rem The following also outputs true on my machine 
git config --get core.autocrlf 
git svn fetch 
rem NOTE: At this point file.txt (git working dir copy) has CRLF newlines 

rem Step 3. Disable autocrlf to inspect repo's inner newline type 
rem Use the following and my editor to set core.autocrlf to false: 
git config --edit --local 
rem This now prints false: 
git config --get core.autocrlf 
git checkout . 
rem NOTE: At this point file.txt (git working dir copy) still has CRLF newlines 
del file.txt 
git checkout . 
rem NOTE: Even after explicitly deleting the old one and checking out again, 
rem file.txt still has CRLF newlines 

यदि गिट न्यूलाइन रूपांतरण मेरे गिट एसवीएन पुल के दौरान हुआ था, तो इसके विपरीत, मैं उम्मीद करता हूं कि फाइल.txt में इन सभी के अंत में एलएफ-केवल न्यूलाइन होगी।

rem We'll a git repo with core.autocrlf on, then switch it off to 
rem pull out a file 

rem The following outputs true 
git config --get core.autocrlf 
git init gitcrtest 
cd gitcrtest 
rem The following still outputs true 
git config --get core.autocrlf 
echo "First line" > file.txt 
echo "Second line" >> file.txt 
echo "Third line" >> file.txt 
git add file.txt 
git commit -m "Add file.txt" 
rem NOTE: At this point file.txt (git working dir copy) has CRLF newlines 
rem Use the following to set core.autocrlf to false 
git config --edit --local 
git checkout . 
rem NOTE: Now file.txt (git working dir copy) has LF-only newlines 

सारांश में::

यहाँ एक मानसिक स्वास्थ्य की जांच है कि ऊपर चरण 3 वास्तव में रेपो वामो-केवल नई-पंक्तियों है या नहीं का एक मान्य परीक्षण लागू करता है ऊपर के आधार पर, ऐसा लगता है जब Git-SVN खींचती है कि एसवीएन से, एसवीएन किसी भी crlf अनुवाद के बिना गिट प्रतिबद्ध ग्राफ में जोड़ा जाता है, भले ही autocrlf सक्षम हो। यही है, आपकी एसवीएन रेपो में आपकी फाइलों की किस तरह की नई लाइन है, वे आपके गिट क्लोन में भी जा रहे हैं। (लेकिन आपकी गिट कार्यशील प्रति में अलग-अलग न्यूलाइन प्रकार हो सकते हैं।)

ध्यान दें कि यह "गिट हेल्प एट्रिब्यूट्स" में अंत-सामान्य सामान्यीकरण की चर्चा के साथ काफी संगत है; वहां सामान्यीकरण कुछ ऐसा होता है जो या तो कमांड के साथ होता है जो रेपो से सामान को आपकी कार्यशील निर्देशिका (जैसे चेकआउट या विलय) में खींचता है या कमांड के साथ जो आपकी कार्यशील निर्देशिका से चीजों को इंडेक्स/रेपो (जैसे जोड़ या प्रतिबद्ध) में ले जाता है। "गिट svn fetch" उन चीजों में से कोई भी प्रतीत नहीं होता है, इसलिए यह समझ में आता है कि उस समय कोई अंतराल सामान्यीकरण नहीं होगा। मैं डॉकिट के बारे में अस्पष्ट हूं, इसलिए मुझे यकीन नहीं है कि उस समय अंतराल के सामान्यीकरण की उम्मीद करनी है या नहीं।

ध्यान दें कि अगर एसवीएन की एसवीएन: ईओएल-स्टाइल प्रॉपर्टी आपके रेपो/मशीन पर सेट की गई है तो एक अतिरिक्त शिकन है।I सोचें एसवीएन डिफ़ॉल्ट इसके अंत में अंतराल के रूपांतरण नहीं करते हैं, लेकिन मुझे 100% निश्चित नहीं है।

अद्यतन: वास्तविक दुनिया के लिए svn-> न्यूलाइन पर गिट माइग्रेशन परिप्रेक्ष्य के लिए, Tim Abell's description भी देखें। गिट-एसवीएन द्वारा सीआरएलएफ न्यूलाइन को एलएफ-केवल न्यूलाइन में परिवर्तित नहीं किया गया था, यदि गिट के स्वचालित अंत-ऑफ-लाइन सामान्यीकरण को छोड़ दिया गया तो गैर-आदर्श परिणामों के साथ। समाधान गिट में लाइन एंडिंग को सामान्य करने या अंत-ऑफ-लाइन-सामान्यीकरण को अक्षम करने के लिए थे।