• 1

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

हाँ मैं सहमत हूँ। मैंने इसे विस्तार एपीआई में उजागर करने के लिए एक अलग मुद्दा बनाया (#1394 देखें)।

+1

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

आम तौर पर, आपके पास १० या १०० की संशोधित फ़ाइलें अप्रतिबद्ध नहीं होती हैं, इसलिए यह क्रिसमस ट्री की तरह दिखने की संभावना नहीं है :)

तो ऐसा लगता है कि इसके लिए पीआर बंद कर दिया गया था। @basero @joaomoreno - इस काम की स्थिति पर कोई अपडेट?

इसे जांचें https://github.com/Microsoft/vscode/pull/8462

कोई अपडेट नहीं...

इस मुद्दे में आपकी रुचि के लिए बहुत-बहुत धन्यवाद! यह वर्तमान में बैकलॉग को सौंपा गया है। वर्तमान पुनरावृत्ति की योजना बनाने के लिए हर महीने हम बैकलॉग से आइटम चुनते हैं। अधिक जानकारी के लिए कृपया https://github.com/Microsoft/vscode/wiki/Issue-Tracking#planning देखें।

चूंकि हम डेवलपर्स की एक छोटी टीम हैं, इसलिए केवल इतने सारे फीचर अनुरोध और मुद्दे हैं जिन पर हम एक मील के पत्थर के लिए काम कर सकते हैं। फिर भी हम हमेशा पुल अनुरोधों का स्वागत करते हैं और अगर वे हमारे गुणवत्ता मानकों को पूरा करते हैं तो उन्हें स्वीकार करने में खुशी होती है।

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

कृपया +1 लिखना बंद करें। यह इस मुद्दे में सभी को ईमेल करता है। पहली टिप्पणी पर इमोजी प्रतिक्रियाओं का प्रयोग करें।

+1

नमस्ते, क्या आपके पास इस सुविधा-अनुरोध के बारे में कोई खबर है? मैंने आज बनाम कोड का उपयोग करना शुरू कर दिया है और मैं पहले से ही प्यार कर रहा हूं लेकिन मुझे वास्तव में परिवर्तनों का संकेत देने वाले रंगों की याद आती है
आपके काम के लिए बधाई

+1

इसे लागू करते समय कृपया 206 पर विचार करें

मैं मदद के लिए कुछ स्क्रीनशॉट जोड़ता हूं:

परमाणु डिफ़ॉल्ट:

वीएससीओडी डिफ़ॉल्ट:

+1

+1

यह बहुत उपयोगी होगा।

फ़ाइल ट्री में फ़ाइलों और चिह्नों को सूचीबद्ध करने के तरीके को संशोधित करने की क्षमता पहले से ही है।
यह एक्सटेंशन करता है
https://github.com/robertohuertasm/vscode-icons।

हालाँकि यह फ़ाइल नामों को रंग नहीं देता है

+1

+1

क्या कोई बदलाव है? यह विशेषता मुझे एटम से आगे बढ़ने से रोकती है। :(

मैं अभी एटम से दूर चला गया क्योंकि वीएससी में प्रदर्शन काफी बेहतर लगता है। हालाँकि, यह एक लक्ज़री विशेषता है जो मुझे VSC में याद आती है।

+1

मुझे लगता है कि इसे एक एक्सटेंशन के बजाय एक अंतर्निहित सेटिंग (जैसे git.colorExplorer ) के रूप में रखना अच्छा होगा।

@arkon क्या ऐसा कोई एक्सटेंशन है? मुझे कोई नहीं मिला।

सबसे अधिक संभावना है कि फ़ाइल एक्सप्लोरर के पास इसे संशोधित करने के लिए एपीआई नहीं है
परिवर्तन गिट करने के लिए। एक एक्सटेंशन मेरे लिए ठीक रहेगा।

शुक्र, 3 फरवरी, 2017, 07:52 को राहुल नोटिफिकेशन @github.com ने लिखा:

@arkon https://github.com/arkon क्या ऐसा कोई एक्सटेंशन है? मैं नहीं कर सका
कोई भी खोजें।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/Microsoft/vscode/issues/178#issuecomment-277177373 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AEQJ1eoLm7Sp59a2hE0tIFQnb0Q5cJnSks5rYs6tgaJpZM4GlYyH
.

@ rahulnever2far नहीं, यह सिर्फ एक सुझाव था क्योंकि पहले यह सुझाव दिया गया था कि इसे एक एक्सटेंशन एपीआई के रूप में उजागर किया जा सकता है (जो ठीक है, मुझे लगता है)।

हाल ही में VSCode पर आगे बढ़ने का फैसला किया और मुझे वास्तव में यह सुविधा याद आती है

कृपया जोड़ें। एटम से कूदने की कोशिश करते समय उत्पादकता में घर्षण जोड़ता है।

@KozhokarAlex @bhudgens और अन्य: डेवलपर्स को दिखाने के लिए आप इस सुविधा का अनुरोध कर रहे हैं, पहली पोस्ट में थम्स अप आइकन पर क्लिक करें। वे यह निर्धारित करने के लिए कि कौन से फीचर अनुरोध सबसे लोकप्रिय हैं, वे

जैसा कि आप इस तरह के मुद्दों को छांटने से देख सकते हैं, यह समस्या अभी तीसरी सबसे अधिक अनुरोधित विशेषता है।

थम्स अप। हाल ही में एटम से आया था..उम्मीद है कि इसे जल्द ही वीएससीओडी में देखा जाएगा!

आह धन्यवाद @joaomoreno!

कृपया केवल FileExplorer ही नहीं, QuickOpen में भी वही रंग/क्यूट स्थिति जोड़ें।
इस तरह से ओपनिंग फाइल्स को पहले से बदली हुई फाइलों के आधार पर विजुअली फिल्टर किया जा सकता है।

इसके साथ क्या हो रहा है? अनुरक्षक @joaomoreno PR का विलय क्यों नहीं करेंगे? क्या कोई प्लगइन है जिसका हम अभी उपयोग कर सकते हैं? यह सिर्फ मूर्खतापूर्ण योजना है

@SOSANA सुनिश्चित नहीं है कि पीआर से आपका क्या मतलब है, आप किस पीआर का जिक्र कर रहे हैं?

२८२४ इसे ठीक करने के लिए द्वार खोलता है, इसलिए बस थोड़ा और धैर्य रखें।

@SOSANA यह एक मुद्दा है, पीआर नहीं

+1 यह सुविधा उत्पादकता के लिए अद्भुत होगी

+1

@ publiclass1 @ hevans90 , ... (+1 के साथ टिप्पणी करने वाले अन्य सभी लोगों को सम्मिलित करें) ..., कृपया इस बारे में टिप्पणी पोस्ट न करें कि आप इस सुविधा को कितना चाहते हैं। यह वही है जिसके लिए GitHub ने इमोजी प्रतिक्रियाओं को जोड़ा। बस मूल टिप्पणी को थम्स अप करें। इस तरह मैं ईमेल सूचनाओं का उपयोग करने के लिए वापस आ सकता हूं कि उनका इरादा क्या था (इस मुद्दे की प्रगति के बारे में अद्यतन रखें, और दुनिया में कोई भी ऐसा नहीं चाहता)। आपको स्पैम करने के लिए भी सभी को क्षमा करें। मुझे पूरी उम्मीद है कि अधिक लोग +1 -इन मुद्दों को रोकना सीखेंगे।

+1

मैं PhpStorm का उपयोग करता हूं, बल्कि हर चीज के लिए VS कोड का उपयोग करूंगा। मैं वर्तमान में जितनी हो सके उतनी वीएस कोड विंडो का उपयोग करता हूं। क्या आप अंततः इस रंग प्रणाली को एक विकल्प के रूप में प्राप्त कर सकते हैं जैसा कि मैं PhpStorm रंगों को पसंद/जानता हूं। सन्दर्भ के लिए:

काला - अप टू डेट - फ़ाइल अपरिवर्तित है।
ग्रे - हटा दिया गया - फ़ाइल को रिपॉजिटरी से हटाने के लिए निर्धारित किया गया है।
नीला - संशोधित - फ़ाइल पिछले सिंक्रनाइज़ेशन के बाद से बदल गई है।
हरा - जोड़ा गया - फ़ाइल को भंडार में जोड़ने के लिए निर्धारित किया गया है।
भूरा - अज्ञात - फ़ाइल स्थानीय रूप से मौजूद है, लेकिन भंडार में नहीं है, और जोड़ने के लिए निर्धारित नहीं है।

आदि https://www.jetbrains.com/help/phpstorm/2016.3/file-status-highlights.html के माध्यम से। तुम लोग रॉक, धन्यवाद।

तथा

• विरोध के साथ मर्ज की गई फ़ाइलें लाल रंग में प्रदर्शित होती हैं,

परस्पर विरोधी को दूसरों से अलग करना बहुत सुविधाजनक है

+1 गिट <> एक्सप्लोरर विचारों के बीच आगे और पीछे टॉगल करना सुपर अनुत्पादक है।

आदर्श रूप से परिवर्तन को शीर्ष पर एक समूह के रूप में भी देखना संभव होगा जहां हमारे पास खुली फाइलें हैं, साथ ही रंग द्वारा देखे गए परिवर्तनों का नेस्टेड पेड़ (जैसा कि ऊपर @abdonrd द्वारा दिखाया गया है।)

आओ एक लोग, बस +1 के साथ रुकें।

कृपया पहली पोस्ट पर एक अंगूठा लगाएं।

मेरे पास एक सामान्य एपीआई बनाने के लिए एक दिलचस्प उपयोग केस और तर्क है जो प्लगइन को अलग-अलग फाइलों और फ़ोल्डरों को रंगने की अनुमति देगा:

ट्रेलो एजिंग पॉवरअप के समान फ़ाइल/फ़ोल्डर की उम्र - मैं उन फ़ाइलों और फ़ोल्डरों को फीका करना चाहता हूं जिन्हें लंबे समय तक छुआ नहीं गया है (गिट इतिहास द्वारा आंका गया), ताकि 'वर्किंग सेट' अधिक विशिष्ट हो और खोजने में आसान।

क्यों: मेरे पास छोटी परियोजनाओं का एक बड़ा रेपो है (विश्लेषणात्मक रिपोर्ट के लिए स्क्रिप्ट का एक समूह सोचें) जहां 90+% काम फिर से नहीं छुआ जाएगा (लेकिन मैं पुरानी सामग्री को सबफ़ोल्डर में नहीं ले जा सकता क्योंकि यह बहुत सारे को तोड़ देगा रेपो की ओर इशारा करते हुए लिंक)।

यदि पेड़ की वस्तुओं को रंगने के लिए एक एपीआई एंडपॉइंट था, तो मैं एक प्लगइन लिख सकता था जो गिट लॉग को पढ़ता है और नियमों के कुछ सेट के अनुसार प्रत्येक फ़ाइल/फ़ोल्डर को रंग देता है।

तो इसके बारे में क्या, क्या अभी भी एपीआई नहीं है जो इसके लिए विस्तार बनाने की अनुमति देता है, या इसे एकीकृत सुविधा के रूप में लागू किया जाएगा?

इस पर किसी भी अद्यतन?

+1

+1

+1

क्या आप लोग कृपया हमारे मेल इनबॉक्स को +1 करना और स्पैम करना बंद कर सकते हैं ???

यह किसी उद्देश्य की पूर्ति नहीं करता है।

+1 से कोई स्पैमिंग नहीं xD

प्रोटिप: जिथब से संदेशों को फ़िल्टर करें जहां शरीर बराबर/मिलान/lolwuts "+1"

आप इन लोगों को रोक नहीं सकते।

@jmbelloteau के रूप में @fredrikaverpil ने पहले टिप्पणियों में कहा था, VSCode मुद्दों को मूल टिप्पणी तक अंगूठे की संख्या से हल किया जाता है। इसलिए पहली टिप्पणी पर प्रतिक्रिया जोड़ने के बजाय "+1" टिप्पणी करना वास्तव में स्पैमिंग है, क्योंकि यह प्रतिक्रिया देने का सही तरीका नहीं है और केवल सभी को बेकार ईमेल भेजता है। और प्रतिक्रिया जोड़ने के विपरीत, इसे ध्यान में नहीं रखा जाएगा।

+1

मुझे वेबस्टॉर्म में भी इसकी आदत है: डी। लेकिन जैसा कि मैं देख सकता हूं कि इसे जल्द से जल्द विकसित किया जाएगा। प्रेरणा के लिए वेबस्टॉर्म से एक स्क्रीनशॉट यहां दिया गया है (निम्नलिखित @abdonrd):

आह, ट्रैक न की गई फ़ाइलें भी लाल रंग में दिखाई जाती हैं!

+1

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

आदर्श रूप से, यह बहुत अच्छा होगा यदि रंगों को व्यक्तिगत रूप से संशोधित किया जा सके।

{
    git.newFileColor: 'green',
    git.changedFileColor: 'yellow',
    git.untrackedFileColor: 'blue',
    git.ignoredFileColor: 'gray,
    git.mergeConflictFileColor: 'red'
}

+1

मैं कुछ समय से एक अच्छे ऐप की तलाश कर रहा था जो मुझे पानी पीने की याद दिला सके।
तब, मुझे एहसास हुआ कि मैंने इस धागे की सदस्यता ले ली है।
+1 आने वाले लोगों को रखें, वे अब बेकार नहीं हैं 🚰

@mmazzarolo
पानी पीने के लिए रिमाइंडर की जरूरत क्यों पड़ती है? क्या प्यास लगने पर पीना काफी नहीं है?

वैसे भी, कृपया +1-आईएनजी बंद करें। मुझे यकीन है कि देव पहले से ही इसके बारे में जानते हैं और जैसे ही वे आएंगे अपडेट पोस्ट करेंगे।

@pohmelie यह एक वैध विकल्प है, धन्यवाद!

+1

इन +1 लोगों के साथ wtf गलत है?

बढ़िया विचार, @davidhu2000! git.ignoredFileColor: '#333333' जैसे हेक्स रंगों का भी समर्थन करना अच्छा होगा।

JetBrains द्वारा यहां उपयोग किए जाने वाले प्रकारों और रंगों की एक अच्छी सूची है: https://www.jetbrains.com/help/idea/2017.1/file-status-highlights.html (आप हेक्स प्राप्त करने के लिए रंग के नाम का निरीक्षण कर सकते हैं)।

+1 इस बारे में जागरूकता बढ़ाना कि इस सुविधा की कितनी आवश्यकता है

एकमात्र कारण है कि मैं वीएस कोड का उपयोग नहीं कर रहा हूं। बहुत बुरा :(

किसी को पता है कि कोडबेस में कोई इसे लागू करना शुरू कर सकता है? मैं उस पर वार करना चाहता हूं।

@admosity किसी ने पिछले साल पहले ही एक पुल अनुरोध सबमिट कर दिया था जो अस्वीकृत हो गया: https://github.com/Microsoft/vscode/pull/8462 ।

2824 को कहीं ऊपर एक अवरोधक के रूप में उल्लेख किया गया था, जिसे कुछ समय पहले विलय कर दिया गया है। मैं यह सुनिश्चित करने के लिए वहां परिवर्तनों को देखूंगा कि यह कैसे लागू होता है कि वीएस-टीम इसे कैसे चाहती है।

@AndreasGassmann कमाल! मैं देख लूंगा।

एक अंतिम प्रमुख विशेषता मुझे बनाम कोड पर स्विच करने से रोकती है

जब यह सुविधा शामिल हो जाएगी, तो मैं vscode में बदल जाऊंगा

मैंने इस मुद्दे की सदस्यता ली है क्योंकि मैं जानना चाहता हूं कि कुछ प्रगति कब हुई है।
हर कोई इस बात से वाकिफ है कि यह सुविधा कितनी वांछित है और अभी यह दूसरा सबसे अधिक चर्चित मुद्दा है :)।

यदि आप वास्तव में, वास्तव में यह सुविधा चाहते हैं, तो केवल पहली टिप्पणी को अपवोट करें, और बार-बार टिप्पणी जोड़ने से बचें ।

उन लोगों के लिए जो यह महसूस करते हैं कि वीएस कोड पर स्विच करने के लिए यह सुविधा आवश्यक है। मैं कह सकता हूं कि एटम से स्विच करते समय यह पहली विशेषता थी, लेकिन आईएमओ इस भयानक आईडीई के लिए भुगतान करने के लिए यह एक छोटी सी कीमत है।
इसके अलावा, पिछले हफ्ते मुझे एटम में कुछ काम करना पड़ा और मैं वास्तव में वीएस कोड के गिट व्यू से चूक गया।

@waderyan यह परमाणु से आगे बढ़ने वाला

जी बोलिये!

+1

+1

+1

मैंने एक बहुत ही बदसूरत हैक बनाया है जो workbench.main.js को संशोधित करके और git status आउटपुट के आधार पर CSS को इंजेक्ट करके इस सुविधा को लागू करता है। यदि आपको वीएस कोड आंतरिक फाइलों के माध्यम से खुदाई करने में कोई फर्क नहीं पड़ता है और आपका वीएस कोड प्रत्येक 5 सेकंड में git status निष्पादित करता है, तो एक नज़र डालें।

https://github.com/karabaja4/vscode-explorer-git-status

अद्यतन २८.६.२०१७: एक बग फिक्स किया गया जहां परियोजना को फिर से खोलने पर प्लगइन लोड नहीं होगा।
अद्यतन ३०.६.२०१७: संशोधित फ़ाइलों की मूल निर्देशिकाओं की हाइलाइटिंग को जोड़ा गया (जैसा कि एटम करता है)।
अद्यतन १.७.२०१७: फ़ाइल मिलान अब पूर्ण फ़ाइल या निर्देशिका पथ का उपयोग करके किया जाता है। इस परिवर्तन से पहले निर्देशिका को हाइलाइट किया गया था यदि उसका नाम किसी अन्य परिवर्तित निर्देशिका के समान था।

नमस्ते,
मैं यह पता नहीं लगा सकता कि यह सुविधा अभी तक लागू की गई है या नहीं?
मुझे कोई सेटिंग या एक्सटेंशन नहीं मिला और जैसा कि लगभग दो साल पहले खोला गया था, मैं उलझन में हूं..

@sanjibukai मुद्दा अभी भी खुला है, इसलिए इसे अभी तक लागू नहीं किया गया है। आप उस हैक का उपयोग कर सकते हैं जिसे @ karabaja4 ने आपके ऊपर टिप्पणी में बनाया है।

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

इस फीचर के बिना फोकस्ड नहीं रह सकता। हर बार मुझे याद रखना पड़ता है कि मैं कौन सी फाइल को एडिट करता हूं।

+1

@ karabaja4 आप अपने हैक के साथ पीआर क्यों नहीं बनाते और इसे ठीक से कैसे लागू किया जाए, इस पर प्रतिक्रिया प्राप्त करते हैं?

@ साडा मैं ऐसा करूँगा अगर मुझे लगा कि उस कोड में से कोई भी वीएस कोड में एकीकृत किया जा सकता है। पृष्ठभूमि git status प्रक्रिया चलाना निश्चित रूप से इस सुविधा को लागू करने का एक उचित तरीका नहीं है। इसे लागू करने वाला कोई भी उचित कोड खरोंच से लिखा जाना चाहिए और वीएस कोड स्रोत ढांचे के अंदर सही ढंग से कार्यान्वित किया जाना चाहिए। यह बहुत काम है और दुर्भाग्य से इस समय मेरे पास पर्याप्त समय उपलब्ध नहीं है। माफ़ करना :(

जब उनकी बताई गई मीट्रिक को पहले से ही +1 की मूल पोस्ट की संख्या के रूप में कहा जाता है, तो पिलिंग से चीजों को मदद नहीं मिलेगी, जवाबों में नहीं। साथ ही, यह देखते हुए कि यह डेवलपर्स के लिए एक उपकरण है, मैं इस बात से चकित हूं कि यहां कितनी पात्रता है और ओपन सोर्स प्रक्रिया को नहीं समझ रहा है। सुविधा अनुरोध यहां एक खुले मुद्दे के रूप में है। आप इसे पोस्ट पर +1 कर सकते हैं और या तो इसे स्वयं कर सकते हैं (संभवतः यह सुनिश्चित करने के लिए अनुरक्षकों के साथ काम करना कि यह व्यर्थ नहीं है) और मर्ज का अनुरोध करें या बस इसे उसी पर छोड़ दें। यदि यह आपके लिए एक महत्वपूर्ण विशेषता है, तो एटम का उपयोग करें। जैसा कि मैंने यह लिखा है, 4000 से अधिक खुले मुद्दे हैं। आपको धैर्य से काम लेना होगा।

(या इस बीच @ karabaja4 हैक का उपयोग करें - आपके काम के लिए धन्यवाद!)

+1
ऐसा इसलिए कर रहे हैं क्योंकि सिर्फ देवचैट की बात

@ karabaja4 बहुत अच्छा काम। एक अन्य दृष्टिकोण: init पर git status चलाने के बारे में कैसे, और फिर जब भी onFileSave ईवेंट निकाल दिया जाए तो अपडेट करें? क्या यह अधिक कुशल होगा?

शायद हम जिस तरह से गिट स्थिति को रीफ्रेश करते हैं उसे कॉन्फ़िगर कर सकते हैं।

+1 अगर जोड़ा जाए तो यह बहुत मददगार होगा

@ कैजुन मुझे यकीन नहीं है कि मैं इसे कैसे कार्यान्वित करूंगा। onFileSave इवेंट कहां से आएगा?

यदि यह दस्तावेज़ सहेजने पर कोड से आता है (यह मानते हुए कि मुझे पता है कि इसे कैसे संलग्न करना है), कोड के बाहर संशोधित फ़ाइलों को अनदेखा कर दिया जाएगा, जैसे कि फ़ाइलों को स्थानांतरित करना और कॉपी करना।

यदि यह फोल्डर वॉच लॉजिक से आता है जिसे सॉल्यूशन ट्री पर लागू किया गया है, तो इसे पूरे ट्री के लिए पुनरावर्ती रूप से करना होगा। मुझे यकीन नहीं है कि यह प्रदर्शन के लायक है या नहीं।

@ karabaja4 मुझे लगता है कि कोड बाहरी परिवर्तनों का भी पता लगाता है। तो इस तरह के "ईवेंट" में शायद एक बहस प्रणाली के साथ जुड़ना ताकि एक ही अंतराल में कई फ़ाइल परिवर्तन बहुत अधिक गिट स्थिति जांच को ट्रिगर न करें। यह काम कर सकता है!. शायद एफएस पीस से परिचित कोई व्यक्ति इसमें झंकार कर सकता है?

यह वास्तव में बैकलॉग पर नहीं होना चाहिए। इस छोटी सी विशेषता को जोड़ने में एक बहुत ही वास्तविक मूल्य है। डेवलपर खुशी साथ-साथ चलती है। यह देखकर निराशा होती है कि इस मुद्दे पर हजारों +1 हैं और 2015 से इस पर ध्यान नहीं दिया गया है।

@kamok सच है कि! हालांकि एटम धीमा है, मेरे पास एक और विकल्प था ... मैं वेबस्टॉर्म पर वापस गया, जो कि जिस तरह से गिट प्लस अन्य सुविधाओं के साथ एकीकृत है, जिसके लिए आपको बनाम कोड पर एक्सटेंशन इंस्टॉल करना पड़ता है, और यह अभी भी इतना तेज़ होने का प्रबंधन करता है और गति के मामले में एक IDE के बजाय एक हल्के संपादक की तरह लगते हैं। अकेले यह सुविधा (फ़ाइल एक्सप्लोरर में गिट स्थिति) अभी भी बनाम कोड उपयोगकर्ताओं को रखने के लिए पर्याप्त नहीं होगी। यह बाल्टी में सिर्फ एक बूंद होगी। वेबस्टॉर्म से आने वाली यह विशेषता मुझे कम से कम याद आती है।
मेरा सुझाव है कि vscode टीम इस पर एक नज़र डालें कि JetBrains के लोग इसे कैसे कर रहे हैं।
मुझे खेद है, लेकिन मैंने कोशिश की है ... मैं महीनों के लिए बनाम कोड के साथ संघर्ष कर रहा हूं, अपडेट के बाद अपडेट की प्रतीक्षा कर रहा हूं, लेकिन मैं अभी भी खुद को लगातार बनाम बंद कर रहा हूं और वेबस्टॉर्म में प्रोजेक्ट को फिर से खोल रहा हूं: एक्सप्लोरर में गिट स्थिति स्थानीय परिवर्तनों के लिए ट्री, स्टैश, फोल्डर / ट्री व्यू, शाखाओं की तुलना, राइट क्लिक> क्लिपबोर्ड के साथ तुलना करें ... और ये मेरे सिर के ऊपर से हैं। यदि वे वास्तव में डेवलपर्स की मदद करना चाहते हैं तो Vscode Git एकीकरण के पास अभी भी जाने का एक बहुत ही आसान तरीका है।

_मेरे Samsung SM-G950F से FastHub का उपयोग करके भेजा गया _

@MrCroft मेरा सुझाव है कि यदि आप उनकी कार्य पद्धति के बारे में बहुत चिंतित हैं तो आप सीधे टीम से संपर्क करें, अन्यथा आप इस मुद्दे को एक अंगूठे के साथ +1 करते हैं और संपादकों को स्विच करते हैं यदि यह आपको इतना परेशान करता है।

@cucumbur मैंने पहले ही किया था (vscode से स्विच किया गया)। मैं सिर्फ अपना दुख बता रहा हूं, क्योंकि मुझे वास्तव में पसंद आया कि vscode कैसा लगा। मैं इसके लिए अच्छा गिट एकीकरण करना पसंद करता ताकि मैं इसका उपयोग करना जारी रख सकूं। मुझे यकीन है कि बहुत से लोग ऐसा ही महसूस करते हैं।
मैं अभी भी इस पर नजर रखूंगा। हो सकता है, कौन जानता है, "बहुत दूर के भविष्य में" यह किया जाएगा ... बनाम कोड के अलावा, मैं वास्तव में एक बहुत बड़ा माइक्रोसॉफ्ट प्रशंसक हूं ... सॉफ्टवेयर और हार्डवेयर, वे 10 में से 9 बार बहुत उच्च गुणवत्ता वाले सामान का निर्माण करते हैं . मुझे उम्मीद है कि vscode 9 में से एक बन जाएगा।

_मेरे Samsung SM-G950F से FastHub का उपयोग करके भेजा गया _

@kamok हर नया मुद्दा बैकलॉग में चला जाता है और तब तक वहीं रहता है जब तक उनका समाधान नहीं हो जाता। मुझे नहीं लगता कि इस सुविधा की बिल्कुल भी अवहेलना की गई है। आपको जितना एहसास होता है, उससे कहीं अधिक परिवर्तनों की आवश्यकता है। जहां तक ​​​​मुझे पता है कि वे इसे एक्सटेंशन एपीआई का हिस्सा बनाना चाहते हैं, और वर्तमान में फ़ाइल ट्री में ऐसा करने के लिए बहुत सारी सुविधाओं का अभाव है।

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

हालांकि इस धागे पर एक सामयिक अद्यतन बहुत अच्छा होगा।

परमाणु से स्विच किया गया लेकिन एक बड़ी परियोजना पर अद्यतन फ़ाइलों को हाइलाइट न करने से काम करना मुश्किल हो जाता है।
यह सुविधा उपलब्ध होने तक वापस एटम पर स्विच करना

शायद यह उल्लेखनीय है कि एक वैकल्पिक/अंतरिम समाधान जो मेरे लिए काम करेगा ... "ओपन एडिटर्स" दृश्य में पेड़ की संरचना को डुप्लिकेट करना है। आम तौर पर दृश्य मुझे "अपडेटेड" फाइलें दिखा रहा है, लेकिन इसके साथ काम करने के लिए फ़ाइल नामों का सिर्फ एक डंप इतना कठिन है, क्योंकि यह स्पष्ट था कि परियोजना में ये फाइलें कहां पाई जाती हैं।

इस पर कोई अपडेट?

https://www.youtube.com/watch?v=rTyN-vvFIkE&t=4s

मैं मर्दवादी हूँ - मेरी अपनी टिप्पणी।

मैं VSCode की कोशिश करता रहता हूं लेकिन चूंकि इस सुविधा की कमी है, यह मुझे स्विच करने से रोकता है। जब तक मैंने स्विच करने की कोशिश नहीं की, तब तक मुझे एहसास नहीं हुआ कि मैं एटम में इस सुविधा पर कितना भरोसा करता हूं।

परमाणु से वीएस कोड पर स्विच करने के लिए बस इसके लिए प्रतीक्षा कर रहा है, आशा है कि यह जल्द ही लागू हो जाएगा।

+1

दो साल बीत गए。。。

और आश्चर्यजनक रूप से आपकी टिप्पणी ने उसे बदल नहीं दिया। हम में से जो विकास और संभावित योगदान की परवाह करते हैं, वे थ्रेड जारी करते हैं, आपकी टिप्पणी ने कुछ भी मदद नहीं की और यह 99 लोगों को एक बेकार ईमेल भेजती है

अरे जब तक आप कोशिश नहीं करते, आपको कोई परिणाम नहीं मिलता है, है ना?

मैंने शुरुआत में इसे बहुत याद किया, और हालांकि इसे प्राप्त करना बहुत सुविधाजनक होगा, 'डिफ एक्सप्लोरर' (ऊर्ध्वाधर मेनू में तीसरा आइकन) वास्तव में शक्तिशाली है और यह बहुत उपयोगी है

+1
अगर यह लागू किया गया तो बहुत बढ़िया होगा ...!

मैंने एक गल्प कार्य लिखा है जो हैक की स्थापना को सरल बनाना चाहिए (केवल वीएस कोड 1.15)।

git clone https://github.com/karabaja4/vscode-explorer-git-status.git
cd vscode-explorer-git-status
npm install
gulp install # as root/administrator

पीएस अभी तक सभी प्लेटफार्मों पर परीक्षण नहीं किया गया है, अगर कोई ओएसएक्स पर कोशिश करेगा तो इसकी सराहना होगी।

@ karabaja4 ऐसा नहीं लगता कि आपका 'हैक' इतना जटिल है कि इसे vscode में ही लागू किया जा सकता है। जैसा कि ऐसा लगता है कि vscode देव इस मुद्दे को जल्द ही ठीक नहीं कर रहे हैं, हो सकता है कि आप एक पुल अनुरोध बना सकें?

@ karabaja4 इसके लिए धन्यवाद! मैकोज़ सिएरा, वीएससीओडी 1.15.1 पर मेरे लिए काम करना।

@ कराबाजा4 धन्यवाद! फेडोरा 26, VSCode 1.15.0 पर यहां कार्य करना। उस अकेले ने एटम से स्विच ओवर को और अधिक सुविधाजनक बना दिया।

@ कराबाजा4 +1 धन्यवाद !! मेरे लिए Ubuntu 14.04 64, VSCode 1.15.1 (मैन्युअल इंस्टॉलेशन) पर काम करना

+1

@ karabaja4 +1 यह कमाल है।

+1

@मत्ती प्लस वन

_ FastHub का उपयोग करके arm64 के लिए मेरे HTC MSM8996 से

@ibrokemypie माइनस टू

Lolbug का उपयोग करके arm32 के लिए मेरे HTC MKB826262 से भेजा गया

इस फीचर के बारे में कोई खबर?

+1

+1

+1

@karabaja4 धन्यवाद आदमी =डी <3

+1

वाह, इसे दो साल पहले लागू कर दिया जाना चाहिए था

@eosrei +1

+1

+1
हकीकत का सामना करते हैं; मुझे वीएससीओडी पसंद है, लेकिन गिट टैब वास्तव में बेकार है

@ karabaja4 नमस्ते, १.१६ अभी-अभी निकला, क्या आप इस रिलीज़ पर अपना हैक पोर्ट करेंगे? धन्यवाद।

संपादित करें: 1.16 के साथ काम करता है, मल्टी रूट वर्कस्पेस का उपयोग करते समय नहीं।

@ karabaja4

@ karabaja4 ने मेरा दिन बना दिया। धन्यवाद दोस्त!

+1

+1

एक +1 टिप्पणी GitHub मुद्दों पर एक स्वचालित प्रतिबंध होना चाहिए...

अच्छा होगा यदि गिटहब ने सिर्फ +1 पोस्ट को पार्स किया और मूल पोस्ट पर स्वचालित रूप से उन्हें थम्स अप इमोजी प्रतिक्रिया के साथ बदल दिया।

@ karabaja4 आपका हैक OSX 10.12.6 पर चलता है - कमाल! धन्यवाद।

git clone https://github.com/karabaja4/vscode-explorer-git-status.git
cd vscode-explorer-git-status
npm install
gulp install # as root/administrator

केवल एक चीज मुझे अब बूट पर एक चेतावनी संदेश मिलता है। सौभाग्य से, यह सिर्फ एक चेतावनी है।

वीएससीओडी संस्करण 1.16.0

+1

क्या कोई कारण है कि इसे अभी तक लागू नहीं किया गया है या क्या कोई समयरेखा है जब इस सुविधा को जोड़ा जाएगा?

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

संपादित करें: बस एक कामकाज मिला। बनाम कोड फ़ाइलों में से एक में एक लाइन जोड़ना (<1min प्रयास) एक आकर्षण की तरह काम करता है! https://github.com/karabaja4/vscode-explorer-git-status

@timc13 @fro3clr @WLLR9505 @ngortheone @edokeh @ncnegoleo @loehx @aecorredor @BenGale

क्या आपने कभी देखा है कि आप पोस्ट +1 बजाय इमोजी प्रतिक्रिया का उपयोग कर सकते हैं?

हर बार जब हम जीथब पर टिप्पणियां पोस्ट करते हैं, तो विषय के सभी ग्राहकों को सूचनाएं प्राप्त होती हैं और कुछ उपयोगकर्ता ईमेल भी प्राप्त करते हैं। यह लिखा हुआ एक ईमेल पढ़कर निराश है: +1 और आप उन टिप्पणियों पर देख सकते हैं, बहुत कुछ है: -1:।

यदि हम सभी इसके बजाय प्रतिक्रियाओं का उपयोग करना शुरू करते हैं तो समुदाय सराहना करता है:
https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments

मैं इस जानकारी के साथ किसी भी अपराध के लिए और इस सूचना को प्राप्त करने वाले अन्य लोगों के लिए क्षमा चाहता हूं।

मैंने अन्य थ्रेड्स में पढ़ा था कि Microsoft ने +1 टिप्पणियों की संख्या के आधार पर किसी सुविधा की प्राथमिकता का मूल्यांकन किया। अगर मुझसे यह गलती हुई है तो मैं माफी मांगता हूं और किसी भी तरह से किसी फीचर को रैंक नहीं किया जाता है। मैंने अपनी टिप्पणी हटा दी। किसी भी तरह, आक्रामक रवैये के साथ क्या है भाई? आप एक ही बात को बेहतर लहजे में बता सकते थे @leocaseiro

चीयर्स।

हाय @aecorredor , अगर अशिष्ट लग रहा हो तो मैं क्षमा चाहता हूं।
मैं एक देशी अंग्रेजी स्पीकर नहीं हूं और शायद मेरी अनुवादित अभिव्यक्तियों में से एक खराब लग रहा था। कृपया, उस टिप्पणी के विवरण को बेहतर बनाने में मेरी सहायता करें। क्या मुझे कष्टप्रद शब्द को बदलना चाहिए? न काम की? धन्यवाद।

पुनश्च: मुझे खुशी है कि आपने मेरे ईमेल पर पढ़ी गई दुनिया को संपादित किया, क्योंकि मैं कठोर लग सकता था, लेकिन किसी को ठेस पहुंचाने का मेरा इरादा कभी नहीं था।

अपडेट करें: मैंने अपनी पिछली टिप्पणी को बदल दिया है, अगर बेहतर लगे तो कृपया मुझे बताएं। धन्यवाद

अरे @leocaseiro ,

उस बुरे शब्द को पहली जगह लिखने के लिए खेद है। मुझे वास्तव में एहसास हुआ
कि एक भाषा बाधा शायद वही थी जो भ्रम पैदा कर रही थी। परंतु
हाँ, मैं उन दो शब्दों को कुछ और के साथ बदल दूंगा:
"कृपया, हम सभी के लिए समग्र जीथब अनुभव को बेहतर बनाने की कोशिश कर रहे हैं
खुले मुद्दे/सुविधा अनुरोध, और यह अच्छा होगा यदि लोग उपयोग करना शुरू कर दें
"+1" जैसी टिप्पणियों के बजाय इमोजी प्रतिक्रियाएं, जो बस बनाते हैं
थ्रेड में अनावश्यक ओवरहेड, और उन ईमेल को ट्रिगर करें जो वास्तव में नहीं हैं
सार्थक रूप से अपना योगदान दे रहे हैं। कृपया इस लिंक को देखें कि कैसे
इमोजी प्रतिक्रियाएं काम करती हैं: {यहां लिंक करें}

चीयर्स, और कोई कठिन भावना नहीं।

श्रेष्ठ।

सोम, 18 सितंबर, 2017 को रात 11:44 बजे, लियो कैसीरो नोटिफिकेशन @github.com
लिखा था:

नमस्ते @aecorredor https://github.com/aecorredor , अगर अच्छा लगे तो मैं क्षमाप्रार्थी हूँ
अशिष्ट।
मैं एक देशी अंग्रेजी स्पीकर नहीं हूं और शायद मेरे अनुवादित में से एक हूं
अभिव्यक्ति खराब लग रही थी। कृपया, विवरण को बेहतर बनाने में मेरी सहायता करें
वह टिप्पणी। क्या मुझे कष्टप्रद शब्द को बदलना चाहिए? न काम की? धन्यवाद।

पुनश्च: मुझे खुशी है कि आपने मेरे ईमेल पर पढ़ी गई दुनिया को संपादित किया, क्योंकि मैं कर सकता हूं
अशिष्ट लग रहा है, लेकिन किसी को ठेस पहुंचाने का मेरा इरादा कभी नहीं था।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/Microsoft/vscode/issues/178#issuecomment-330420547 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AIsVa9fgWXPMFBgkZdHjQHKhUEDJb8Bmks5sjziWgaJpZM4GlYyH
.

https://github.com/Microsoft/vscode/blob/master/CONTRIBUTING.md

"+1" टिप्पणी के स्थान पर प्रतिक्रिया का प्रयोग करें।

+1

मैं वास्तव में उम्मीद कर रहा था कि पिछली टिप्पणियों के बाद +1 की संख्या घट जाएगी, लेकिन फिर अचानक एक और +1 दिखाई दिया 😁 ।

यह शर्म की बात है, क्योंकि प्रोग्रामर अक्सर उपयोगकर्ताओं को त्रुटि संदेश न पढ़ने के लिए दोषी ठहराते हैं, लेकिन कुछ टिप्पणियों या निर्देशों को नहीं पढ़ सकते हैं।

हो सकता है कि उपयोगकर्ताओं को +1 टिप्पणी करने के बजाय प्रतिक्रियाओं का उपयोग करने के लिए कहने के लिए README.md पर कुछ डालने लायक होगा? शायद CONTRIBUTING.md पर यह थोड़ा छिपा हुआ है।

मुझे नहीं पता, मुझे लगता है कि मैं अभी सदस्यता समाप्त कर दूंगा और इसके तैयार होने पर रिलीज नोट्स की प्रतीक्षा करूंगा।

मैंने एक Gist बनाया है जो इसका ख्याल रखता है। @ karabaja4 द्वारा ठीक किया गया अनदेखा फ़ाइलों/फ़ोल्डरों को ठीक से ग्रे नहीं करता है (उसके मुद्दों को देखें)। @dseipp द्वारा एक पीआर है

इसलिए यदि आप इसे बहुत बेहतर तरीके से काम करना चाहते हैं, तो मेरा सार देखें: https://gist.github.com/WadeShuler/1637073371ad126779076344c34278f3

@ikatyang : क्षमा करें, क्या इसका मतलब यह है कि यह सुविधा अक्टूबर (2017) में पेश की जा रही है ..?

@nkkollaw लिंक इस टिप्पणी से था: https://github.com/Microsoft/vscode/issues/34160#issuecomment -331066864

टिप्पणी सिर्फ इस मुद्दे से संबंधित चीजों पर चर्चा करने के लिए कह रही थी, न कि "इटरेशन प्लान" में (और अंग्रेजी में उन पर चर्चा करने के लिए कह रही थी)।

आह, मिल गया @tiangolo , धन्यवाद।

मैं इस कार्यक्षमता को लागू करने के लिए एक एपीआई होने तक एटम के साथ रखने की कोशिश करूंगा (क्षमा करें, मैं इसमें मदद करने के लिए पर्याप्त नहीं हूं)।

मैं परियोजना के भीतर ही अद्यतन करने पर काम कर रहा हूँ।
अभी के लिए, मैंने अवधारणा का एक प्रमाण बनाया है जो काम कर रहा है, लेकिन मैं tslint पास नहीं करता, क्योंकि मुझे अभी भी सब कुछ सही जगह पर रखने के लिए परतों को समझने की आवश्यकता है।
मैं यहां कुछ अपडेट डालूंगा, और अगर कोई मेरी मदद करना चाहता है तो मैं अपने पुल अनुरोध का लिंक बाद में डालूंगा ताकि मदद के लिए आपका स्वागत है।

अक्टूबर 2017 पुनरावृत्ति में नियोजित !! मैं

हमारे पास इसका पहला संस्करण है। सभी निश्चिंत रहें कि यह अक्टूबर में आएगा।

थोड़ी और जानकारी:

• रंगों को थीम में परिभाषित किया जाएगा जिसका अर्थ है कि उन्हें आपके स्वाद के अनुरूप बनाया जा सकता है
• इसे सक्षम/अक्षम करने के लिए एक सेटिंग होगी
• यह संस्करण नियंत्रण के लिए अनन्य नहीं है। हम फ़ाइल एक्सप्लोरर में त्रुटियों / चेतावनियों को उजागर करने पर भी विचार कर रहे हैं (देखें #782) और हम इसे विस्तार लेखकों के सामने लाने के बारे में सोच रहे हैं।

प्रश्न खोलें:

• क्या सिर्फ एक रंग का इस्तेमाल काफी है? क्या कोई टेक्स्टुअल और/या आइकन हिंट भी होना चाहिए?
• माता-पिता को किस बच्चे की स्थिति उठानी चाहिए? क्या यह महत्व से जाना चाहिए? त्रुटियों और चेतावनियों के साथ यह आसान है लेकिन क्या अधिक महत्वपूर्ण है, एक बदली हुई, एक ट्रैक न की गई, या एक अनदेखी फ़ाइल?
• क्या हमें इन फाइल डेकोरेशन को "ओपन एडिटर्स" बकेट और/या फाइल पिकर आदि में भी दिखाना चाहिए?

सामान होने के दौरान मैं इस मुद्दे को अप-टू-डेट रखूंगा। हमेशा की तरह, "+1" -टिप्पणियों के बजाय भावनाओं का उपयोग करें। धन्यवाद और हैप्पी कोडिंग!

व्यक्तिगत रूप से, मैं ऊपर की छवि पर जो देख रहा हूं वह पर्याप्त है। बहुत अच्छा लग रहा है और धन्यवाद!

ऐसा लगता है कि गहरे भूरे रंग में .gitignore द्वारा अनदेखा की गई फ़ाइलों को याद आती है?

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

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

मुझे यह भी लगता है कि यदि त्रुटियां हैं, तो शायद पेड़ में फ़ाइल नाम से पहले या बाद में एक बिंदु का उपयोग करें। यह गैर-आक्रामक होगा, थीम को उन्हें स्टाइल करने दें, और गिट रंग हाइलाइटिंग में हस्तक्षेप नहीं करेगा।

हाँ इसे विस्तार डेवलपर्स के लिए खोला जाना चाहिए! पहले ही कर देना चाहिए था। हम अच्छा एक्सटेंशन बनाने या उन चीजों को ठीक करने के लिए फ़ाइल ट्री पर नियंत्रण क्यों नहीं रखना चाहेंगे जो आप लोगों ने नहीं की?

ऐसा लगता है कि गहरे भूरे रंग में .gitignore द्वारा अनदेखा की गई फ़ाइलें याद आती हैं?

ज़रूर, इसका काम प्रगति पर है और चीज़ें एक-एक करके होती हैं। अनसुनी फाइलें आएंगी, अक्टूबर में भी।

यह अच्छा होगा यदि आप लोग हमें अपने काम करने की अनुमति दें, तो हम इसके साथ खेल सकते हैं, और पीआर बना सकते हैं।

ज़रूर, यह सब joh/feco -शाखा में है। एक नई सजावट सेवा है जो वास्तविक डेटा के लिए प्रदाताओं का उपयोग करती है। उपभोग पक्ष पर फ़ाइल लेबल है जिसका उपयोग हम फ़ाइल नामों को प्रस्तुत करने के लिए करते हैं

आप केवल एक अनदेखा फ़ाइल के लिए मूल फ़ोल्डर का रंग (ग्रे आउट) नहीं बदलते हैं। आप इसे केवल तभी धूसर कर देते हैं जब फ़ोल्डर को स्वयं अनदेखा कर दिया जाता है। कृपया मेरी टिप्पणी देखें/कुछ टिप्पणियों को ठीक करें।

मुझे लगता है कि "अनदेखी फाइलें और उनके बच्चे (यदि कोई हैं) धूसर हो गए हैं" बहुत स्पष्ट है।

@nkkollaw आप किस बारे में बात कर रहे हैं ?!

@jrieken में कहा:

“Which child status should a parent pick up? Should this go by importance? That's easy with errors and warnings buts what's more important, a changed, an untracked, or an ignored file?“

उन्होंने एक अनदेखी फ़ाइल का संकेत दिया जो संभवतः मूल फ़ोल्डर की स्थिति को प्रभावित कर रही है, जो इसे नहीं करना चाहिए!

आपका निष्क्रिय आक्रामक संदेश इस धागे को अनुपयोगी संदेशों से रोक रहा है...

@WadeShuler : मुझे नहीं पता कि _you_ किस बारे में बात कर रहे हैं।

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

से संबंधित:

आपका निष्क्रिय आक्रामक संदेश इस धागे को अनुपयोगी संदेशों से रोक रहा है...

मुझे नहीं पता कि मेरा संदेश कैसे निष्क्रिय-आक्रामक था- मुझे लगता है कि आप इसका मतलब नहीं जानते हैं- लेकिन आप ही इस धागे को रोक रहे हैं, क्योंकि आप अकेले हैं जिन्होंने मेरे संदेश के बाद टिप्पणी की है।

अजीब।

वाह.. अच्छा विचार! मुझे यह पसंद है!

मैं एक दाहिने कॉलम पर सिंगल कैरेक्टर टेक्स्टुअल हिंट की तरह एक्सकोड रखना चाहता हूं। फ़ाइलों को फ़िल्टर करना/दृश्य रूप से अनुसरण करना आसान बनाता है।

@nkkollaw मैंने कहा:

आप केवल एक अनदेखा फ़ाइल के लिए मूल फ़ोल्डर का रंग (ग्रे आउट) नहीं बदलते हैं। आप इसे केवल तभी धूसर कर देते हैं जब फ़ोल्डर को स्वयं अनदेखा कर दिया जाता है।

जाहिर है, मैं पैरेंट फोल्डर की बात कर रहा हूं, बच्चों की नहीं। यहाँ, मैंने आपको एक चित्र बनाया है:

यहाँ है .gitignore पेरेंट निर्देशिका में, web संदर्भ के लिए:

/index.php
/index-test.php
!/assets/css
!/assets/fonts
!/assets/js
!/assets/themes
/assets/*

मेरा संदेश WIP के @jrieken के उत्तर का उत्तर था, यहाँ , जहाँ वे कहते हैं:

माता-पिता को किस बच्चे की स्थिति उठानी चाहिए? क्या यह महत्व से जाना चाहिए? त्रुटियों और चेतावनियों के साथ यह आसान है लेकिन क्या अधिक महत्वपूर्ण है, एक बदली हुई, एक ट्रैक न की गई, या एक अनदेखी फ़ाइल?

यह दर्शाता है कि "अनदेखा" फ़ाइल/फ़ोल्डर के माता-पिता की स्थिति हो सकती है, जो कि नहीं है। इसलिए मेरा जवाब। आप भ्रमित कर रहे हैं कि आप क्या देखते हैं, बनाम क्या गिट वास्तव में इसकी अनदेखी सूची के लिए उपयोग करता है

➜  yii2-mlm git:(master) ✗ git status --short --ignored
 M backend/views/layouts/_left.php                   <-- Modified File
?? backend/controllers/PayoutController.php         <-- Added File
?? backend/views/payout/                            <-- Added Directory
?? common/models/Payout.php                         <-- Added File

!! backend/runtime/logs/                            <-- Ignored Directory (everything inside)
!! backend/web/assets/6f57f06b/                     <-- *special rule - Ignored Directory (everything inside)
!! backend/web/assets/9e65c758/                     <-- *special rule - Ignored Directory (everything inside)
!! backend/web/assets/1ecaa825/                     <-- *special rule - Ignored Directory (everything inside)

!! node_modules/                                    <-- Ignored Directory (everything inside)
!! vendor/                                          <-- Ignored Directory (everything inside)

*special rule अर्थ है कि इसे एक विशेष नियम के साथ .gitignore में परिभाषित किया गया है, इसलिए यह केवल backend/web/assets/ क्यों नहीं है और यह विशेष रूप से यादृच्छिक नामित संपत्ति डीआईआर है। जब आप उस निर्देशिका से निपटते हैं जहां इसकी सामग्री को अनदेखा किया जाता है, तो आप प्रत्येक अनदेखा फ़ाइल निर्दिष्ट नहीं करते हैं। जैसे vendor या node_modules निर्देशिका। git status अनदेखा प्रविष्टि में उनके पास केवल एक प्रविष्टि है।

फ़ाइल-पेड़ में, आपको git-status-ignored से शुरू होने वाले सभी तत्वों (फ़ाइलों और फ़ोल्डरों) में git-status-ignored की कक्षा जोड़ने की आवश्यकता है backend/web/assets/6f57f06b/ ।

फ़ाइल-पेड़ फ़ोल्डर से मिलान करने के लिए सीएसएस backend/web/assets/6f57f06b/ इस तरह है (वर्तमान में 2 नियम लेता है!):

#workbench\.view\.explorer .explorer-folders-view .monaco-tree .monaco-tree-rows .monaco-tree-row .explorer-item[title="/Applications/XAMPP/xamppfiles/htdocs/yii2-mbn/backend/web/assets/6f57f06b" i] {
    opacity: 0.4 !important;
}

तथा

#workbench\.view\.explorer .explorer-folders-view .monaco-tree .monaco-tree-rows .monaco-tree-row .explorer-item[title^="/Applications/XAMPP/xamppfiles/htdocs/yii2-mbn/backend/web/assets/6f57f06b/" i] {
    opacity: 0.4 !important;
}

सूचना: पहले नियम में, हम शीर्षक का मिलान केवल = चिह्न के साथ करते हैं, इसलिए बिल्कुल! दूसरे नियम में, हम ^= साथ सभी शीर्षकों का मिलान करते हैं, इसलिए स्ट्रिंग की शुरुआत, उससे भी अधिक गहराई से मेल खाती है (सभी बच्चे)।

एक निर्देशिका से मिलान करने के लिए 2 सीएसएस नियम लेता है। तो मुझे लगता है कि ऐसा करते समय, हमें आगे बढ़ना चाहिए और title निर्देशिकाओं के लिए HTML तत्व पर, एक पिछला स्लैश शामिल करने के लिए बनाना चाहिए। आप इस स्क्रीनशॉट में देख सकते हैं कि मैं किस बारे में बात कर रहा हूं:

हां, आपकी टिप्पणी निष्क्रिय आक्रामक थी, क्योंकि आप वास्तव में शब्दों को कहे बिना असभ्य/स्नर्क/भद्दे थे। इसके अलावा आप गलत थे। बच्चों के बारे में किसी ने कुछ नहीं कहा, और यह वह भी नहीं है जिसके बारे में हम बात कर रहे थे।

@jrieken
जिस तरह से एटम का मेरा सेटअप काम करता है: "संपादित" को "जोड़ा गया" पर प्राथमिकता है। किसी फ़ाइल को हटाना कोई स्थिति नहीं दिखाता है। "मंचन" के लिए कोई स्थिति नहीं है। मुझे लगता है कि दूसरों को अपने एटम सेटअप की जांच करनी चाहिए और देखना चाहिए कि क्या यह उनके लिए भी सच है, और यह सिर्फ मेरा सेटअप नहीं है। हर स्थिति के लिए कोड जोड़ना अच्छा होगा, और उपयोगकर्ता को इसे काम करने के लिए संपादित करने दें कि वे कैसे चाहते हैं।

हो सकता है कि कई वर्ग जोड़ें, इसलिए मूल निर्देशिका पेड़ के ऊपर "गिट-स्थिति-जोड़ा" और "गिट स्थिति-संशोधित" होगी। शायद "गिट-स्टेटस-डिलीट" में भी टॉस करें अगर इसके तहत कुछ हटा दिया गया है।

फिर उनसे मिलान करने के लिए बस css का उपयोग करें। यदि आप .git-status-added.git-status-modified लिए एक अलग रंग चाहते हैं, तो आप हरे रंग की अंडरलाइन के साथ नारंगी फ़ॉन्ट कर सकते हैं (संशोधित के लिए नारंगी, जोड़ा के लिए हरा)। यदि इसमें केवल .git-status-added वर्ग था, तो फ़ॉन्ट को हरा बनाएं।

एक बार जब आप उनमें कक्षाएं जोड़ लेंगे तो इससे कोई फर्क नहीं पड़ेगा, हर कोई कुछ सीएसएस को चाबुक कर सकता है, हालांकि वे चाहते हैं। हालांकि आप बॉक्स से बाहर "बहुत अच्छा" डिफ़ॉल्ट रहना चाहते हैं।

जब मुझे कुछ समय मिलेगा तो मैं उस शाखा को खींच लूंगा और उसे देख लूंगा।

लिंट त्रुटियों और गिट स्थिति को कैसे संभालें?

जैसा कि आप यहाँ देख सकते हैं, एटम फ़ाइल नाम के नीचे एक लाल रंग की स्क्विगली लाइन डालता है:

मुझे लगता है कि हमें गिट स्थिति के समान तत्व में lint-error जैसे वर्ग को जोड़ना चाहिए, जिसे हम (और थीम) अपनी स्टाइलशीट के माध्यम से ओवरराइड कर सकते हैं।

तो फ़ाइल-पेड़ में उसी तत्व के लिए div जैसा कि मैंने ऊपर एक उदाहरण के रूप में उपयोग किया था (बैकएंड/वेब/संपत्ति/6f57f06b):

<div class="monaco-icon-label folder-icon 6f57f06b-name-folder-icon explorer-item" title="/Applications/XAMPP/xamppfiles/htdocs/yii2-mbn/backend/web/assets/6f57f06b" style="display: block;"> </div>

कुछ इस तरह दिखेगा, जब हम git-status-edited और lint-error git status दोनों लागू करते हैं:

<div class="monaco-icon-label folder-icon 6f57f06b-name-folder-icon explorer-item git-status-edited lint-error" title="/Applications/XAMPP/xamppfiles/htdocs/yii2-mbn/backend/web/assets/6f57f06b" style="display: block;"> </div>

तब हम CSS के माध्यम से मिलान कर सकते थे:

.folder-icon.explorer-item.git-status-edited {
    color: #cbcb41;  // yellow
}

// Adds a squiggly red line under the filename in the left tree-view list
.folder-icon.explorer-item.lint-error a.label-name {
    background-image: linear-gradient(45deg, transparent 65%, #cc3e44 80%, transparent 90%), linear-gradient(135deg, transparent 5%, #cc3e44 15%, transparent 25%), linear-gradient(135deg, transparent 45%, #cc3e44 55%, transparent 65%), linear-gradient(45deg, 
    transparent 25%, #cc3e44 35%, transparent 50%);
    background-size: 8px 2px;
    background-repeat: repeat-x;
    background-position: left bottom;
}

क्या आप लोगों के पास स्लैक है? कमिट में बहुत सारी संपादित फाइलें हैं। मैं ठीक उसी जगह की तलाश में हूं जहां आप फ़ाइल-पेड़ पर गिट स्थिति रंग लागू कर रहे हैं। क्या यह /extensions/git/src/repository.ts में है ?

सभी को धन्यवाद और परिवर्तनों के नियमों को स्पष्ट करने के लिए धन्यवाद, ट्रैक नहीं किया गया, और फाइलों को नजरअंदाज कर दिया। कल अंदरूनी सूत्र इसके शुरुआती संस्करण के साथ शिप करेंगे।

कुछ चीजें

• डिफ़ॉल्ट रूप से रंग और बैगडे का संयोजन होता है।
  
  
  
  • इसके साथ आइकन सक्षम/अक्षम करें: "explorer.decorations.badges": true|false
  
  
  • "explorer.decorations.colors": true|false साथ रंगों को सक्षम/अक्षम करें
  
  
• फ़ाइल ट्री, खुले संपादक अनुभाग और SCM व्यूलेट में रंग दिखाई देते हैं
• शुरू करने के लिए तीन रंग हैं। आप उन्हें workbench.colorCustomizations -सेटिंग में कस्टमाइज़ कर सकते हैं। रंग हैं gitDecoration.modifiedResourceForeground ,
  gitDecoration.deletedResourceForeground ,
  gitDecoration.untrackedResourceForeground ,
  gitDecoration.ignoredResourceForeground , और
  gitDecoration.conflictingResourceForeground
• ध्यान दें कि सेटिंग्स आदि के नाम बदल सकते हैं, नई सेटिंग्स जोड़ी जा सकती हैं, अन्य सेटिंग्स फिर से हटाई जा सकती हैं।

FYI करें - प्रारंभिक पोस्ट के बाद किए गए परिवर्तनों को दर्शाने के लिए संपादित किया गया

मुझे लगता है कि पैरेंट डायरेक्टरी में राइट-साइड आइकन्स को लागू नहीं करना बेहतर है। कम से कम एक विकल्प हो सकता है।

ऐसा लगता है कि इसे अंदरूनी संस्करण में scm.fileDecorations.useIcons और scm.fileDecorations.useColors साथ scm.fileDecorations.enabled बदल दिया गया है जो आइकन और रंग दोनों देता है।

मैं केवल रंग रखना चाहता हूं लेकिन प्रतीक नहीं। IE scm.fileDecorations.useIcons : false और scm.fileDecorations.useColors : true . का "पुराना" व्यवहार

मैंने explorer.decorations.badges और explorer.decorations.colors साथ प्रयोग करने की कोशिश की है लेकिन उनका कोई असर नहीं हुआ है।

संपादित करें:
मैं विंडोज़ 10 पर संस्करण 1.18 इनसाइडर, कमिट f1ee80be081b0d ... चला रहा हूं
(यह अच्छा होगा यदि डायलॉग बॉक्स के बारे में टेक्स्ट हाईलाइट करने योग्य होगा ताकि आप कॉपी कर सकें)

इसे एक साथ रखने के लिए धन्यवाद @jrieken !

कुछ विचार थे:

• ऐसा लगता है कि चयनित रंग स्थिति रंग के बजाय अभी भी पुराना ग्रे है
• आइकन रखने या न होने के विकल्प से सहमत हैं (प्रति @FredrikFolkesson )
• आइकन दिखाने के साथ, यदि संशोधित/अपडेट किया गया रंग हल्का है, तो 'एम' या 'यू' गहरा (या इसके विपरीत) होना चाहिए ताकि कंट्रास्ट हो और इसे पढ़ना आसान हो।

रंग प्राप्त करने के लिए प्रत्येक बिल्ड के साथ main.js फ़ाइल को अपडेट न करने की प्रतीक्षा कर रहे हैं !!!

रिपोर्ट करने के लिए मामूली समस्या (मैं 16 अक्टूबर तक नवीनतम अंदरूनी सूत्रों का उपयोग करता हूं), @jrieken : यदि यह फ़ाइल वर्तमान में चुनी गई है तो प्रोजेक्ट ट्री में संशोधित फ़ाइल नाम का रंग नहीं दिखाया गया है। यहां उम्मीद यह है कि प्रोजेक्ट ट्री में फ़ाइल का चयन किया गया है या नहीं, इसका रंग समान होना चाहिए (संशोधित फ़ाइल को दर्शाता है)।

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

यह एक बेहतरीन फीचर होगा। एटम से वीएससी में नया और मुझे इसकी बहुत याद आती है।

बस एटम से भी चले गए और इस सुविधा को भी याद कर रहे थे। इस सुविधा के साथ रिलीज़ कब निर्धारित है?

इसी तरह, यह ज्यादातर महत्वपूर्ण है क्योंकि सूची में gitignored फ़ाइलें बहुत प्रमुख हैं और यह सब कुछ के साथ मिश्रित हो जाती है ...

नमस्ते, मुझे लगता है कि बैज अग्रभूमि रंग बदलने के लिए हमें एक रंग कुंजी की भी आवश्यकता है (#36246)

निरंतर प्रतिक्रिया के लिए सभी का धन्यवाद। मैंने हाल के परिवर्तनों को दर्शाने के लिए अपनी प्रारंभिक सारांश टिप्पणी अपडेट की है। मैंने यह भी सुनिश्चित किया है कि सेटिंग्स में परिवर्तन बिना पुनः लोड किए परिलक्षित होते हैं और यह कि स्थिति का रंग चयन रंग पर जीत जाता है।

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

@jrieken क्या आप मुझे बता सकते हैं कि बाएं फ़ाइल पेड़ एक्सप्लोरर के तत्वों पर सीएसएस कक्षाएं लागू की जा रही हैं या नहीं? यह सर्वोत्तम विस्तारशीलता प्रदान करेगा और थीम डेवलपर्स के लिए, और व्यक्तिगत रूप से, रंगों को अनुकूलित और ओवरराइड करना आसान बना देगा।

उदाहरण के लिए: जब आपका नया कोड किसी फ़ाइल या फ़ोल्डर को जोड़े गए के रूप में चिह्नित करता है, तो उसे git-status-added जैसे वर्ग को जोड़ना चाहिए। फिर हम अपनी स्टाइलशीट के माध्यम से रंगों को अनुकूलित करने के लिए लक्षित कर सकते हैं और जो आप हमें बॉक्स से बाहर देते हैं उसके साथ अटक नहीं जाते हैं।

@WadeShuler हमारी थीम/रंग अनुकूलन सीधे सीएसएस के साथ काम नहीं करता है, लेकिन कुछ के साथ हम थीम रंग कहते editorLineNumber.foreground लाइन नंबरों के लिए अग्रभूमि रंग का नाम है। विषयवस्तु उन नामों को रंग प्रदान करती है और प्रस्तुतीकरण करते समय संपादक उन मानों को चुन लेता है। इस पर अधिक पृष्ठभूमि के लिए इसे चेकआउट करें: https://code.visualstudio.com/docs/getstarted/theme-color-reference

अगले अंदरूनी सूत्रों के साथ, संभवत: कल 19 तारीख को, अनदेखी की गई फ़ाइलों ( git.color.ignored ) के लिए विशेष रेंडरिंग होगी और "ओपन एडिटर्स" अनुभाग में रंग/बैज दिखाई देंगे। मैंने तदनुसार https://github.com/Microsoft/vscode/issues/178#issuecomment -335511695 अपडेट किया है।

@jrieken बहुत बढ़िया! गिट बैज अग्रभूमि के लिए रंग कुंजी के बारे में क्या?
https://github.com/Microsoft/vscode/issues/178#issuecomment -336904514

बहुत अच्छा काम! इस सुविधा को vscode में आते देखकर बहुत अच्छा लगा।

वर्तमान कार्यान्वयन में एक सबमॉड्यूल में संशोधित फ़ाइलों को अभी तक संशोधित के रूप में सही ढंग से चिह्नित नहीं किया गया है।

निम्नलिखित उदाहरण में:

मुख्य भंडार में src/components/ में एक सबमॉड्यूल शामिल है। सबमॉड्यूल में कई फाइलों को संशोधित किया गया है। vscode सही ढंग से रिपोर्ट करता है src/components/ संशोधित किया गया है लेकिन यह इंगित नहीं कर रहा है कि सबमॉड्यूल में कौन से परिवर्तन किए गए हैं।

एटम संशोधित फाइलों की सही पहचान करता है:

यह समस्या संभवतः https://github.com/Microsoft/vscode/issues/7829 से संबंधित है

@jrieken बहुत बढ़िया! गिट बैज अग्रभूमि के लिए रंग कुंजी के बारे में क्या?

@equinusocio कोई चिंता नहीं, ऐसा होगा लेकिन कुछ सोच की जरूरत है। यह अक्टूबर के लिए निर्धारित है

@jrieken धन्यवाद!। मुझे कुछ याद आया .. फ़ोल्डर आइकन भी संशोधित/जोड़ा गया रंग प्राप्त करता है? क्या गिट संपादित/संशोधित होने पर फ़ोल्डरों के लिए अलग-अलग आइकन सेट करने के लिए आइकन थीम में जोड़ने के लिए कोई नई कुंजी है?

@jrieken - 1.18 में मुद्दे। मैं अब तक आपके काम के लिए धन्यवाद कहना चाहता हूं। मैंने अभी v1.18 अंदरूनी सूत्रों का परीक्षण किया है। मैंने ऊपर दिए गए धागे को स्किम किया है, इसलिए क्षमा करें यदि आपके पास पहले से ही 1.19 के कार्यों में कुछ है जो मैं नीचे उल्लेख करता हूं उसे संबोधित करने के लिए।

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

2) git.color.added लिए कोई रंग विकल्प नहीं है

3) git.color.ignored लिए कोई रंग विकल्प नहीं है।

4) (गड़बड़) यह "जोड़ी गई" फ़ाइलों को "अनट्रैक" के रूप में मानता है। मैंने एक "जोड़ी" फ़ाइल का निरीक्षण किया, और ऐसा लगता है कि एचटीएमएल में है, ऐसा लगता है कि यह ट्रैक नहीं किया गया है। ( span शीर्षक "अनट्रैक" कहता है और वर्ग monaco-decorations-style-32 , जो "यू" आइकन है)। workbench.colorCustomizations लिए git.color.untracked पर रंग बदलते समय यह स्पष्ट होता है, क्योंकि यह "जोड़ी गई" फ़ाइलों को नियंत्रित करता है।

5) "R" स्थिति का समर्थन करें, "बदला हुआ" या स्थानांतरित करने के लिए, एक "R" बैज जोड़ें, और मिलान git.color.renamed सेटिंग जोड़ें।

धन्यवाद, मैं 1.19 को आज़माने के लिए उत्सुक हूं

@danjjl # 7829 के लिए एक लंबित पीआर है जिसे लागू करने के साथ, git

इसमें एक संभावित समस्या है, यदि सबमॉड्यूल बदल दिया गया है, तो मुझे नहीं पता कि क्या यह (सबमॉड्यूल की जड़ वाली निर्देशिका) को मुख्य गिट रिपॉजिटरी में निर्देशिका स्थिति के रंग के रूप में माना जाएगा, या एक अलग निहित फाइलों के आधार पर रंग।

यानी, मुझे नहीं पता कि सबमॉड्यूल निर्देशिका का रंग मूल निर्देशिका में या सबमॉड्यूल में 'गिट स्थिति' पर आधारित होगा। हो सकता है कि इससे कोई फर्क नहीं पड़ता।

@jrieken क्या आपके पास इस मुद्दे पर चर्चा करने के लिए एक सुस्त समूह है, या कहीं और है? मैं मदद कर सकता हूँ :) मैं मास्टर शाखा से वर्तमान परिवर्तनों को खींचने, विकसित करने और डीबग करने में सक्षम था। मैंने "यू" के रूप में दिखाई देने वाली "जोड़ी" फ़ाइलों को ठीक किया, और यहां तक ​​​​कि "मंचन" समर्थन भी जोड़ा। चूंकि यह प्रोजेक्ट में मेरा पहला मौका था, इसलिए मैं इसे वापस मास्टर पर रीसेट कर रहा हूं और इसे फिर से कर रहा हूं। मैंने कई बदलाव किए हैं, और मैं एक सर्जन की तरह जाना चाहता हूं, न कि परमाणु के रूप में।

raw.x + raw.y पर चेक और उसके बाद raw.x फिर raw.y पर चेक क्यों हैं? ऐसा लगता है कि यह 2 अलग-अलग स्थितियों से मेल खाता है।

ADDED / INDEX_ADDED , MODIFIED / INDEX_MODIFIED , और कुछ अन्य के लिए 2 स्थिति स्थिरांक क्यों हैं? मैं सभी अलग-अलग गिट स्थितियों को समझता हूं, लेकिन अंतिम उपयोगकर्ता के लिए इसे संभालना समझ में आता है, गिट स्थितियों का नामकरण नहीं। ADDED का उपयोग आपके पास अब UNTRACKED रूप में किया जाना चाहिए और फिर git.color.added का सेटिंग कोड होना चाहिए। मुझे लगता है कि इनमें से कुछ स्थिति स्थिरांक दोहराए गए हैं और इन्हें सरल और साफ किया जाना चाहिए।

का एक Git स्थिति _M <- अंडरस्कोर = अंतरिक्ष / कुछ भी नहीं, से मेल खाएंगे raw.y और तुम लोगों के रूप में यह राशि INDEX_MODIFIED । यह गलत है, वह स्थिति जहां x = कुछ नहीं और y = M अर्थ staged ।

किसी कारण से, कभी-कभी बेतरतीब ढंग से, ऐसा लगता है कि यह परिवर्तनों को प्रतिबिंबित नहीं करता है। साथ ही, ऐसा लगता है कि गिट स्थिति परिवर्तन पुनरावर्ती रूप से ऊपर से नीचे तक स्कैन कर रहे हैं। यदि आपके पास एक बड़ी परियोजना है, तो आप अपने फ़ोल्डर्स/फ़ाइलों के माध्यम से "अनदेखा" स्थिति को टपकते हुए देख सकते हैं। इसे तेज करने के लिए, गहराई से नेविगेट करना, उस निर्देशिका के लिए इसे किक करना और उन्हें ग्रे आउट करना प्रतीत होता है। -- क्या यह प्रक्रिया सिस्टम/VSCode को बहुत धीमा कर रही है? क्या किसी ने इसे बेंचमार्क किया है? माता-पिता को अनदेखा किए जाने पर वास्तव में प्रत्येक फ़ाइल/फ़ोल्डर के माध्यम से नीचे जाने की आवश्यकता नहीं होती है। बच्चों को उनके माता-पिता से उनकी स्थिति मिलनी चाहिए। -- यदि आपके पास 5,000 फ़ाइलें ignored लेकिन सभी 2 निर्देशिकाओं में हैं (यानी: node_modules, विक्रेता) तो हमें 5,000 फ़ाइलों को संसाधित नहीं करना चाहिए, केवल 2 निर्देशिकाएं जो उनके बच्चों की उपस्थिति को नियंत्रित करती हैं।

मैं आज बाद में अपने परिवर्तन फिर से करूंगा और एक पीआर जारी करूंगा।

आपके काम के लिए फिर से धन्यवाद। मैं सिर्फ आपकी मदद करने की बजाय आपकी मदद करने की कोशिश कर रहा हूं, क्योंकि मैं वास्तव में ऐसा कर सकता हूं योग्य

@WadeShuler मैं उनमें से कुछ का उत्तर दे सकता हूं। मैं मान रहा हूँ कि आप Repository.updateModelState() में repository.ts में देख रहे हैं। यदि आप raw.x + raw.y चेक नोट करते हैं, तो वे सभी वापस आ जाते हैं, इसलिए आप वास्तव में raw.x और raw.y नहीं कर सकते। कारण raw.x और raw.y अलग-अलग हैं, और INDEX_* का कारण यह है कि प्रत्येक INDEX_* का मंचन किया जाता है, बस जो मंचन किया जाता है वह बदल जाता है। यदि आप INDEX को STAGE से प्रतिस्थापित करते हैं तो मुझे लगता है कि यह अधिक समझ में आता है, हालांकि वे जिस तर्क का उपयोग कर रहे हैं वह तकनीकी रूप से सही है। देखें https://git-scm.com/docs/git-status , विशेष रूप से तालिका "XY अर्थ"
(संपादित करें: वाह, स्वरूपण खराब था। बस मूल पर जाएं। यह लाल रंग में लगभग आधा रास्ता नीचे की एक तालिका है।)
यह स्पष्ट रूप से वे इस पूरी चीज़ के लिए उपयोग कर रहे हैं।

और मुझे लगता है कि आप _M मामले में गलत हैं, जो संशोधित, इंडेक्स अनमोडिफाइड (यानी मंचित नहीं) से मेल खाएगा। बेशक आप इस कोड का डुप्लिकेट कहीं और नहीं देख रहे हैं।

@petkahl धन्यवाद, मैं Git Status Short Format से परिचित हूं। जब तक यह आधिकारिक रूप से हल नहीं हो जाता, तब तक मैंने इसे बुनियादी Git स्थितियों को जोड़ने के लिए अपने vsc git स्टेटस को ठीक करने के लिए हफ्तों पहले इसका इस्तेमाल किया था।

_M (अंडरस्कोर = स्पेस) प्राप्त करना संभव है (किसी तरह)। मुझे यकीन नहीं है कि कैसे, क्यों, कब .. मुझे यह आज पहले मिला (साथ ही कुछ हफ्ते पहले जब मैं अपने जिस्ट पर काम कर रहा था):

➜  git-test git:(master) ✗ git status -s --ignored                                  
 M added.php       <-- notice space before M
A  test2.php
?? untracked.php
!! vendor/

अब कुछ घंटों बाद, मैं इसे चलाता हूं और "ए" प्राप्त करता हूं। मुझे नहीं पता कि तब से क्या बदल गया है..

➜  git-test git:(master) ✗ git status -s --ignored         
A  added.php
A  test2.php
?? untracked.php
!! vendor/

जब मैं अपने सार के लिए शोध कर रहा था, मुझे लगता है कि मैंने निष्कर्ष निकाला है कि मंचन के लिए "ए_" और "_एम" प्राप्त करना संभव है। मुझे ऐसी साइट भी मिली थी जिसने गिट-स्टेटस दस्तावेज़ों की तुलना में स्थिति को बहुत स्पष्ट रूप से तोड़ दिया था, मैं इसे फिर से नहीं ढूंढ सकता।

आप चरणबद्ध और संशोधित फ़ाइल के लिए "AM" भी प्राप्त कर सकते हैं। एक नई खाली फ़ाइल बनाएं, इसे जोड़ें (इसे चरणबद्ध करें), फ़ाइल को संपादित करें और सहेजें, स्थिति जांचें:

➜  git-test git:(master) ✗ touch test.php         <--- create file
➜  git-test git:(master) ✗ git add test.php       <--- add/stage
➜  git-test git:(master) ✗ nano test.php          <--- edit, add some text, save
➜  git-test git:(master) ✗ git status -s --ignored
A  added.php
AM test.php              <--- modified after staging
A  test2.php
?? untracked.php
!! vendor/

तो क्या इसमें 2 बैज होने चाहिए, "[S][M]" ? मैं यह जानना चाहूंगा कि मैंने किन फाइलों का मंचन किया है। चेरी चुनते समय यह उपयोगी है। यह देखना अभी भी उपयोगी हो सकता है कि क्या आपने किसी चरणबद्ध फ़ाइल को संशोधित किया है। इसमें कम से कम स्टेज्ड बैज होना चाहिए।

@WadeShuler मैं प्रतिबद्ध और संशोधित करके लगातार _M प्राप्त कर सकता हूं। जिसका अर्थ है कि यह इंडेक्स में अपरिवर्तित (_=स्पेस) है, लेकिन वर्किंग ट्री में संशोधित है।
इसलिए:
फ़ाइल बनाएँ: ??
गिट फ़ाइल ए_ जोड़ें
गिट प्रतिबद्ध (स्थिति में नहीं, बल्कि अंतरिक्ष स्थान के बराबर)
फ़ाइल को संशोधित करें: _M
git फ़ाइल जोड़ें M_
इसे फिर से संशोधित करें: MM

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

मैंने Staged समर्थन जोड़ा है। आप यहां बदलाव देख सकते हैं: WadeShuler/ vscode:gitstatus-fix । मैंने गिट स्टेटस टैब पर कुछ बैज को थोड़ा बड़ा करके थोड़ा बेहतर बना दिया।

किसी कारण से, इसने vendor निर्देशिका के कालेपन/अनदेखा को हटा दिया, लेकिन इसके अंदर की सामग्री अभी भी धूसर हो गई है और इसे अनदेखा कर दिया गया है। मुझे समझ नहीं आता कि मेरे साधारण संशोधन ने vendor निर्देशिका को धूसर करना क्यों बंद कर दिया? मैंने अभी जो किया उसके साथ यही एकमात्र मुद्दा है, और मैंने अभी तक पीआर जारी क्यों नहीं किया ...

यदि चरणबद्ध फ़ाइल रंग/आइकन शामिल होने जा रहे हैं, तो यह निश्चित रूप से वैकल्पिक होना चाहिए। निजी तौर पर, मैं अपनी सूची में मूल नए/संशोधित रंग की तुलना में एक अलग रंग के रूप में मंचन नहीं देखूंगा।

एक बार जब आप मंचन को शामिल करना शुरू कर देते हैं तो यह तेजी से जटिल हो सकता है क्योंकि इसमें नए/नए-चरणबद्ध/संशोधित/संशोधित-चरणबद्ध/संशोधित-चरणबद्ध-संशोधित/नए-चरणबद्ध-संशोधित, आदि के सभी संयोजनों और क्रमपरिवर्तन को शामिल करने की संभावना है। , जो रंगों और भ्रम की एक विशाल मैट्रिक्स को जन्म देगा।

मैं वोट देता हूं कि हम मामले को अधिक जटिल नहीं बनाते हैं।

मैं @dseipp से सहमत हूं। यही कारण है कि जब मैंने इसे बनाया था, तब मैंने अपने प्रारंभिक हैक में चरणबद्ध फ़ाइलों के समर्थन को मर्ज नहीं किया था, क्योंकि मैंने देखा कि मंचित फ़ाइलों के रंगीन होने का कोई उपयोग नहीं है।

रंग हाइलाइटिंग का उद्देश्य यह है कि यह मुझे फ़ाइल एक्सप्लोरर में नई/संशोधित फ़ाइलों को एक नज़र में खोजने की अनुमति देता है। अगर मैं कुछ फाइलों को मंचित करता हूं, तो यह आमतौर पर कमिटमेंट से पहले होता है या यदि मैं उनके साथ अन्यथा कर रहा हूं, तो मेरे पास उनके लिए सामान्य रूप से रंगीन होने का कोई उपयोग नहीं है।

यदि हम हर संभव प्रकार की git स्थिति के लिए रंग जोड़ते हैं, तो फ़ाइल एक्सप्लोरर क्रिसमस ट्री की तरह दिखने लगेगा और यह देखना बहुत भ्रमित करने वाला होगा कि वास्तव में क्या चल रहा है।

@jrieken एक और बग रिपोर्ट, नवीनतम अंदरूनी सूत्रों पर होती है:

• VSCode संस्करण: कोड - अंदरूनी सूत्र 1.18.0-अंदरूनी सूत्र (82dcf9835265cd0a45ec135587ae2a82673f1c8f, 2017-10-20T04:24:25.632Z)
• ओएस संस्करण: विंडोज_एनटी x64 10.0.15063

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

@dseipp यह वैकल्पिक हो सकता है। हालाँकि, जब तक आप फ़ाइलों को मंचित नहीं करते हैं, तब तक आप "मंचित" रंग कभी नहीं देख पाएंगे ... इसलिए यह 99% बार भी नहीं देखा जाता है, और वास्तव में किसी को परेशान नहीं करना चाहिए।

@ karabaja4 मैं असहमत हूं कि इसका कोई उपयोग नहीं है। आपने यह बात कही, कि आप कभी भी स्टेजिंग कलरिंग का उपयोग / नोटिस / आवश्यकता नहीं करते हैं ...

रंग हाइलाइटिंग का उद्देश्य यह है कि यह मुझे फ़ाइल एक्सप्लोरर में नई/संशोधित फ़ाइलों को एक नज़र में खोजने की अनुमति देता है। अगर मैं कुछ फाइलों को मंचित करता हूं, तो यह आमतौर पर कमिटमेंट से पहले होता है या यदि मैं उनके साथ अन्यथा कर रहा हूं, तो मेरे पास उनके लिए सामान्य रूप से रंगीन होने का कोई उपयोग नहीं है।

तो अगर इस सुविधा को जोड़ा भी जाता है, तो यह आपको परेशान नहीं करेगा...

चरणबद्ध फ़ाइलों को देखने में सक्षम होने से चेरी को आपके द्वारा किए जाने वाले कार्यों को चुनने में मदद मिलती है। अगर हमारे पास १०० फाइलें बदली हुई हैं, तो उन्हें समूहबद्ध करने की जरूरत है, हम फाइल ट्री पर परिमार्जन कर सकते हैं और आसानी से देख सकते हैं कि क्या मंचन किया गया है, और जिन्हें हमने याद किया है, उन्हें यह सुनिश्चित करने के लिए पकड़ लें कि वे एक ही प्रतिबद्धता में हैं।

आपने कितनी बार मुट्ठी भर फाइलें की हैं, फिर महसूस किया कि आपने एक को याद किया है? फिर आपके पास 2 विकल्प हैं, छूटी हुई फ़ाइलों को शामिल करने के लिए अपनी अंतिम प्रतिबद्धता को संशोधित करें, या एक नई प्रतिबद्धता बनाएं। टीमों के साथ काम करते समय, उन्हें एक ही प्रतिबद्धता में रखना अधिक साफ और कम भ्रमित करने वाला होता है।

चरणबद्ध बिंदु पर, इससे कोई फर्क नहीं पड़ता कि फ़ाइल को जोड़ा गया है, संशोधित किया गया है, या कुछ और..

ईमानदार होने के लिए, जिस तरह से विजुअल स्टूडियो कोड गिट को संभालता है, वह छोटा और छोटा है। बड़े फ़ाइल पेड़, आप सचमुच फाइलों / फ़ोल्डरों के माध्यम से रंग टपकता देख सकते हैं। यह बेतरतीब ढंग से रंग छोड़ देता है ...

मुझे लगता है कि पूरे गिट समर्थन की जरूरत खरोंच से फिर से लिखी गई है।

मैं मंचित फ़ाइलों को रंगने के लिए अपना समर्थन देना चाहूंगा (वैकल्पिक तब तक ठीक है जब तक मैं इसे सक्षम कर सकता हूं)।

यहां मेरा वर्कफ़्लो है: मैं कुछ फीचर/बगफिक्स पर काम करना शुरू करता हूं, इसे "ओकेश" स्थिति में बनाता हूं, जिसका अर्थ है कि कोड कम या ज्यादा काम करता है लेकिन कुछ पॉलिश/ट्वीक्स/क्लीनअप या रिफैक्टरिंग की आवश्यकता होती है। उस समय मैं अपने परिवर्तनों का मंचन करता हूं। फिर सफाई और रिफैक्टरिंग करें। यदि रिफैक्टरिंग विफल हो जाती है या बहुत गड़बड़ हो जाती है, तो मैं वापस चरणबद्ध स्थिति में वापस आ जाता हूं।

यह देखने की क्षमता होना कि मैं वर्तमान में किन फाइलों को संशोधित कर रहा हूं, बहुत फायदेमंद है, और जब मैं परिवर्तनों को चरणबद्ध करता हूं तो मैं उस सारी जानकारी को खोना नहीं चाहता और बिना किसी रंग के सादे पेड़ तक पहुंचना चाहता हूं।

@vvs मैं मंचित फाइलों के रंग न खोने के बारे में सहमत हूं। रंग प्रतिबद्ध होने तक बने रहना चाहिए। मैं सिर्फ यह पसंद करूंगा कि मंचित रंग नए/संशोधित रंगों को बनाए रखें और अतिरिक्त मंचित रंग वैकल्पिक रहें।

हो सकता है कि स्टेज्ड एक ही रंग रख सकता है लेकिन इसे कंट्रास्ट देने के लिए बस किसी तरह का हाइलाइट या बोल्ड जोड़ें।

पूर्व कला को देखना मददगार हो सकता है .. चरणबद्ध संकेतक देखना याद नहीं है, लेकिन शायद समय बदल गया है

क्या फाइल एक्सप्लोरर में संशोधित/अस्थिर/... फाइलों के लिए आइकन वास्तव में जरूरी हैं? मुझे ध्यान में कुछ समस्या है, इसलिए रंग और चिह्न मुझे बहुत आसानी से विचलित कर देते हैं। क्या यह वैकल्पिक और डिफ़ॉल्ट रूप से अक्षम नहीं हो सकता था? क्या मैं अकेला हूँ जो उनसे विचलित होता है?

उपयोगकर्ता अनुभव के दृष्टिकोण से, कभी-कभी कम अधिक होता है, और कई लोग इन चीजों को अक्षम करने के विकल्प की तलाश में परेशान नहीं होंगे और पीड़ित रहेंगे या संपादकों को भी बदल देंगे। मुझे लगता है कि इसके बारे में सोचना और यह तय करना एक अच्छी बात होगी कि क्या यह वास्तव में एक बेहतर UX के लिए आवश्यक है (जो मुझे लगता है कि इन आइकन का बिंदु है।)

* मेरे पास इस मुद्दे पर हर टिप्पणी को पढ़ने का समय नहीं था, इसलिए कृपया मुझे बताएं कि क्या मैं कुछ ऐसा पूछ रहा हूं जिस पर पहले ही चर्चा हो चुकी है और मैं अपना समय जल्द से जल्द सब कुछ पढ़ने के लिए लूंगा ताकि मैं इसके अनुरूप हो सकूं क्या कहा गया था। धन्यवाद।

मुझे लगता है कि इसके बारे में सोचना और यह तय करना एक अच्छी बात होगी कि क्या यह वास्तव में एक बेहतर UX के लिए आवश्यक है (जो मुझे लगता है कि इन आइकन का बिंदु है।)

https://github.com/Microsoft/vscode/issues/178#issuecomment -336960308 यही कारण है कि हमारे पास डिफ़ॉल्ट रूप से रंग और बैज हैं। सहमत हूं कि यह यूआई को थोड़ा अधिक अव्यवस्थित बनाता है, उन सुझावों के लिए खुला है जो सुलभ/समावेशी हैं लेकिन साथ ही स्लीक और साफ भी हैं।

@jrieken धन्यवाद! क्या आप कृपया मुझे उस प्रतिबद्धता के बारे में बता सकते हैं जिसने बैज पेश किया था? मैं कुछ ऐसा खोजने की कोशिश करूंगा जो दोनों मुद्दों के लिए फायदेमंद हो (रंग देखने में कठिनाई हो रही हो या यह नहीं पता कि यह किस लिए है, और व्याकुलता की समस्या है)।

@jrieken चलिए Xcode से एक पेज लेते हैं और बैज को

नए लोगों को संकेत देने के लिए बैज उपयोगी होते हैं, लेकिन रंग सीखने के बाद यह अव्यवस्थित हो जाता है।

अतिरिक्त बाइक-शेडिंग के लिए, मैं git.color.ignored (_बाएं_ ऊपर) में रंगीन बैज पसंद करता हूं क्योंकि उनका दृश्य महत्व समान है। यानी फीके पड़ जाते हैं लेकिन अगर मुझे आपकी जरूरत हो तो गायब न हों।

अगर हम सूक्ष्म बैज लागू करते हैं, तो निरंतरता के लिए स्रोत नियंत्रण साइडबार बैज को अपडेट किया जाना चाहिए।

बैज चर्चा किसी भी दिशा में जाती है, क्या बैज डिज़ाइन कम से कम गिट साइडबार में उन लोगों के अनुरूप हो सकता है? एक्सप्लोरर साइडबार के लिए एक डिज़ाइन और गिट साइडबार के लिए एक अलग डिज़ाइन होना थोड़ा असंबद्ध लगता है।

मुझे @jayjun का एकल पत्र सुझाव पसंद है। मैं आज इसे आजमाऊंगा।

अगर हम सूक्ष्म बैज लागू करते हैं, तो निरंतरता के लिए स्रोत नियंत्रण साइडबार बैज को अपडेट किया जाना चाहिए।

ऐसा होगा, यह अक्टूबर के लिए मेरी योजना पर है।

मैंने नवीनतम स्क्रीन शॉट्स और रंग नामों के साथ https://github.com/Microsoft/vscode/issues/178#issuecomment -335511695 अपडेट किया है। साथ ही, कल के अंदरूनी सूत्र के साथ, हम SCM व्यूलेट में वही बैज दिखाएंगे, लेकिन कोई रंगीन लेबल नहीं। इस तरह

यह बेहतर दिख रहा है

क्या बैज U होना चाहिए? मुझे लगता है कि समुदाय को इसमें शामिल होना चाहिए। U मुझे सबसे पहले updated सोचने पर untracked है, लेकिन मुझे लगता है कि A अधिक उपयुक्त है, खासकर उन लोगों के लिए जो अंतर्निहित शर्तों से परिचित नहीं हैं, कि U ट्रैक नहीं किया गया है। - मैं व्यक्तिगत रूप से जोड़े जाने के लिए A लिए वोट करता हूं। जैसा कि, इसे आपके भंडार में जोड़ा गया है।

फिर staged लिए समर्थन (सेटिंग्स के माध्यम से वैकल्पिक) और यह बहुत करीब है

@WadeShuler , ट्रैक न किए गए प्रश्न चिह्न (?) के बारे में कैसे? मुझे ए पसंद नहीं है क्योंकि इसका गिट के लिए एक अलग अर्थ है, कम से कम मेरे दिमाग में।

संपादित करें: लेकिन मैं मानता हूं कि यू भ्रमित हो सकता है।

मुझे लगता है कि मैं एक प्रश्न चिह्न के साथ ठीक रहूंगा। हालांकि, मुझे नहीं लगता कि कोड
केवल गिट का समर्थन करता है, है ना? मुझे नहीं लगता कि हमें इसे दृष्टि से देखना चाहिए
संपादक "गिट" के रूप में, लेकिन सामान्य रूप से अधिक संस्करण नियंत्रण।

जो भी हो, मुझे वास्तव में "यू" पसंद नहीं है lol

मंगलवार, 24 अक्टूबर, 2017 दोपहर 2:20 बजे पीटर काहले नोटिफिकेशन @github.com
लिखा था:

@WadeShuler https://github.com/wadeshuler , प्रश्नवाचक चिन्ह के बारे में कैसे?
(?) अनट्रैक के लिए? मुझे ए पसंद नहीं है क्योंकि इसका एक अलग अर्थ है
कम से कम मेरे दिमाग में git की तुलना में यहाँ है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/Microsoft/vscode/issues/178#issuecomment-339084261 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AJHVkJJNzw89umFiPB0BmgQAZYJNXTHzks5svip7gaJpZM4GlYyH
.

पर्याप्त रूप से, यह अज्ञेयवादी होना चाहिए। लेकिन "संस्करण नियंत्रण प्रणाली के लिए अज्ञात" एक के रूप में? मेरी समझ मे आ रहा है। लेकिन एन (नए के लिए) भी काम कर सकता है, और मैं उस पर किसी भी अधिभार के बारे में नहीं सोच सकता, हालांकि मुझे यकीन है कि कोई और करेगा।

हाँ, @jrieken , आपके प्रयासों की बहुत सराहना की जाती है! वास्तव में अच्छा लग रहा है! सूक्ष्म बैज एक प्लस हैं।

मैं यू को किसी और चीज़ में बदलने के लिए @WadeShuler और @petkahl के साथ हूं । 'एन' या '?' काम। हालाँकि मैं N की ओर झुक रहा हूँ, तब यह 'N'new और 'M'odified होगा।

इसे एक साथ देखने के लिए उत्साहित!

क्या workbench.colorCustomizations.git.color.ignored सबके लिए काम कर रहा है?
मैं 1.18.0-insider आज आखिरी बार अपडेट किया गया और अनदेखा रंग अभी भी उठाया नहीं गया है। साथ ही, ऐसा लगता है कि "_deleted_" और "_conflict_" अभी काम नहीं कर रहे हैं... शायद कल के अपडेट के साथ,
लेकिन जो मुझे परेशान कर रहा है वह है अनदेखा रंग। फ़ाइल का नाम एक संस्करणित - अनमॉडिफाइड फ़ाइल के समान दिखता है, जिसका अर्थ है कि इस पर कोई विशेष रंग लागू नहीं किया गया है।
नोट: स्क्रीनशॉट में रेपो में कोई भी ट्रैक की गई फाइल नहीं है। सभी फाइलें अनट्रैक हैं। एक बार जब मैं "_shared.module.ts_" को .gitignore से हटा देता हूं, तो यह भूरे रंग में दिखाई देता है (मेरी ट्रैक न की गई रंग सेटिंग)।

क्या बैज यू होना चाहिए? मुझे लगता है कि समुदाय को इसमें शामिल होना चाहिए। यू मुझे पहले सोचने पर मजबूर करता है। मुझे पता है कि यह गिट शब्दावली में ट्रैक नहीं किया गया है

हम पहले 'यू' का उपयोग कर रहे हैं, यह चर्चा करने के लिए सही मुद्दा नहीं है कि क्या बेहतर है, लेकिन मुझे लगता है कि गिट उपयोगकर्ता शब्दावली जानते हैं और अन्य एससीएम प्रदाताओं के लिए अन्य अक्षरों/आइकनों का उपयोग/उपयोग किया जा सकता है (और आज यही मामला है)।

यह सुविधा नहीं जोड़ी गई है, और मैं इस थ्रेड में तब से सक्रिय हूं
यह आगे बढ़ने लगा। मैंने शुरू से ही "यू" बैज का उल्लेख किया है।

यह धागा पूरी सुविधा को विकसित करने और इस्त्री करने के बारे में है, क्योंकि
यह नया है। यदि फ़ॉन्ट रंग, बैज शैली और बैज रंग सभी स्वीकार्य हैं
इस सूत्र में चर्चा करने के लिए, तो पत्र भी हैं।

तो इस धागे के बाहर और कहाँ, हम "U" का उपयोग कर रहे हैं?

तो इस धागे के बाहर और कहाँ, हम "U" का उपयोग कर रहे हैं?

स्थिर, अंदरूनी नहीं, और एससीएम व्यूलेट को गिट के साथ जांचें। यह एक यू का उपयोग करता है यू के लिए ntracked फ़ाइलें।

@WadeShuler @jrieken वर्तमान SCM व्यूलेट (1.17.2) ग्रे U के साथ _untracked file_ और हरे A के साथ _added file_ को चिह्नित करता है। git status ANSI हरे रंग में _added (मंचित) फ़ाइलें_ दिखाता है।

तो मैं एक _untracked file_ के लिए हरे U के साथ भ्रम को समझता हूं। मैं भी मेरी आँखों के साथ हरे रंग एक रों हरी यू एस मिश्रण से चोट पहुँचाने का पूर्वानुमान।

एटम रंग ट्रैक नहीं किए गए और नई फाइलों को हरे रंग के रूप में मंचित करते हैं, और एक्सकोड ने फाइलों को ए के रूप में जोड़ा है, जब तक कि यह एक नई फाइल है। दोनों ने मुझे कभी परेशान नहीं किया (लेकिन एक हरा यू करता है)।

तो मैं अनट्रैक किए गए _and_ मंचित नई फ़ाइलों के लिए हरे A s का उपयोग करने के लिए तैयार हूं।

आइए 'यू' बनाम 'ए' बनाम '?' जारी रखें https://github.com/Microsoft/vscode/issues/36912 में चर्चा

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

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

क्या यह उत्पाद छोड़ दिया गया है? जैसा लगता है।

वर्तमान में, list.activeSelectionForeground git स्टेटस स्टाइलिंग पर पूर्वता लेता प्रतीत होता है, इसलिए git स्टेटस रंग चयनित फ़ाइल को नहीं देखा जा सकता है। मुझे यह जानकारी उपयोगी लगती है, यहाँ तक कि वर्तमान में चयनित फ़ाइल पर भी। explorer.decorations.colors सत्य होने पर किसी भी मौके पर गिट स्टेटस स्टाइल प्राथमिकता ले सकता है?
यह व्यवहार अंदरूनी सूत्रों 1.18 8dfa696 पर देखा गया था।

वर्तमान में, list.activeSelectionForeground गिट स्थिति स्टाइल पर प्राथमिकता लेता प्रतीत होता है, इसलिए गिट स्थिति रंग चयनित फ़ाइल को नहीं देखा जा सकता है।

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

बीटीडब्ल्यू, खुली फाइलों की सूची के साथ एक ही समस्या, जब आप वहां फ़ाइल पर क्लिक करते हैं, तो गिट स्थिति रंग को तटस्थ चयन रंग से बदल दिया जाता है।

बीटीडब्ल्यू, खुली फाइलों की सूची के साथ एक ही समस्या, जब आप वहां फ़ाइल पर क्लिक करते हैं, तो गिट स्थिति रंग को तटस्थ चयन रंग से बदल दिया जाता है।

खैर, यह उद्देश्य पर किया गया था क्योंकि चयन-अग्रभूमि रंग अक्सर सजावट के रंगों के साथ संघर्ष करता है। अधिक रंग जोड़ना, जैसे git.untrackedSelectedForeground और git.untrackedFocusedForeground हमें बहुत आकर्षक नहीं लगा। इसलिए जब कोई आइटम चुना जाता है और फोकस होता है तो हम चयन रंग को जीतने देते हैं।

ऐसा लगता है कि परमाणु को इससे कोई समस्या नहीं है ....

नई सेटिंग्स की कोई आवश्यकता नहीं है... यदि चयनित आइटम पृष्ठभूमि रंग में हस्तक्षेप करता है, तो थीम समायोजित करने के लिए अपडेट हो जाएंगी। जो लोग ऐसा करने में विफल रहते हैं, समुदाय उन विषयों का उपयोग नहीं करने का निर्णय लेगा।

मैंने जाँच नहीं की है, लेकिन मुझे आशा है कि "बैज" (यानी: U, M), अभी भी svg फ़ाइलें नहीं हैं। वे केवल कच्चे पाठ होने चाहिए जिन्हें स्टाइल/रंगीन किया जा सकता है।

ईमानदारी से, VSCode को इन चीजों के लिए क्लंकी कॉन्फिग सेटिंग्स के बजाय स्टाइलशीट के साथ जाना चाहिए था। इसने एक सरल प्रक्रिया को जटिल बना दिया।

@WadeShuler चयन और फोकस है और क्योंकि मुझे आपके स्क्रीन शॉट में एक संपादक कर्सर दिखाई देता है, मेरा मानना ​​​​है कि आपका आइटम केवल चयनित है, केंद्रित नहीं है। वास्तव में मुझे एटम में चयनित और केंद्रित के बीच कोई अंतर नहीं दिख रहा है। वीएस कोड में ऐसा है

चयनित लेकिन केंद्रित नहीं

चयनित और केंद्रित

@jrieken मैंने दोबारा जांच की है, और मेरे परमाणु में, चयनित बनाम केंद्रित एक ही परिणाम उत्पन्न करते हैं। यह बाईं फ़ाइल एक्सप्लोरर विंडो पर yellow फ़ॉन्ट रंग कभी नहीं खोता है। आपके दूसरे स्क्रीनशॉट में, red रंग test.foo से खो गया है, जो कि मुद्दा है।

मैंने डिफ़ॉल्ट डार्क और लाइट एटम थीम के साथ-साथ लगभग 3 अन्य थीम आज़माई हैं। मेरा डिफ़ॉल्ट (जैसा कि आप मेरे एसएस में देखते हैं) सेती (यूआई और थीम दोनों) है। मैं फ़ाइल एक्सप्लोरर से yellow रंग छोड़ने के लिए एटम को प्राप्त करने में असमर्थ हूं, चाहे मैं कुछ भी करूं। परमाणु संस्करण 1.21.2।

गिने चुने

चयनित और केंद्रित

बॉक्स से बाहर, वीएस कोड को चयनित या केंद्रित राज्यों की परवाह किए बिना गिट स्थिति रंग को संरक्षित करना चाहिए।

यदि आपकी समस्या विषयवस्तु है, तो यह आपकी समस्या नहीं है। यह थीम डेवलपर्स की जिम्मेदारी है कि वे अपडेट करें और समायोजित करें।

एक तरफ ध्यान दें: मैंने नवीनतम अंदरूनी सूत्रों की जांच नहीं की है या कोड नहीं देखा है, लेकिन git ignored फ़ाइलों को opacity उपयोग करना चाहिए, फ़ॉन्ट रंग नहीं, इसलिए यह हमेशा x नियमित फ़ाइलों की तुलना में गहरा, उनके रंग की परवाह किए बिना।

@WadeShuler थीम प्रबंधकों को अपने व्यवसाय को कैसे संभालना चाहिए, इस पर आपकी प्रतिक्रिया के लिए धन्यवाद! VSCode टीम उन्हें ऐसा करने में मदद करने के लिए API प्रदान करने की हिम्मत कैसे हुई? वे आलसी डेवलपर्स!

@fernandofleury थीम प्रबंधकों को इसे प्रबंधित करने के लिए एक एपीआई प्रदान नहीं करने के बारे में किसी ने कुछ नहीं कहा। मेरी पोस्ट ने ऐसा कुछ नहीं कहा। तो आपकी भद्दी टिप्पणी, केवल अमान्य और अनुचित है।

@jrieken ने कहा:

खैर, यह उद्देश्य पर किया गया था क्योंकि चयन-अग्रभूमि रंग अक्सर सजावट के रंगों के साथ संघर्ष करता है।

मैंने कहा:

यदि आपकी समस्या विषयवस्तु है, तो यह आपकी समस्या नहीं है। यह थीम डेवलपर्स की जिम्मेदारी है कि वे अपडेट करें और समायोजित करें।

यह मुद्दा अग्रभूमि (वास्तव में, यह एक पृष्ठभूमि रंग है) फ़ाइल/फ़ोल्डर ट्री आइटम (सामान्य, चयनित, केंद्रित), और विभिन्न गिट स्थितियों के लिए फ़ॉन्ट रंग विकल्पों के बीच एक संघर्ष होगा।

यह _would_ थीम डेवलपर्स की जिम्मेदारी होगी। उन्हें पेड़ में वस्तुओं के अग्रभूमि रंग और विभिन्न गिट स्थितियों के लिए फ़ॉन्ट रंग दोनों चुनना चाहिए ताकि वे संघर्ष न करें।

उदाहरण के लिए: एक थीम डेवलपर के पास थीमएक्स है और एक्सप्लोरर फ़ाइल ट्री में आइटम के लिए उसका फ़ॉन्ट रंग yellow । खैर, उसका डिफ़ॉल्ट फ़ॉन्ट रंग डिफ़ॉल्ट yellow गिट स्थिति रंग के साथ संघर्ष करेगा। आप यह नहीं बता पाएंगे कि अब कौन सी फाइलें संशोधित की गई हैं। तो यह थीम डेवलपर्स की जिम्मेदारी होगी! - एक्सप्लोरर फ़ाइल ट्री बनाम गिट स्थितियों के फ़ॉन्ट रंगों में चयनित/चयनित-केंद्रित वस्तुओं के लिए पृष्ठभूमि रंग के लिए भी यही है।

क्या यह अब स्थगित कर दिया गया है?

@IljaDaderko मुझे ऐसा नहीं लगता क्योंकि यह अगले स्थिर संस्करण के आगामी रिलीज नोट v1.18 में दिखाई देता है। सवाल और भी हो सकता है, क्या इसे बंद कर दिया जाएगा या अभी और काम किया जाना बाकी है?

@IljaDaderko VSCode v1.18 पहले से ही बाहर है और इसमें यहां चर्चा किए गए परिवर्तन शामिल हैं।

क्या उपेक्षित फ़ाइल रंगों को v1.18 अद्यतन का भाग माना जाता है? दस्तावेज़ों का कहना है कि gitDecoration.ignoredResourceForeground का उपयोग अनदेखा फ़ाइलों को रंगने के लिए किया जा सकता है, लेकिन अभी तक मैं यह नहीं देख पाया कि इससे कुछ भी प्रभावित होता है। हालांकि संशोधित/अनट्रैक रंग बहुत अच्छा काम करता है। यह स्थिर 1.18.0, windows.

यहाँ वही (अनदेखे रंग के बारे में)। मेरे लिए भी काम नहीं कर रहा है, क्योंकि यह पूरा गिट कार्यान्वयन शुरू हुआ है। अंदरूनी सूत्रों का उपयोग करना।
वह सब जो gitDecoration.ignoredResourceForeground करता है वह रंग से अनदेखी की गई फ़ाइलों को अनदेखा करता है :)

यह मेरे लिए काम कर रहा है और यह शानदार दिखता है।

अंत में यह यहाँ है

@arxpoetica मुझे यही मिलता है:

यह कुछ के लिए कैसे काम कर सकता है और दूसरों के लिए नहीं, मुझे समझ नहीं आता। यह सिर्फ एक सेटिंग है gitDecoration.ignoredResourceForeground
क्या मैं अकेला हूं जिसके लिए यह काम नहीं करता है? सच में कोई और नहीं? :) ओह, और @Shurelia
क्या किसी और ने (हम, उपयोगकर्ता) वास्तव में यह कहने से पहले कि यह काम करता है, अनदेखा रंग सेट करने का परीक्षण किया है?

ओएस: विंडोज 10 प्रो (1709)
VSCode: 1.19.0-अंदरूनी सूत्र (अभी पहले अपडेट किया गया)
मेरे काम के लैपटॉप और होम डेस्कटॉप पर भी ऐसा ही है।

क्या यह अंदरूनी सूत्रों में है? मुझे इसे कैसे प्रयोग में लाना है?

बधाई हो, सब लोग!

@nkkollaw दोनों अंदरूनी और स्थिर (1.18) में

@MrCroft कृपया यहाँ https://github.com/Microsoft/vscode/issues/37857

जैसा कि हमने अपने नवीनतम स्थिर बिल्ड में इस सुविधा को भेज दिया है, इस मुद्दे को बंद करने और लॉक करने का समय आ गया है। कृपया विषय चर्चा और बग रिपोर्ट के लिए नए मुद्दे बनाएं। इस क्षेत्र के आसपास के मुद्दों को file-decorations -लेबल के साथ टैग किया गया है।

हर कोई, शानदार और निरंतर प्रतिक्रिया के लिए धन्यवाद जिसने इस सुविधा को यह बनाया है!

मेरी पिछली टिप्पणी को सारांशित करने और दोहराने के लिए।

कुछ चीजें

• डिफ़ॉल्ट रूप से रंग और बैगडे का संयोजन होता है।
  
  
  
  • इसके साथ आइकन सक्षम/अक्षम करें: "explorer.decorations.badges": true|false
  
  
  • "explorer.decorations.colors": true|false साथ रंगों को सक्षम/अक्षम करें
  
  
• फ़ाइल ट्री, खुले संपादक अनुभाग और SCM व्यूलेट में रंग दिखाई देते हैं
• शुरू करने के लिए तीन रंग हैं। आप उन्हें workbench.colorCustomizations -सेटिंग में कस्टमाइज़ कर सकते हैं। रंग हैं gitDecoration.modifiedResourceForeground ,
  gitDecoration.deletedResourceForeground ,
  gitDecoration.untrackedResourceForeground ,
  gitDecoration.ignoredResourceForeground , और
  gitDecoration.conflictingResourceForeground