Git इस पाठ फ़ाइल को बाइनरी फ़ाइल के रूप में क्यों मानता है?

Question

मुझे आश्चर्य है कि मुझे यह क्यों बताता है:?

$ git diff MyFile.txt
diff --git a/MyFile.txt b/MyFile.txt
index d41a4f3..15dcfa2 100644
Binary files a/MyFile.txt and b/MyFile.txt differ

क्या वे पाठ फ़ाइलें नहीं हैं?

मैंने .gitattributes की जाँच की है और यह खाली है। मुझे यह संदेश क्यों मिल रहा है? मुझे अब और भिन्न नहीं मिल सकते क्योंकि मैं अब तक का उपयोग करता हूं

जोड़े गए:

मैंने देखा है @कि फ़ाइल अनुमतियों में एक है, यह क्या है? क्या इसका कारण हो सकता है?

$ls -all
drwxr-xr-x   5 nacho4d  staff    170 28 Jul 17:07 .
drwxr-xr-x  16 nacho4d  staff    544 28 Jul 16:39 ..
-rw-r--r--@  1 nacho4d  staff   6148 28 Jul 16:15 .DS_Store
-rw-r--r--@  1 nacho4d  staff    746 28 Jul 17:07 MyFile.txt
-rw-r--r--   1 nacho4d  staff  22538  5 Apr 16:18 OtherFile.txt

Comments

यह एक UTF-8 एन्कोडेड फ़ाइल हो सकती है।

— मार्निक्स वैन वैलेन

यह UTF16 के छोटे एंडियन LF

— nacho4d

lsमैक ओएस एक्स पर मैनपेज से : यदि फ़ाइल या निर्देशिका में विशेषताओं को बढ़ाया गया है, तो -lविकल्प द्वारा मुद्रित अनुमतियाँ फ़ील्ड में एक @चरित्र है । -@इन विस्तारित विशेषताओं को देखने के लिए विकल्प का उपयोग करें ।

— adl

मुझे लगता है कि यह बग का एक बग हो सकता है। मैंने विस्तारित विशेषताओं को हटा दिया और अब फिर से सब कुछ ठीक है।

— nacho4d

@ nacho4d: यह अजीब है, क्योंकि गिट को भी नहीं पता होना चाहिए कि कोई भी विस्तारित विशेषता है। यदि आप इसे पुन: पेश कर सकते हैं, तो यह गिट मेलिंग सूची में लाने लायक होगा। जैसा कि vger.kernel.orgसूचियों पर अच्छा रिवाज है , आपको पोस्ट करने के लिए सदस्यता लेने की ज़रूरत नहीं है (लोग आपको जवाब देने के लिए CC'ed रखेंगे) और [e-mail]सूची के उच्च मात्रा को नहीं दिए जाने की तरह हैं ।

— जन हडेक

Answer 1

इसका सीधा सा मतलब है कि जब git फ़ाइल की वास्तविक सामग्री का निरीक्षण करता है (यह नहीं जानता कि कोई भी एक्सटेंशन बाइनरी फ़ाइल नहीं है - आप विशेषताओं फ़ाइल का उपयोग कर सकते हैं यदि आप इसे स्पष्ट रूप से बताना चाहते हैं - तो मैन पेज देखें)।

फाइल की सामग्री का निरीक्षण करने के बाद इसमें वह सामान दिखाई देता है जो बुनियादी अस्की पात्रों में नहीं है। UTF16 होने के नाते मुझे उम्मीद है कि इसमें 'मज़ेदार' अक्षर होंगे, इसलिए यह सोचता है कि यह द्विआधारी है।

यदि आपके पास फ़ाइल के लिए अंतर्राष्ट्रीयकरण (i18n) या विस्तारित चरित्र प्रारूप हैं, तो गिट को बताने के तरीके हैं। मैं सेट करने के लिए सटीक विधि पर पर्याप्त रूप से नहीं हूं - आपको RT [Full] M ;-) तक की आवश्यकता हो सकती है;

संपादित करें: एसओ की त्वरित खोज कैन -आई-मेक-गिट-पहचान-ए-यूएफएफ-16-फाइल- ए -टेक्स्ट के रूप में मिली है, जो आपको कुछ सुराग देना चाहिए।

Comments

आप लगभग हैं लेकिन पूरी तरह से गलत नहीं है। Git ने वास्तविक फाइलों का निरीक्षण किया और वहां 'मजाकिया' अक्षर देखे। हालांकि यह यूटीएफ -16 बाइनरी नहीं है। यह है द्विआधारी क्योंकि पाठ के रूप में ASCII आधारित (कि केवल एक चीज है निर्मित diff के लिए प्रयोग करने योग्य परिणाम देगा) नहीं और UTF-16 है परिभाषित किया गया है,। हां, पैटर्न परिभाषित फ़ाइलों (उपयोग .gitattributes) के लिए विशेष अंतर का उपयोग करने के लिए गिट को बताने का एक तरीका है ।

— जन हडेक

मुझे जोड़ना चाहिए, कि 'मजाकिया चरित्र' का अर्थ है शून्य बाइट्स।

— जान हुदेक

हम दोनों सही हैं, लेकिन विभिन्न दृष्टिकोणों से। हम दोनों कहते हैं "गिट अपने प्रकार का निर्धारण करने के लिए सामग्री का निरीक्षण करते हैं।" हम दोनों कहते हैं कि पता Git यह बताने के लिए UTF16 के रूप में व्यवहार किया जाना चाहिए उपयोगकर्ता की जरूरत बनाने के लिए Git के माध्यम से .gitattributesआदि

— फिलिप ओकले

@ जानहुडेक: आपके विचार में, सभी फाइलें बाइनरी हैं।

— स्टोल्कविक

@stolosvik, (और JanH) यह उस UTF-8 में एक अधिक सूक्ष्म मध्य मैदान है, जिसमें आधार 0-127 ASCII वर्ण और अन्य सभी यूनिकोड वर्ण शामिल हैं, बिना null char के अलावा किसी भी अन्य (n) (00h) बाइट की आवश्यकता के बिना बाइट। ('सी' स्ट्रिंग टर्मिनेटर)। इस प्रकार Git की पाठ परिभाषा है कि सामग्री (पहले 1k बाइट्स) को utf-8 एन्कोडेड होने पर एक अशक्त बाइट नहीं होना चाहिए। एक मजेदार पढ़ने के लिए stackoverflow.com/questions/2241348/… का प्रयास करें । मेरी मूल टिप्पणी उस मामले को संदर्भित करती है जब यूटीएफ -16 एनकोडेड डेटा को बाइट जोड़े के रूप में देखा जाता है, इसलिए एससीआई कोड अंक के लिए उच्च बाइट 00 होगी।

— फिलिप ओकले

Answer 2

यदि आपने किसी फ़ाइल का प्रकार सेट नहीं किया है, तो Git इसे स्वचालित रूप से निर्धारित करने की कोशिश करता है और वास्तव में लंबी लाइनों और शायद कुछ विस्तृत वर्णों (जैसे यूनिकोड) के साथ एक फ़ाइल को द्विआधारी माना जाता है। साथ .gitattributes फ़ाइल परिभाषित कर सकते हैं कि कैसे Git फ़ाइल interpretes। मैन्युअल रूप से अंतर विशेषता सेट करने से फ़ाइल सामग्री को पाठ के रूप में व्याख्या करने की सुविधा मिलती है और यह सामान्य अंतर भी करेगा।

बस एक जोड़ने .gitattributes अपने भंडार रूट फ़ोल्डर पर सेट करना और diff पथ या फ़ाइलों के लिए गुण। यहाँ एक उदाहरण है:

src/Acme/DemoBundle/Resources/public/js/i18n/* diff
doc/Help/NothingToSay.yml                      diff
*.css                                          diff

यदि आप जांचना चाहते हैं कि क्या कोई फ़ाइल पर सेट की गई विशेषताएँ हैं, तो आप git चेक-अटर की मदद से ऐसा कर सकते हैं

git check-attr --all -- src/my_file.txt

गिट विशेषताओं के बारे में एक और अच्छा संदर्भ यहां पाया जा सकता है ।

Comments

यह मददगार था, लेकिन वास्तव में गलत है - सही विशेषता है diff, नहीं text। textविशेषता पाठ लेकिन इसके बजाय नियंत्रण कैसे लाइन अंत (वामो के लिए सामान्य) नियंत्रित किया जाता है का उपयोग कर diff के लिए Git नहीं बताता है। अधिक जानकारी के लिए अपने .gitattributes के लिंक को देखें।

— एरिक

साभार @ErikE मैंने आपकी टिप्पणी और Git प्रलेखन के अनुसार अपनी पोस्ट को अपडेट किया है।

— naitsirch

इसके अतिरिक्त, आप सेट कर सकते हैं कि किस प्रकार का अंतर किया जाना चाहिए। उदाहरण के लिए, यदि यह एक xml फ़ाइल है, जिसका उपयोग आप diff=xmlकेवल के बजाय कर सकते हैं diff।

— सैंडी चैपमैन

चेक-एटर के विपरीत क्या है - क्या कोई सेट-एटर है? मैंने मूल रूप से गलती से एक फ़ाइल को UTF-16 के रूप में सहेजा, फिर कमिट किया और धक्का दिया, और अब BitBucket इसे UTF-16 के रूप में देखता है, फिर भी इसे UTF-8 के रूप में सहेजने के बाद, फिर से शुरू करना और इसे धक्का देना। यह मूल रूप से मेरे पुल अनुरोधों को पढ़ने के लिए असंभव बनाता है क्योंकि समीक्षकों को समीक्षा टिप्पणियों को जोड़ने के लिए प्रत्येक व्यक्तिगत टिप्पणी पर क्लिक करने की आवश्यकता है।

— जॉन ज़ब्रोस्की

Answer 3

मैं इस मुद्दे पर जहां जीयूआई GUI और SourceTree जावा / जेएस फ़ाइलों को द्विआधारी के रूप में मान रहा था और इस प्रकार अंतर नहीं देख सकता था

निम्नलिखित सामग्री के साथ .git \ info फ़ोल्डर में "विशेषताएँ" नाम की फ़ाइल बनाने से समस्या हल हो गई

*.java diff
*.js diff
*.pl diff
*.txt diff
*.ts diff
*.html diff

यदि आप सभी रिपॉजिटरी के लिए यह परिवर्तन करना चाहते हैं तो आप निम्नलिखित स्थान $ HOME / .config / gb / विशेषताओं में विशेषता फ़ाइल जोड़ सकते हैं।

Comments

<project-root>/.gitattributesफ़ाइल को भी नोट करें , जो सभी योगदानकर्ताओं के लिए और केवल प्रासंगिक प्रोजेक्ट के लिए परिवर्तन को सक्रिय बनाता है।

— jpaugh

जोड़ना * diffमेरे लिए सहायक था: यह सभी प्रकार की फ़ाइलों में अंतर दिखाता है। लेकिन आपका समाधान बेहतर है, क्योंकि बड़ी बाइनरी फ़ाइलों में अनावश्यक अंतर दिखाने से बचें।

— बूलियन

हाँ! इससे मदद मिलती है!

— वाइल्डकैट

Answer 4

Git यहां तक ​​कि यह निर्धारित करेगा कि यह द्विआधारी है यदि आपकी पाठ फ़ाइल में एक सुपर-लंबी रेखा है। मैंने एक लंबी स्ट्रिंग को तोड़ दिया, इसे कई स्रोत कोड लाइनों में बदल दिया, और अचानक फ़ाइल 'बाइनरी' से एक पाठ फ़ाइल में चली गई जिसे मैं देख सकता था (स्मार्टगिट में)।

इसलिए अपने संपादक में 'एन्टर' को दबाए बिना बहुत दूर तक टाइपिंग न करें - अन्यथा बाद में Git को लगेगा कि आपने एक बाइनरी फ़ाइल बनाई है।

Comments

यह एक सही जानकारी है। मैं एक बहुत बड़ी MySQL डंप (.sql फ़ाइल) को नियंत्रित करने की कोशिश कर रहा था, लेकिन गिट इसे एक द्विआधारी फ़ाइल के रूप में मानते हैं, भले ही उस पर केवल ASCII / UTF8 डेटा हो। कारण, यह है कि लाइनें सुपर-लॉन्ग होती हैं (इंसर्ट वैल्यूज़ (एक), (दो), (तीन), (...), (3 मिलियन ...); - अजीब, हर कमिट के लिए, गिट रिपॉजिटरी करता है। 1.7gb से वृद्धि नहीं, लेकिन केवल ~ 350mb। शायद, git इसे सहेजने से पहले "बाइनरी" फ़ाइल को संपीड़ित कर रहा है।

— एलेक्जेंडर टी।

@AlexandreT। Git वास्तव में फ़ाइल ब्लॉब्स को संकुचित करता है (GZip, IIRC का उपयोग करके)।

— jpaugh

Answer 5

एक नई संपादक में अपनी एक फाइल को संपादित करने के बाद मुझे यही समस्या थी। नया संपादक मेरे पुराने संपादक (UTF-8) की तुलना में एक अलग एन्कोडिंग (यूनिकोड) का उपयोग करता है। इसलिए मैंने बस यूटीएफ -8 के साथ अपनी फाइलों को बचाने के लिए अपने नए संपादक को बताया और फिर गिट ने मेरे परिवर्तनों को फिर से ठीक से दिखाया और इसे बाइनरी फाइल के रूप में नहीं देखा।

मुझे लगता है कि समस्या बस यह थी कि git विभिन्न एन्कोडिंग प्रकारों की फ़ाइलों की तुलना करना नहीं जानता है। तो एन्कोडिंग प्रकार जो आप वास्तव में उपयोग करते हैं, तब तक कोई फर्क नहीं पड़ता, जब तक यह सुसंगत रहता है।

मैंने इसका परीक्षण नहीं किया, लेकिन मुझे यकीन है कि अगर मैं अपनी फ़ाइल को नए यूनिकोड एन्कोडिंग के साथ ले जाता, तो अगली बार जब मैंने उस फ़ाइल में परिवर्तन किया, तो उसने परिवर्तनों को ठीक से दिखाया होगा और बाइनरी के रूप में इसका पता नहीं लगाया होगा, क्योंकि तब यह दो यूनिकोड एन्कोडेड फाइलों की तुलना कर रहा होगा, न कि यूटीएफ -8 फाइल की एक यूनिकोड फाइल से।

आप आसानी से टेक्स्ट फ़ाइल के एन्कोडिंग प्रकार को देखने और बदलने के लिए नोटपैड ++ जैसे ऐप का उपयोग कर सकते हैं ; नोटपैड ++ में फ़ाइल खोलें और टूलबार में एन्कोडिंग मेनू का उपयोग करें।

Comments

यूनिकोड एनकोडिंग नहीं है। यह एक चारसेट और UTF-8, इसकी एन्कोडिंग में से एक है यानी जिस तरह से एक यूनिकोड कोडपॉइंट एन्कोड करने के लिए

— phuclv

यह मुद्दे को हल नहीं करता है, केवल इसे टालता है। मुद्दा यह है कि गिट या इसका अलग-अलग उपकरण टेक्स्ट फ़ाइलों को ठीक से नहीं पहचानता है या आसानी से उपयोगकर्ता को उसके व्यवहार को ओवरराइड करने की अनुमति नहीं देता है।

— प्रेजा za

Answer 6

मुझे भी यही समस्या हुई है। जब मैंने Google पर समाधान खोजा तो मुझे धागा मिला, फिर भी मुझे कोई सुराग नहीं मिला। लेकिन मुझे लगता है कि मैंने अध्ययन करने के बाद इसका कारण पाया, नीचे दिए गए उदाहरण से मेरा सुराग स्पष्ट हो जाएगा।

    echo "new text" > new.txt
    git add new.txt
    git commit -m "dummy"

अभी के लिए, new.txt फ़ाइल को टेक्स्ट फ़ाइल माना जाता है।

    echo -e "newer text\000" > new.txt
    git diff

आपको यह परिणाम मिलेगा

diff --git a/new.txt b/new.txt
index fa49b07..410428c 100644
Binary files a/new.txt and b/new.txt differ

और यह कोशिश करो

git diff -a

आप नीचे मिलेगा

    diff --git a/new.txt b/new.txt
    index fa49b07..9664e3f 100644
    --- a/new.txt
    +++ b/new.txt
    @@ -1 +1 @@
    -new file
    +newer text^@

Answer 7

जब भी हमने इसमें बदलाव करने की कोशिश की, तो हमारे पास .html फ़ाइल बाइनरी के रूप में देखी गई थी। नहीं देखने के लिए बहुत uncool अलग है। ईमानदार होने के लिए, मैंने यहां सभी समाधानों की जांच नहीं की, लेकिन हमारे लिए जो काम किया वह निम्नलिखित था:

1. फ़ाइल को निकाला (वास्तव में इसे मेरे डेस्कटॉप पर स्थानांतरित कर दिया) और कमिट किया git deletion। गिट कहते हैंDeleted file with mode 100644 (Regular) Binary file differs
2. फ़ाइल को फिर से जोड़ा (वास्तव में इसे मेरे डेस्कटॉप से ​​परियोजना में वापस ले जाया गया)। Git का कहना है New file with mode 100644 (Regular) 1 chunk, 135 insertions, 0 deletionsकि फ़ाइल अब एक नियमित पाठ फ़ाइल के रूप में जोड़ी गई है

अब से, मैंने फ़ाइल में किए गए किसी भी बदलाव को एक नियमित पाठ अंतर के रूप में देखा है। आप इन कमिट्स (1, 2, और 3 को आपके द्वारा किए गए वास्तविक बदलाव के रूप में भी) स्क्वैश कर सकते हैं, लेकिन मैं भविष्य में यह देखना पसंद कर सकता हूं कि मैंने क्या किया। 1 और 2 स्क्वैश करना एक द्विआधारी परिवर्तन दिखाएगा।

Comments

एक या दो (सफलतापूर्वक संकलित) सीपीपी फ़ाइलों के साथ इसी तरह वी.एस. जोरदार तुलना के लिए Github gui को प्रस्तुत करता है । एक ऐसे डिंग डोंग इंटरचेंज में घंटी पर एक मक्खी होने की इच्छा नहीं होगी, - वी.एस. एक तरफ कह रहा है कि यह जीथब है, और दूसरी तरफ गितूब कह रही है कि यह वी.एस. :(

— लॉरी स्टर्न

Answer 8

प्रति यह मददगार जवाब है, तो आप Git सीधे कारण है कि यह एक खास तरह से एक फ़ाइल व्यवहार करता है पूछ सकते हैं:

cd directory/of/interest
file *

यह इस तरह उपयोगी उत्पादन का उत्पादन करता है:

$ file *
CR6Series_stats resaved.dat: ASCII text, with very long lines, with CRLF line terminators
CR6Series_stats utf8.dat:    UTF-8 Unicode (with BOM) text, with very long lines, with CRLF line terminators
CR6Series_stats.dat:         ASCII text, with very long lines, with CRLF line terminators
readme.md:                   ASCII text, with CRLF line terminators

Comments

fileएक git कमांड नहीं है। यह विंडोज पर गिट के साथ एक पूरी तरह से अलग उपकरण है। क्या यह दिखाने के लिए दस्तावेज है कि यह बाइनरी फाइल डिटेक्शन के लिए क्या उपयोग करता है?

— अधिकतम

Answer 9

यह भी (कम से कम विंडोज पर) टेक्स्ट फ़ाइलों के कारण होता है जिसमें बीओएम एन्कोडिंग के साथ यूटीएफ -8 होता है । नियमित रूप से UTF-8 को एन्कोडिंग को बदलने से गिट ने फ़ाइल को टाइप = टेक्स्ट के रूप में देखा

Answer 10

मेरे पास एक उदाहरण था जहां .gitignoreएक डबल था\r उद्देश्य से (कैरिज रिटर्न) अनुक्रम था।

उस फ़ाइल को git द्वारा बाइनरी के रूप में पहचाना गया था। एक .gitattributesफ़ाइल जोड़ने में मदद मिली।

# .gitattributes file
.gitignore diff

Comments

काम किया। मेरे पास कुछ OS "Icon \ r \ r" फ़ाइल को अनदेखा करने के लिए एक डबल \ r था। कारण के रूप में अच्छी तरह से पता करने के लिए अच्छा है।

— hsandt

Answer 11

यदि git check-attr --all -- src/my_file.txtयह इंगित करता है कि आपकी फ़ाइल को बाइनरी के रूप में चिह्नित किया गया है, और आपने इसे बाइनरी के रूप में सेट नहीं किया है .gitattributes, तो इसके लिए जांच करें /.git/info/attributes।

Answer 12

Aux.js को दूसरे नाम में बदलें, जैसे Sig.js.

स्रोत पेड़ अभी भी इसे एक बाइनरी फ़ाइल के रूप में दिखाता है, लेकिन आप इसे जोड़ सकते हैं और इसे प्रतिबद्ध कर सकते हैं।

Answer 13

मेरे पास एक समान मुद्दा था क्योंकि मैंने एक बाइनरी काफ्का संदेश से कुछ पाठ चिपकाया था, जिसमें गैर-दृश्य चरित्र डाला गया था और यह सोचने का कारण था कि फ़ाइल द्विआधारी है।

मैं regex का उपयोग कर फ़ाइल खोज कर आपत्तिजनक अक्षर पाया [^ -~\n\r\t]+।

• [ इस सेट में पात्रों का मिलान करें
• ^ इस सेट में वर्णों का मिलान न करें
• -~ '' (स्पेस) से '~' तक के सभी पात्रों से मेल खाता है
• \n नई पंक्ति
• \r कैरिज रिटर्न
• \t टैब
• ] बंद सेट
• + इनमें से एक या अधिक वर्णों का मिलान करें

Answer 14

मैंने अभी इस सूची में सब कुछ करने के लिए कई घंटे बिताए हैं, यह जानने की कोशिश कर रहा है कि मेरे समाधान में परीक्षण परियोजनाओं में से कोई भी खोजकर्ता के लिए कोई परीक्षण क्यों नहीं जोड़ रहा है।

यह मेरे मामले में निकला कि किसी भी तरह (शायद कहीं न कहीं एक खराब मर्ज के कारण) कि वीएस ने परियोजना को पूरी तरह से एक संदर्भ खो दिया था। यह अभी भी निर्माण कर रहा था लेकिन मैंने देखा कि इसने केवल आश्रितों का निर्माण किया।

मैंने तब देखा कि यह निर्भरता सूची में ही दिखाई नहीं दे रहा था , इसलिए मैंने परीक्षण परियोजना को हटा दिया और अपने सभी परीक्षणों को फिर से जोड़ दिया ।

Comments

विजुअल स्टूडियो वास्तव में यहां प्रासंगिक नहीं है।

— jpaugh