Vscode: حالة Git في File Explorer

تم إنشاؤها على ١٩ نوفمبر ٢٠١٥  ·  247تعليقات  ·  مصدر: microsoft/vscode

على غرار ما تقدمه Atom في مستكشف المشروع:

  1. يتم عرض الملفات الجديدة باللون الأخضر.
  2. يتم عرض التعديل باللون الأصفر / البرتقالي.
  3. يتم عرض الملفات التي تم تجاهلها بشكل شفاف.

شكرا

feature-request file-decorations file-explorer git

التعليق الأكثر فائدة

أقوم بإضافة بعض لقطات الشاشة للمساعدة:

افتراضي Atom:

screen shot 2016-12-15 at 12 29 11

الافتراضي VSCode:

screen shot 2017-01-05 at 10 55 23

ال 247 كومينتر

  • 1

سيكون رائعًا إذا تم الكشف عن هذا كامتداد بطريقة ما. أخشى أنه في بعض الحالات ، يمكن أن تكون الشجرة ملوثة قليلاً بالألوان وتبدو مثل شجرة عيد الميلاد. أو إذا لم يكن كذلك ، فلديك على الأقل خيار التبديل بين تشغيله وإيقاف تشغيله.

نعم اوافق. لقد أنشأت مشكلة منفصلة لعرضها في واجهة برمجة تطبيقات الملحق (انظر # 1394).

+1

احب ذلك ايضا تعد علامة التبويب Git سهلة الاستخدام للغاية ولكن هذا لغرض آخر - سيكون الحصول على ألوان مثل Atom أمرًا مجانيًا للغاية لرؤية ما تم تغييره وأين تم تغييره (مع انتشار اللون تلقائيًا إلى أعلى الدليل). ربما تكون هذه هي الميزة التي أفتقدها أكثر من Atom.

عادة ، ليس لديك 10 أو 100s من الملفات المعدلة غير الملتزم بها ، لذلك من غير المحتمل أن تبدو مثل شجرة عيد الميلاد :)

لذلك يبدو أن العلاقات العامة لهذا كانت مغلقة. bpaserojoaomoreno - أي تحديثات عن حالة هذا العمل؟

لا توجد تحديثات...

شكرا جزيلا لاهتمامك بهذه القضية! تم تعيينه حاليا إلى المتأخرات. كل شهر نختار عناصر من التراكم للتخطيط للتكرار الحالي. الرجاء مراجعة https://github.com/Microsoft/vscode/wiki/Issue-Tracking#planning لمزيد من المعلومات.

نظرًا لأننا فريق صغير من المطورين ، لا يوجد سوى العديد من طلبات الميزات والمشكلات التي يمكننا العمل عليها لتحقيق معلم واحد. ومع ذلك ، فإننا نرحب دائمًا بطلبات السحب ويسعدنا قبولها إذا كانت تفي بمعايير الجودة لدينا.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

الرجاء التوقف عن كتابة +1 . إنها تراسل كل شخص في القضية عبر البريد الإلكتروني. استخدم ردود الفعل على الرموز التعبيرية في التعليق الأول.

+1

مرحبًا ، هل لديك أي أخبار عن طلب الميزة هذا؟ لقد بدأت في استخدام vscode اليوم وأنا أحب بالفعل ولكني أفتقد الألوان التي تشير إلى التغييرات
مبروك على عملك

+1

أثناء تنفيذ هذا ، يرجى النظر في 206

أقوم بإضافة بعض لقطات الشاشة للمساعدة:

افتراضي Atom:

screen shot 2016-12-15 at 12 29 11

الافتراضي VSCode:

screen shot 2017-01-05 at 10 55 23

+1

+1

هذا من الممكن ان يكون مفيد جدا.

هناك بالفعل إمكانية تعديل طريقة سرد الملفات والرموز في شجرة الملفات.
هذا التمديد يفعل ذلك
https://github.com/robertohuertasm/vscode-icons.

ومع ذلك ، فإنه لا يقوم بتلوين أسماء الملفات

+1

+1

هل هناك تغييرات؟ تمنعني هذه الميزة من الانتقال من Atom. :(

لقد ابتعدت للتو عن Atom لأن الأداء يبدو أفضل بكثير في VSC. ومع ذلك ، فهذه ميزة فاخرة أفتقدها في VSC.

+1

أعتقد أنه سيكون من الجيد أن يكون هذا كإعداد مضمن (على سبيل المثال git.colorExplorer ) بدلاً من ملحق.

arkon هل هناك أي امتداد من هذا القبيل؟ لم أجد أي شيء.

على الأرجح لا يحتوي مستكشف الملفات على واجهة برمجة تطبيقات لتعديله وفقًا
لبوابة التغييرات. التمديد سيكون جيدًا بالنسبة لي.

في الجمعة ، 3 فبراير 2017 ، 07:52 كتب Rahul [email protected] :

arkon https://github.com/arkon هل يوجد أي امتداد من هذا القبيل؟ لم أستطع
العثور على أي.

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/178#issuecomment-277177373 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AEQJ1eoLm7Sp59a2hE0tIFQnb0Q5cJnSks5rYs6tgaJpZM4GlYyH
.

@ rahulnever2far لا ، لقد كان مجرد اقتراح لأنه تم اقتراحه مسبقًا بأنه يمكن كشفه

قررت مؤخرًا الانتقال إلى VSCode وأنا أفتقد هذه الميزة حقًا

اضف من فضلك. يضيف الاحتكاك إلى الإنتاجية عند محاولة القفز من Atom.

KozhokarAlexbhudgens وآخرون: انقر فوق رمز المنشور الأول لتظهر للمطورين أنك تطلب هذه الميزة. يقومون بفرز المشكلات حسب الإبهام لتحديد طلبات الميزات الأكثر شيوعًا.

كما ترون من هذا النوع من فرز المشكلات ، فإن هذه المشكلة هي الميزة الثالثة الأكثر طلبًا في الوقت الحالي.

ممتاز. لقد جئت مؤخرًا من Atom .. آمل أن أراها في VSCode قريبًا!

آه بفضل joaomoreno!

يرجى أيضًا إضافة نفس حالة التلوين / qit إلى QuickOpen ، وليس فقط FileExplorer.
بهذه الطريقة ، يمكن تصفية الملفات بصريًا بناءً على الملفات التي تم تغييرها بالفعل.

ما يجري مع هذا؟ لماذا لا يدمج المشرفونjoaomoreno PR؟ هل هناك مكون إضافي يمكننا استخدامه الآن؟ هذه مجرد خطة سخيفة

SOSANA لست متأكدًا مما

2824 يفتح الباب لإصلاح هذا ، لذا كن صبوراً أكثر قليلاً.

SOSANA هذه مشكلة وليست علاقات عامة 🤣

+1 ستكون هذه الميزة رائعة للإنتاجية

+1

@ publiclass1 @ hevans90 ، ... (أدخل جميع الأشخاص الآخرين الذين علقوا بـ +1) ... ، من فضلك لا تنشر تعليقات حول مدى رغبتك في هذه الميزة. هذا ما أضافه GitHub إلى ردود أفعال الرموز التعبيرية. فقط اعجب بالتعليق الاصلي بهذه الطريقة يمكنني العودة إلى استخدام إشعارات البريد الإلكتروني الغرض المقصود منها (ابق على اطلاع دائم بالتقدم المحرز في هذه المشكلة ، وليس من يريد ذلك أيضًا في العالم). آسف للجميع أيضا لإرسال رسائل غير مرغوب فيها لك. آمل بصدق أن يتعلم المزيد من الأشخاص كيفية إيقاف مشكلات +1 -ing.

+1

أنا أستخدم PhpStorm لكني أفضل استخدام VS Code في كل شيء. أستخدم حاليًا أكبر عدد ممكن من نوافذ VS Code. هل يمكنك في النهاية الحصول على نظام التلوين هذا كخيار كما أفضل / أعرف ألوان PhpStorm. كمرجع:

أسود - محدث - الملف لم يتغير.
رمادي - محذوف - تمت جدولة الملف للحذف من المستودع.
أزرق - معدل - تم تغيير الملف منذ آخر مزامنة.
أخضر - تمت الإضافة - تمت جدولة الملف للإضافة إلى المستودع.
بني - غير معروف - الملف موجود محليًا ، ولكنه ليس في المستودع ، ولم تتم جدولة إضافته.

إلخ عبر https://www.jetbrains.com/help/phpstorm/2016.3/file-status-highlights.html . يا رفاق الصخور، شكرا لك.

و

  • يتم عرض الملفات التي تم دمجها مع التعارضات باللون الأحمر ،

من الملائم جدًا التمييز بين المتضاربين والمتضاربين

+1 الاضطرار إلى التبديل بين طرق عرض Git <> Explorer أمر غير مثمر للغاية.

من الناحية المثالية ، سيكون من الممكن أيضًا رؤية مجموعة التغييرات كمجموعة في الأعلى حيث لدينا ملفات مفتوحة ، بالإضافة إلى شجرة متداخلة من التغييرات التي تم تصورها حسب اللون (كما هو موضح في abdonrd أعلاه.)

تعالوا يا رفاق ، توقفوا عن +1.

الرجاء وضع ممتاز على أول وظيفة.

لدي حالة استخدام مثيرة للاهتمام وحجة لإنشاء واجهة برمجة تطبيقات عامة تسمح للمكوِّن الإضافي بتلوين الملفات والمجلدات الفردية:

تقادم الملف / المجلد على غرار تقادم Powerup في - أود أن تتلاشى الملفات والمجلدات التي لم يتم لمسها لفترة طويلة (يتم الحكم عليها من خلال سجل git) ، بحيث تكون `` مجموعة العمل '' أكثر تميزًا و أسهل في العثور عليها.

السبب: لدي مجموعة كبيرة من المشاريع الصغيرة (فكر في مجموعة من البرامج النصية للتقرير التحليلي) حيث لن يتم التطرق إلى أكثر من 90٪ من العمل مرة أخرى (لكن لا يمكنني نقل الأشياء القديمة إلى مجلد فرعي لأنها ستؤدي إلى كسر الكثير من روابط تشير إلى الريبو).

إذا كانت هناك نقطة نهاية API لعناصر شجرة التلوين ، فيمكنني كتابة مكون إضافي يقرأ سجل git ويلون كل ملف / مجلد وفقًا لمجموعة من القواعد.

إذن ماذا عن ذلك ، ألا تزال هناك واجهة برمجة تطبيقات تسمح بإنشاء امتداد لهذا ، أم سيتم تنفيذ ذلك كميزة متكاملة؟

أي تحديث على هذا؟

+1

+1

+1

هل يمكنكم يا رفاق التوقف عن إجراء 1+ وإرسال رسائل البريد العشوائي إلى صناديق البريد الخاصة بنا ؟؟؟

لا يخدم أي غرض على الإطلاق.

+1 لعدم إرسال بريد عشوائي xD

protip: تصفية الرسائل من github حيث يساوي الجسم / يطابق / lolwuts "+1"

لا يمكنك إيقاف هؤلاء الناس.

jmbelloteau كما قال fredrikaverpil سابقًا في التعليقات ، يتم فرز مشكلات VSCode حسب عدد الإبهام للتعليق الأصلي. لذا فإن التعليق بـ "1+" بدلاً من إضافة رد فعل على التعليق الأول يعد فعلاً أسلوب غير مرغوب فيه ، حيث إنها ليست الطريقة الصحيحة لتقديم التعليقات ولا ترسل سوى رسائل بريد إلكتروني عديمة الفائدة إلى الجميع. وعلى عكس إضافة رد فعل ، فلن يتم أخذه في الاعتبار.

+1

أنا معتاد على هذا في Webstorm أيضًا: D. ولكن كما أرى ، من المحتمل أن يتم تطوير هذا عاجلاً وليس آجلاً. هذه لقطة شاشة من Webstorm للإلهام (تتبعabdonrd):

screen shot 2017-04-16 at 19 03 16

آه ، تظهر أيضًا الملفات غير المتعقبة باللون الأحمر!

+1

فقط جربت رمز VS لأول مرة اليوم (قادم من Atom) وكانت إحدى الإضافات الأولى التي بحثت عنها هي تمييز "حالة git" في عرض المستكشف. تعد علامة التبويب "التحكم بالمصدر" من تلقاء نفسها أمرًا رائعًا للغاية ، ولكن وجود مجلدات / ملفات مميزة يسمح لي بالانتقال بسرعة إلى المكون الذي أعمل دون الحاجة إلى ترك شجرة الدليل موسعة (مفيدة للغاية لقواعد أكواد FE التي تميل إلى لديها هياكل متداخلة بشكل أعمق).

من الناحية المثالية ، سيكون من الرائع أن يتم تعديل الألوان بشكل فردي.

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

+1

لقد كنت أبحث منذ فترة عن تطبيق جيد لتذكيرني بشرب الماء.
ثم أدركت أنني مشترك في هذا الموضوع.
احتفظوا بزيارات +1 القادمة ، فهم ليسوا عديمي الفائدة بعد الآن 🚰

تضمين التغريدة
لماذا تحتاج منبه لشرب الماء؟ ألا يكفي أن تشرب وأنت عطشان؟

على أي حال ، من فضلك توقف عن + 1 جي. أنا متأكد من أن المطورين على دراية بهذا بالفعل وسيقومون بنشر التحديثات فور وصولها.

pohmelie هذا بديل صالح ، شكرًا لك!

+1

ما هو الخطأ مع هؤلاء +1 الأشخاص؟

فكرة عظيمة ، @ davidhu2000! سيكون من الجيد دعم الألوان السداسية مثل git.ignoredFileColor: '#333333' أيضًا.

توجد قائمة لطيفة بالأنواع والألوان التي يستخدمها JetBrains هنا: https://www.jetbrains.com/help/idea/2017.1/file-status-highlights.html (يمكنك فحص اسم اللون للحصول على ست عشري).

1+ لزيادة الوعي بمدى الحاجة إلى هذه الميزة

السبب الوحيد الذي يجعلني لا أستخدم VS Code. مؤسف جدا :(

هل يعرف أي شخص أين في قاعدة البيانات يمكن للمرء أن يبدأ في تنفيذ هذا؟ أريد أن أحاول طعنة في ذلك.

admosity قدم شخص ما بالفعل طلب سحب العام الماضي وتم رفضه: https://github.com/Microsoft/vscode/pull/8462 .

تم ذكر 2824 كمانع في مكان ما أعلاه ، والذي تم دمجه منذ فترة. أود أن أنظر إلى التغييرات هناك للتأكد من تنفيذها بالطريقة التي يريدها فريق VS.

تضمين التغريدة سألقي نظرة من خلال.

تمنعني ميزة المفتاح الأخير من التبديل إلى رمز vs

عندما يتم دمج هذه الميزة ، سوف أتغير إلى vscode

أنا مشترك في هذه المشكلة لأنني أرغب في معرفة متى يتم إحراز بعض التقدم.
يدرك الجميع مدى رغبة هذه الميزة وهي الآن ثاني أكثر مشكلة تم التصويت عليها :).

إذا كنت تريد حقًا هذه الميزة ، فما عليك سوى التصويت على التعليق الأول ، وتجنب إضافة تعليقات متكررة .

للأشخاص الذين يشعرون أن هذه الميزة ضرورية للتبديل إلى VS Code. أستطيع أن أقول إنها كانت أول ميزة فاتني عند التبديل من Atom ، لكن IMO هذا ثمن صغير يجب دفعه مقابل هذا IDE الرائع.
علاوة على ذلك ، اضطررت الأسبوع الماضي إلى القيام ببعض الأعمال في Atom وقد فاتني حقًا عرض git الخاص بـ VS Code.

waderyan هذا

نعم من فضلك!

+1

+1

+1

لقد صنعت اختراقًا بشعًا للغاية يقوم بتنفيذ هذه الميزة عن طريق تعديل workbench.main.js وحقن CSS بناءً على إخراج git status . إذا كنت لا تمانع في التنقيب في الملفات الداخلية لـ VS Code وقيام VS Code بتنفيذ git status كل 5 ثوانٍ ، ألق نظرة.

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

التحديث 28.6.2017: تم إصلاح الخلل حيث لا يتم تحميل المكون الإضافي عند إعادة فتح المشروع.
تحديث 30.6.2017: تمت إضافة تمييز الدلائل الرئيسية للملفات المعدلة (كما يفعل Atom).
التحديث 1.7.2017: تتم مطابقة الملفات الآن باستخدام ملف كامل أو مسار دليل. قبل هذا التغيير ، تم تمييز الدليل إذا كان له نفس اسم دليل آخر تم تغييره.

أهلا،
لا أستطيع معرفة ما إذا كانت هذه الميزة قد تم تنفيذها أم لا بعد؟
لم أجد أي إعدادات أو امتدادات ولأن هذا تم فتحه منذ ما يقرب من عامين ، فأنا في حيرة من أمري ..

sanjibukai لا تزال المشكلة مفتوحة ، لذا لم يتم تنفيذها بعد. يمكنك استخدام الاختراق الذي أنشأه @ karabaja4 في التعليق فوق تعليقك.

أنا جديد هنا ، لكن هل تحتاج حقًا إلى عامين تقريبًا لإضافة هذه الميزة الواضحة؟
من المدهش أنني لم أسمع أبدًا عن vscode حتى وقت قريب ، ولكن عندما سمعت عنها ، فإن الميزة الرئيسية التي تم الدفاع عنها هي بالتحديد كيف أن vscode جيدة في دمج git. وهي بالفعل جيدة.
يا للأسف أن هذه الميزة لا تزال تفتقر إليها ..
ومع ذلك ، حافظ على فريق العمل الجيد vscode 👍

لا يمكن الاستمرار في التركيز بدون هذه الميزة. في كل مرة علي أن أتذكر الملف الذي أقوم بتحريره.

+1

@ karabaja4 لماذا لا تقوم بعمل

saada سأفعل ذلك إذا اعتقدت أنه يمكن دمج أي من هذه التعليمات البرمجية في VS Code. إن تشغيل عملية في الخلفية git status بالتأكيد ليس طريقة عاقلة لتنفيذ هذه الميزة. يجب كتابة أي كود مناسب ينفذ هذا من البداية ويتم تنفيذه بشكل صحيح داخل إطار عمل مصدر VS Code. هذا كثير من العمل وللأسف في الوقت الحالي ليس لدي الوقت الكافي المتاح. آسف :(

لن يساعد التكديس الأشياء عندما يُقال بالفعل أن المقياس المعلن هو عدد +1 التي يحصل عليها المنشور الأصلي ، وليس في الردود. أيضًا ، نظرًا لأن هذه أداة للمطورين ، فأنا مندهش نوعًا ما من مقدار الاستحقاق وعدم فهم عملية المصدر المفتوح الجارية هنا. طلب الميزة هنا كمسألة مفتوحة. يمكنك إجراء 1+ لها في المنشور وإما أن تفعل ذلك بنفسك (من المفترض أن تعمل مع المشرفين للتأكد من أنها لم تذهب سدى) وتطلب دمجها أو اتركها عند هذا الحد. إذا كانت ميزة حيوية بالنسبة لك ، فاستخدم Atom. أثناء كتابة هذا ، هناك أكثر من 4000 إصدار مفتوح. سيكون عليك التحلي بالصبر.

(أو استخدم @ karabaja4 hack في هذه الأثناء - شكرًا لعملك!)

+1
القيام بذلك لأن مجرد الاستماع للحديث عن devchat والمشكلات المتعلقة بمزيد من التعليقات ستحظى بمزيد من الاهتمام

@ karabaja4 عمل عظيم. طريقة أخرى: ماذا عن تشغيل git status عند التهيئة ، ثم التحديث عندما يتم تشغيل الحدث onFileSave ؟ هل سيكون هذا أكثر كفاءة؟

ربما يمكننا تهيئة طريقة تحديث حالة git.

1+ هذا سيكون مفيدًا جدًا إذا تمت إضافته

Kaijun لست متأكدًا من كيفية تنفيذ ذلك. من أين يأتي حدث onFileSave ؟

إذا كانت تأتي من Code on document save (بافتراض أنني أعرف كيفية إرفاقها) ، فسيتم تجاهل الملفات التي تم تعديلها خارج Code ، وكذلك التغييرات مثل نقل الملفات ونسخها.

إذا كان يأتي من منطق مراقبة المجلد الذي تم تنفيذه على شجرة الحل ، فيجب القيام بذلك بشكل متكرر للشجرة بأكملها. لست متأكدًا مما إذا كان الأمر يستحق الأداء.

@ karabaja4 أعتقد أن Code يكتشف التغييرات الخارجية أيضًا. لذا ، فإن الارتباط بمثل هذا "الحدث" ربما باستخدام نظام debounce بحيث لا تؤدي تغييرات الملفات المتعددة في نفس الفاصل الزمني إلى عمليات تحقق متعددة من حالة git. هذا يمكن أن يعمل! ربما يمكن لشخص على دراية بقطعة fs أن يتناغم؟

هذا حقا لا ينبغي أن يكون على التراكم. هناك قيمة حقيقية جدًا لإضافة هذه الميزة التي تبدو صغيرة. سعادة المطور تسير على طول الطريق. من المخيب للآمال رؤية هذه المشكلة بها الآلاف من إجراءات 1+ ويتم تجاهلها منذ عام 2015.

@ kamok صحيح أن! على الرغم من أن Atom بطيء ، إلا أنه كان لدي خيار آخر ... لقد عدت إلى WebStorm ، الذي لم يهزم بالطريقة التي يتكامل بها مع Git بالإضافة إلى الميزات الأخرى التي يتعين عليك تثبيت ملحقات عليها على vscode ، ولا يزال بإمكانه أن يكون سريعًا جدًا ويبدو أنه محرر خفيف الوزن بدلاً من IDE ، من حيث السرعة. هذه الميزة وحدها (حالة Git في مستكشف الملفات) لا تزال غير كافية للاحتفاظ بمستخدمي vscode. سيكون هذا مجرد قطرة في دلو. إنها الميزة التي أفتقدها على الأقل ، قادمة من WebStorm.
أقترح أن يقوم فريق vscode بإلقاء نظرة على كيفية قيام الرجال في JetBrains بذلك.
أنا آسف ، لكنني حاولت ... لقد كافحت مع vscode لعدة أشهر حتى الآن ، وانتظرت التحديث بعد التحديث ، لكنني ما زلت أجد نفسي أغلق vscode باستمرار وأعيد فتح المشروع في WebStorm من أجل: حالة Git في المستكشف الشجرة ، المخبأ ، عرض المجلد / الشجرة للتغييرات المحلية ، مقارنة الفروع ، انقر بزر الماوس الأيمن> قارن مع الحافظة ... وهذه فقط من أعلى رأسي. لا يزال أمام تكامل Vscode Git طريق طويل إذا كانوا يريدون حقًا مساعدة المطورين.

_ تم الإرسال من Samsung SM-G950F باستخدام FastHub _

MrCroft ، أقترح عليك الاتصال بالفريق مباشرةً إذا كنت قلقًا جدًا بشأن منهجية عملهم ، وإلا يمكنك إجراء 1+

cucumbur فعلت بالفعل (تحولت من vscode). أنا فقط أعبر عن حزني ، لأنني أحببت حقًا كيف شعرت vscode. كنت سأحب أن يكون هناك تكامل جيد مع Git حتى أتمكن من الاستمرار في استخدامه. أنا متأكد من أن الكثير من الناس يشعرون بنفس الشيء.
سأظل أراقبها. ربما ، من يدري ، في "مستقبل ليس بعيدًا جدًا" سيتم إنجازه ... بخلاف vscode ، أنا في الواقع معجب كبير بـ Microsoft ... البرامج والأجهزة ، قاموا ببناء أشياء عالية الجودة 9 من 10 مرات . أتمنى أن تصبح vscode واحدة من 9.

_ تم الإرسال من Samsung SM-G950F باستخدام FastHub _

kamok تتراكم كل مشكلة جديدة وتبقى هناك حتى يتم معالجتها. لا أعتقد أنه يتم تجاهل هذه الميزة على الإطلاق. إنها تتطلب فقط تغييرات أكثر مما تدرك. وبقدر ما أعلم أنهم يريدون جعل هذا جزءًا من واجهة برمجة التطبيقات الخاصة بالامتدادات ، وتفتقر شجرة الملفات حاليًا إلى الكثير من الميزات لتحقيق ذلك.

إذا قمت بفرز المشكلات عن طريق الإبهام لأعلى ، فسترى أن هذه المشكلة هي ثاني أكثر المشكلات شيوعًا ، حيث يتم العمل على المشكلة الأولى وتقترب من الانتهاء. أنا متأكد من أنهم سيبدأون العمل على هذا بمجرد اكتمال الآخر.

على الرغم من ذلك ، سيكون من الرائع إجراء تحديث عرضي على هذا الموضوع.

تحولت من atom ولكن في مشروع كبير لا يحتوي على ملفات محدثة مميزة ، مما يجعل من الصعب العمل معها.
العودة إلى Atom حتى تتوفر هذه الميزة

ربما من الجدير بالذكر أن الحل البديل / المؤقت الذي من شأنه أن يعمل بالنسبة لي ... هو أن تكون بنية الشجرة مكررة في عرض "Open Editors". عادةً ما يُظهر لي العرض الملفات "المحدثة" ، لكن من الصعب جدًا العمل معها ، على عكس ما إذا كان من الواضح مكان وجود هذه الملفات في المشروع.

أي تحديثات على هذا؟

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

أنا ماسوشي 👎 تعليقي الخاص.

ما زلت أحاول VSCode ولكن نظرًا لعدم توفر هذه الميزة ، فإنها تمنعني من التبديل. لم أدرك مقدار الاعتماد على هذه الميزة في Atom حتى حاولت التبديل.

فقط في انتظار التبديل إلى رمز VS من atom ، آمل أن يتم تنفيذه قريبًا.

+1

مرت سنتان 。。。

والمثير للدهشة أن تعليقك لم يغير ذلك. أولئك منا الذين يهتمون بالتطوير والمساهمات المحتملة يشتركون في سلاسل إصدار ، ولا يساعد تعليقك شيئًا ويرسل بريدًا إلكترونيًا عديم الفائدة إلى 99 شخصًا

مرحبًا ، لا تحصل على أي نتائج إلا إذا حاولت ، أليس كذلك؟

لقد فاتني كثيرًا في البداية ، وعلى الرغم من أنه سيكون من الملائم جدًا الحصول عليها ، فإن "المستكشف المختلف" (الرمز الثالث في القائمة الرأسية) قوي حقًا وهو مفيد جدًا

+1
سيكون رائعا إذا تم تنفيذ هذا واوووووووووووووووووووو ...!

لقد كتبت مهمة gulp التي يجب أن تبسط تثبيت الاختراق (VS Code 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

PS لم يتم اختباره على جميع المنصات حتى الآن ، سأكون ممتنًا إذا جربه شخص ما على OSX.

@ karabaja4 لا يبدو أن "الاختراق" معقدًا لتطبيقه في vscode نفسه. نظرًا لأنه يبدو أن مطوري vscode لا يصلحون هذه المشكلة في أي وقت قريب ، فربما يمكنك إنشاء طلب سحب؟

@ karabaja4 شكرا على هذا! العمل لدي على macOS Sierra ، VSCode 1.15.1.

@ karabaja4 شكرا! العمل هنا على Fedora 26، VSCode 1.15.0. هذا وحده جعل التبديل من Atom أكثر ملاءمة.

@ karabaja4 +1 شكرا !! العمل لدي على Ubuntu 14.04 64 ، VSCode 1.15.1 (تثبيت يدوي)

+1

@ karabaja4 +1 هذا رائع.

+1

@ ماتي بلس واحد

_ تم الإرسال من HTC MSM8996 الخاص بي لـ arm64 باستخدام FastHub _

ibrokemypie ناقص اثنين

تم إرسالها من HTC MKB826262 الخاص بي لـ arm32 باستخدام Lolbug

أي أخبار عن هذه الميزة؟

+1

+1

+1

@ karabaja4 شكرا الرجل = D <3

+1

واو ، هذا كان يجب أن يتم تنفيذه قبل عامين

eosrei +1

+1

+1
دعونا نواجه الواقع. أنا أحب VSCode ، لكن Git tab سيئة حقًا

@ karabaja4 مرحبًا ، 1.16 خرج للتو ، هل ستقوم

تحرير: يعمل مع 1.16 ، فقط ليس عند استخدام مساحات عمل متعددة الجذور.

@ karabaja4

@ karabaja4 فقط جعلت يومي. شكرا يا رجل!

+1

+1

يجب أن يكون التعليق +1 حظرًا تلقائيًا على مشكلات GitHub ...

سيكون أجمل إذا قام 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

الشيء الوحيد الذي أحصل عليه الآن هو رسالة تحذير عند الإقلاع. لحسن الحظ ، إنه مجرد تحذير.

إصدار VSCode 1.16.0

+1

هل هناك سبب لعدم تنفيذ ذلك بعد أم أن هناك أي جدول زمني عند إضافة هذه الميزة؟

بالأمس ، عدت إلى Atom لمدة ساعة لاستخدام آخر تحديث لـ IDE واعتقدت أن حياتي سهلة للغاية مع الملفات الملونة في عرض شجرة الملفات.

تحرير: للتو وجدت حلاً. تعمل إضافة سطر إلى أحد ملفات التعليمات البرمجية مقابل (جهد أقل من دقيقة واحدة) مثل السحر! https://github.com/karabaja4/vscode-explorer-git-status

@ timc13 @ fro3clr @ WLLR9505ngortheoneedokehncnegoleoloehxaecorredorBenGale

هل سبق لك أن رأيت أنه يمكنك استخدام تفاعل الرموز التعبيرية بدلاً من النشر +1 ؟

في كل مرة ننشر فيها تعليقات على github ، يتلقى جميع المشتركين في الموضوع إشعارات ويتلقى بعض المستخدمين رسائل بريد إلكتروني أيضًا. إنه نوع من الإحباط عند قراءة بريد إلكتروني مكتوب: +1 ويمكنك أن ترى في هذه التعليقات ، هناك الكثير من: -1 :.

يقدر المجتمع إذا بدأنا جميعًا في استخدام ردود الفعل بدلاً من ذلك:
https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments

أعتذر عن أي إهانة مع هذه المعلومات وللآخرين الذين يتلقون هذا الإشعار.

لقد قرأت في سلاسل رسائل أخرى أن Microsoft صنفت أولوية الميزة بعدد تعليقات +1. أعتذر إذا كان لدي هذا الخطأ وليس بأي شكل من الأشكال كيف يتم تصنيف الميزة. أزلت تعليقي. في كلتا الحالتين ، ما هو الموقف العدواني يا أخي؟ كان بإمكانك الإشارة إلى نفس الشيء بنبرة أفضل leocaseiro

هتافات.

مرحبًا aecorredor ، أعتذر إذا بدت وقحة.
أنا لست متحدثًا أصليًا للغة الإنجليزية ، وربما بدا أحد التعبيرات المترجمة سيئًا. من فضلك ، ساعدني في تحسين وصف هذا التعليق. هل يجب علي استبدال كلمة مزعجة؟ عديم الفائدة؟ شكرا.

ملاحظة: أنا سعيد لأنك قمت بتحرير العالم الذي قرأته في رسالتي الإلكترونية ، لأنني ربما أبدو وقحًا ، لكن لم يكن في نيتي أبدًا الإساءة إلى أي شخص.


تحديث: لقد استبدلت تعليقي السابق ، يرجى إعلامي إذا كان يبدو أفضل. شكرا

مرحبًا leocaseiro ،

آسف لكتابة تلك الكلمة السيئة في المقام الأول. لقد أدركت بالفعل
أن حاجز اللغة ربما كان سبب الارتباك. لكن
نعم ، سأستبدل هاتين الكلمتين بشيء آخر على غرار:
"من فضلك ، نحن نحاول جميعًا تحسين تجربة جيثب بشكل عام
فتح المشكلات / طلبات الميزات ، وسيكون من الجيد أن يبدأ الأشخاص في استخدام ملفات
ردود فعل الرموز التعبيرية بدلاً من التعليقات مثل "+1" ، والتي تخلق فقط
الحمل غير الضروري في سلسلة الرسائل ، وتشغيل رسائل البريد الإلكتروني التي ليست كذلك بالفعل
المساهمة بأي طريقة مفيدة. يرجى الرجوع إلى هذا الرابط لمعرفة كيف
ردود الفعل على الرموز التعبيرية تعمل: {Link here}

في صحتك ، ولا مشاعر قاسية.

بست.

يوم الاثنين 18 سبتمبر 2017 الساعة 11:44 مساءً ، Leo Caseiro [email protected]
كتب:

مرحبًا 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 آخر 😁.

إنه لأمر مخز ، لأن المبرمجين غالبًا ما يلومون المستخدمين على عدم قراءة رسائل الخطأ ، لكن لا يمكنهم قراءة بعض التعليقات أو التعليمات.

ربما سيكون من المفيد وضع شيء ما على README.md لمطالبة المستخدمين باستخدام ردود الفعل بدلاً من التعليق +1؟ ربما يكون الأمر مخفيًا بعض الشيء في CONTRIBUTING.md.

لا أعرف ، أعتقد أنني سأقوم فقط بإلغاء الاشتراك وانتظر ملاحظات الإصدار عندما تكون جاهزة.

لقد قمت بإنشاء Gist الذي يعتني بهذا. الإصلاح الذي أجراه @ karabaja4 لا يؤدي إلى مشكلاته ). هناك علاقات عامة بواسطة

لذلك إذا كنت ترغب في جعل هذا يعمل بشكل أفضل ، تحقق من جوهر بلدي: https://gist.github.com/WadeShuler/1637073371ad126779076344c34278f3

ikatyang : آسف ، هل هذا يعني أنه سيتم تقديم هذه الميزة في أكتوبر (2017) ..؟

nkkollaw كان الرابط من هذا التعليق: https://github.com/Microsoft/vscode/issues/34160#issuecomment -331066864

كان التعليق يطلب فقط مناقشة الأمور المتعلقة بهذه المشكلة هنا ، وليس في "خطة التكرار" (وطلب مناقشتها باللغة الإنجليزية).

آه ، حصلت عليه @ tiangolo ، شكرًا.

سأحاول التعامل مع Atom حتى تكون هناك واجهة برمجة تطبيقات لتنفيذ هذه الوظيفة (آسف ، لست جيدًا بما يكفي للمساعدة على الإطلاق في هذا).

أنا أعمل على إجراء التحديث داخل المشروع نفسه.
في الوقت الحالي ، قدمت إثباتًا لمفهوم يعمل ولكني لا أجتاز tslint ، لأنني ما زلت بحاجة إلى فهم الطبقات من أجل وضع كل شيء في المكان المناسب.
سأضع بعض التحديثات هنا ، وإذا أراد شخص ما مساعدتي ، فسوف أضع رابط طلب السحب الخاص بي لاحقًا ، لذا فنحن نرحب بك لمساعدتك.

مخطط في أكتوبر 2017 التكرار !! 👍

لدينا النسخة الأولى من هذا. يطمئن الجميع إلى أن هذا سيأتي في أكتوبر.

oct-09-2017 18-09-19

مزيد من المعلومات:

  • سيتم تحديد الألوان في موضوعات مما يعني أنه يمكن تخصيصها حسب ذوقك
  • سيكون هناك إعداد لتمكين / تعطيل هذا
  • هذا ليس حصريا للتحكم في الإصدار. نحن نبحث أيضًا في إبراز الأخطاء / التحذيرات في مستكشف الملفات (انظر # 782) ونفكر في الكشف عن ذلك لمؤلفي الإضافات.

أسئلة مفتوحة:

  • هل يكفي استخدام اللون فقط؟ هل يجب أن يكون هناك أيضًا تلميح نصي و / أو رمز؟
  • ما هي حالة الطفل التي يجب على الوالد تحديدها؟ هل يجب أن يذهب هذا حسب الأهمية؟ هذا أمر سهل مع وجود الأخطاء والتحذيرات ولكن ما هو الأهم ، الملف الذي تم تغييره أو عدم تعقبه أو تجاهله؟
  • هل يجب أن نظهر زخارف الملفات هذه أيضًا في حاوية "Open Editors" و / أو منتقي الملفات وما إلى ذلك؟

سأبقي هذه المشكلة محدثة أثناء حدوث الأشياء. كما هو الحال دائمًا ، استخدم العواطف بدلاً من تعليقات "+1". شكرًا وترميزًا سعيدًا!

أنا شخصياً ما أراه في الصورة أعلاه يكفي. تبدو رائعة وشكرا!

يبدو أنه فاتك الملفات التي تم تجاهلها بواسطة .gitignore باللون الرمادي الداكن؟

لا يمكنك تغيير اللون (الرمادي) لمجلد أصلي لملف تم تجاهله بالداخل. أنت فقط رمادي اللون إذا تم تجاهل المجلد نفسه. يرجى الاطلاع على تعليقي / إصلاح بعض التعليقات. يجعل Git يتخلص من الحالات ويكتشف ما إذا كان دليلًا أو ملفًا. ستعمل إضافة فئات إلى الملفات / المجلدات في شجرة الملفات ... مثل "git-status-modified" أو "git-status-added". ثم يمكن للسمات أن تعمل بسحرها.

سيكون من الرائع أن تسمحوا لنا يا رفاق بسحب ما تعملون عليه ، حتى نتمكن من اللعب به ، وإنشاء العلاقات العامة. بصراحة ، إذا حدث خطأ ما ، فمن المحتمل أن يتوقف الأشخاص عن استخدام Code إذا تعذر تحقيق حل قابل للتطبيق في وقت معقول. ترك العديد من الأشخاص (بمن فيهم أنا) Atom لمشكلات مماثلة.

أعتقد أيضًا أنه إذا كانت هناك أخطاء ، فربما استخدم نقطة قبل أو بعد اسم الملف في الشجرة. سيكون هذا غير مزعج ، دع السمات تصممها ، ولن تتداخل مع تمييز ألوان Git.

نعم يجب فتح هذا لمطوري الامتدادات! كان يجب القيام به بالفعل. لماذا لا نريد التحكم في شجرة الملفات لعمل امتدادات رائعة أو إصلاح الأشياء التي لم تفعلها يا رفاق؟

يبدو أنه فاتك الملفات التي تم تجاهلها بواسطة .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 : ليس لدي أي فكرة عما تتحدث عنه

لقد أشرت للتو إلى أن الملفات التي تم تجاهلها وأطفالهم يجب أن يتحول لونهم إلى اللون الرمادي ، وهذا واضح تمامًا أن هذا التعريف لا يطلب من آباء الملفات التي تم تجاهلها باللون الرمادي.

أما بالنسبة لل:

رسالتك العدوانية السلبية هي مجرد انسداد هذا الموضوع برسائل غير مفيدة ...

ليس لدي أي فكرة عن كيف كانت رسالتي عدوانية سلبية - أعتقد أنك لا تعرف ما تعنيه - لكنك الشخص الذي يسد هذا الموضوع ، نظرًا لأنك الشخص الوحيد الذي علق بعد رسالتي.

عجيب.

نجاح باهر .. فكرة جيدة! أحبها!

أرغب في الحصول على xcode مثل تلميح نصي بحرف واحد في العمود الأيمن. يجعل الملفات سهلة التصفية / المتابعة بصريًا.

nkkollaw قلت:

لا يمكنك تغيير اللون (الرمادي) لمجلد أصلي لملف تم تجاهله بالداخل. أنت فقط رمادي اللون إذا تم تجاهل المجلد نفسه.

من الواضح أنني أتحدث عن المجلدات الأم ، وليس الأطفال. هنا رسمت لك صورة:

vscode-git-status-tree-explain

إليك .gitignore في الدليل الأصلي ، web كمرجع:

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

كانت رسالتي ردًا على رد jrieken على العمل هنا ، حيث قال:

ما هي حالة الطفل التي يجب على الوالد تحديدها؟ هل يجب أن يذهب هذا حسب الأهمية؟ هذا أمر سهل مع وجود الأخطاء والتحذيرات ولكن ما هو الأهم ، الملف الذي تم تغييره أو عدم تعقبه أو تجاهله؟

الإشارة إلى أن أصل ملف / مجلد "تم تجاهله" يمكن أن يكون له حالة ، وهي ليست كذلك. ومن هنا ردي. أنت تربك ما تراه بصريًا ، مقابل ما تستخدمه Git بالفعل لقائمة التجاهل

➜  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 إلى جميع العناصر (الملفات والمجلدات) التي تبدأ بـ backend/web/assets/6f57f06b/ .

إن CSS الذي يتطابق مع مجلد شجرة الملفات backend/web/assets/6f57f06b/ يشبه هذا (يأخذ حاليًا قاعدتين!):

#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;
}

ملاحظة: في القاعدة الأولى ، نطابق العنوان بعلامة = فقط ، تمامًا! في القاعدة الثانية ، نطابق جميع العناوين بـ ^= ، لذا فإن بداية السلسلة تطابق كل شيء أعمق من ذلك أيضًا (كل الأطفال).

لمطابقة دليل يأخذ قاعدتين CSS. لذا أعتقد أثناء القيام بذلك ، يجب أن نمضي قدمًا ونصنع title على عنصر HTML للأدلة ، لتضمين شرطة مائلة. يمكنك أن ترى ما أتحدث عنه في لقطة الشاشة هذه:

vsc-dir-trailing-slash

نعم ، كان تعليقك عدوانيًا سلبيًا ، لأنك كنت وقحًا / متذمرًا / مجنونًا دون أن تقول الكلمات في الواقع. بالإضافة إلى أنك كنت مخطئا. لم يقل أحد أي شيء عن الأطفال ، وهذا ليس حتى ما كنا نتحدث عنه.


تضمين التغريدة
الطريقة التي يعمل بها إعداد Atom الخاص بي: "تم تحريره" له الأسبقية على "مضاف". حذف ملف لا يظهر أي حالة. لا توجد حالة لـ "منظم". أعتقد أنه يجب على الآخرين التحقق من إعداد Atom الخاص بهم ومعرفة ما إذا كان هذا صحيحًا بالنسبة لهم أيضًا ، وأنه ليس إعدادي فقط. سيكون من الجيد إضافة رمز لكل موقف ، والسماح للمستخدم بتحريره ليعمل بالطريقة التي يريدها.

ربما تضيف فئات متعددة ، وبالتالي فإن الدلائل الرئيسية على طول الشجرة ، سيكون لها "git-status-added" و "git status-modified". ربما حتى يتم حذف "git-status-delete" إذا تم حذف شيء تحته.

ثم استخدم css لمطابقتها. إذا كنت تريد لونًا مختلفًا لـ .git-status-added.git-status-modified ، فيمكنك عمل خط برتقالي بتسطير أخضر (برتقالي للتعديل ، وأخضر للإضافة). إذا كانت تحتوي فقط على فئة .git-status-added ، فقم بجعل الخط أخضر.

لن يكون الأمر مهمًا حقًا بمجرد إضافة فئات إليها ، يمكن للجميع إعداد بعض CSS كما يريدون. قد تحتاج إلى وضع افتراضي "جيد جدًا" خارج الصندوق بالرغم من ذلك.

سأقوم بسحب هذا الفرع عندما أحصل على بعض الوقت ، وأتفقده.


كيفية التعامل مع أخطاء النسالة وحالة البوابة؟

يضع Atom خطًا متعرجًا أحمر أسفل اسم الملف ، كما ترى هنا:

image

أعتقد أنه يجب علينا إضافة فئة مثل lint-error إلى نفس العنصر مثل حالة git ، والتي يمكننا (والقوالب) تجاوزها عبر أوراق الأنماط الخاصة بنا.

لذا فإن div لنفس العنصر في شجرة الملفات كما استخدمته كمثال أعلاه (backend / web / الأصول / 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 git-status-edited و lint-error :

<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;
}

هل لديكم سلاك يا رفاق؟ هناك الكثير من الملفات المحررة في التنفيذ. أنا أبحث عن المكان الذي تقوم فيه بالضبط بتطبيق لون حالة git على شجرة الملفات. هل هو في /extensions/git/src/repository.ts ؟

شكرا للجميع وشكرا لتوضيح قواعد التغييرات والملفات غير المتعقبة والمتجاهلة. سيأتي المطلعون في Tomorrows بنسخة مبكرة من هذا.

screen shot 2017-10-24 at 19 51 36 2

شيئين

  • بشكل افتراضي ، هناك مزيج من اللون والباجدي.

    • تمكين / تعطيل الرموز بـ: "explorer.decorations.badges": true|false

    • تمكين / تعطيل الألوان باستخدام "explorer.decorations.colors": true|false

  • تظهر الألوان في شجرة الملفات ، وقسم برامج التحرير المفتوحة ، وفي عرض SCM
  • هناك ثلاثة ألوان لتبدأ. يمكنك تخصيصها في إعداد workbench.colorCustomizations . الألوان هي gitDecoration.modifiedResourceForeground ،
    gitDecoration.deletedResourceForeground ،
    gitDecoration.untrackedResourceForeground ،
    gitDecoration.ignoredResourceForeground و
    gitDecoration.conflictingResourceForeground
  • لاحظ أنه من المحتمل أن تتغير أسماء الإعدادات وما إلى ذلك ، وقد تتم إضافة إعدادات جديدة ، وقد تتم إزالة الإعدادات الأخرى مرة أخرى.

لمعلوماتك - تم التعديل لتعكس التغييرات التي تم إجراؤها بعد النشر الأولي

أعتقد أنه من الأفضل عدم تطبيق الرموز الموجودة على الجانب الأيمن على الدلائل الرئيسية. يمكن أن يكون هناك خيار على الأقل.

يبدو أنه تم تحديث هذا في الإصدار الداخلي حيث تم استبدال scm.fileDecorations.useIcons و scm.fileDecorations.useColors بـ scm.fileDecorations.enabled والذي يعطي الرموز والألوان معًا.

أرغب في الحصول على الألوان فقط وليس الرموز. أي السلوك "القديم" scm.fileDecorations.useIcons : false و scm.fileDecorations.useColors : true

لقد حاولت تجربة استخدام explorer.decorations.badges و explorer.decorations.colors لكن يبدو أنه ليس لهما أي تأثير.

تعديل:
أقوم بتشغيل الإصدار 1.18 من الداخل ، قم بتنفيذ f1ee80be081b0d ... على نظام التشغيل windows 10
(سيكون من الرائع أن يكون النص الموجود في مربع الحوار "حول" قابلاً للتمييز بحيث يمكنك نسخه)

شكرا لوضع هذا معا jrieken !

كان لديه فكرتان:

  • يبدو أن اللون المحدد لا يزال هو الرمادي القديم بدلاً من لون الحالة
  • وافق على خيار أن يكون لديك أيقونات أم لا (لكل FredrikFolkesson )
  • مع عرض الأيقونات ، إذا كان اللون المعدل / المحدث فاتحًا ، فيجب أن يكون اللون "M" أو "U" غامقًا (أو العكس) بحيث يكون التباين موجودًا ويسهل قراءته.

نتطلع إلى عدم الاضطرار إلى تحديث ملف main.js مع كل بناء للحصول على الألوان !!!

مشكلة بسيطة (أستخدم أحدث المطلعين اعتبارًا من 16 أكتوبر) للإبلاغ ، jrieken : لا يظهر لون اسم الملف المعدل في شجرة المشروع إذا كان هذا الملف

هناك مشكلة أخرى أرغب في معالجتها وهي نفس الترميز اللوني ليس فقط لشجرة المشروع ، ولكن أيضًا لقسم المحررين المفتوحين. حاليًا ، لا توجد طريقة لمعرفة الملفات التي تم تعديلها وأيها لم يتم تعديلها في قسم المحررين المفتوحين. تعد القدرة على اكتشاف برامج التحرير المناسبة للملفات المعدلة أمرًا ملائمًا للغاية ، بحيث يمكن للمرء التنقل بين الملفات التي يعدلها بسرعة ولا داعي لمحاولة تذكر أسماء الملفات المعدلة حاليًا.

ستكون هذه ميزة رائعة. جديد في VSC من Atom وأفتقده كثيرًا.

انتقلت للتو من Atom أيضًا وفقدت هذه الميزة أيضًا. متى يتم جدولة الإصدار مع هذه الميزة؟

وبالمثل ، من المهم في الغالب لأن الملفات المصممة باستخدام gitignored بارزة جدًا في القائمة ويتم خلطها بكل شيء ...

مرحبًا ، أعتقد أننا نحتاج أيضًا إلى مفتاح لون لتغيير لون الشارات الأمامية (# 36246)

image

شكرا للجميع على ردود الفعل المستمرة. لقد قمت بتحديث ملخّص تعليقي الأولي ليعكس التغييرات الأخيرة. لقد تأكدت أيضًا من أن التغييرات التي تم إجراؤها على الإعدادات تنعكس دون إعادة التحميل وأن لون الحالة يفوز على لون التحديد.

بشكل افتراضي ، ما زلنا نستخدم اللون والشارة ، غالبًا لسببين: لا يعرف الجميع على الفور ما يعنيه اللون ، كما أن امتلاك الشارة (مع تلميحها) قد يجعل هذا الشرح الذاتي. ثانيًا ، هناك أشخاص ، مثلي في الواقع ، يواجهون صعوبات في التمييز بين هذه الألوان والهدف من الشارة جعل هذا الأمر أكثر سهولة.

jrieken هل يمكن أن تخبرني ما إذا كان يتم تطبيق فئات CSS على العناصر الموجودة في مستكشف شجرة الملف الأيسر؟ سيوفر هذا أفضل قابلية للتوسيع ويسهل على مطوري السمات ، ولنا شخصيًا ، تخصيص الألوان وتجاوزها.

على سبيل المثال: عندما يتم إصلاح رمزك الجديد ، قم بوضع علامة على ملف أو مجلد على أنه مضاف ، يجب إضافة فئة مثل git-status-added . ثم يمكننا استهداف ما إذا كان من خلال أوراق الأنماط الخاصة بنا لتخصيص الألوان وعدم التعثر مع ما تقدمه لنا من خارج الصندوق.

WadeShuler لا تعمل ألوان السمات . إنه أمر غير مباشر ، إعطاء أسماء لأشياء معينة مثل editorLineNumber.foreground هو اسم اللون الأمامي لأرقام الأسطر. تقوم النسق بتعيين ألوان لتلك الأسماء ويلتقط المحرر هذه القيم عند التجسيد. تحقق من هذا لمزيد من المعلومات الأساسية حوله: https://code.visualstudio.com/docs/getstarted/theme-color-reference

مع المطلعين التاليين ، من المحتمل غدًا في التاسع عشر ، سيكون هناك عرض خاص للملفات التي تم تجاهلها ( git.color.ignored ) وستظهر الألوان / الشارات في قسم "Open Editors". لقد قمت بتحديث https://github.com/Microsoft/vscode/issues/178#issuecomment -335511695 وفقًا لذلك.

تضمين التغريدة ماذا عن مفتاح اللون لشارات git في المقدمة؟
https://github.com/Microsoft/vscode/issues/178#issuecomment -336904514

عمل جميل جدا! إنه لأمر رائع أن تستحوذ على هذه الميزة القادمة إلى vscode.


في التنفيذ الحالي ، لم يتم تمييز الملفات المعدلة في وحدة فرعية بشكل صحيح على أنها تم تعديلها.

في المثال التالي:

يتضمن المستودع الرئيسي وحدة فرعية في src/components/ . تم تعديل عدة ملفات في الوحدة الفرعية. تقارير vscode بشكل صحيح تم تعديل src/components/ لكنها لا تشير إلى التغييرات التي تم إجراؤها في الوحدة الفرعية.

vscode

يحدد Atom الملفات المعدلة بشكل صحيح:
atom

من المحتمل أن تكون هذه المشكلة متعلقة بـ https://github.com/Microsoft/vscode/issues/7829

تضمين التغريدة ماذا عن مفتاح اللون لشارات git في المقدمة؟

equinusocio لا تقلق ، سيحدث ولكنه يحتاج إلى بعض التفكير. من المقرر في أكتوبر

jrieken شكرا لك !. فاتني شيء .. أيقونات المجلد تحصل أيضًا على اللون المعدل / المضاف؟ هل هناك مفتاح جديد لإضافته إلى سمة الرمز لتعيين رمز مختلف للمجلدات عندما يتم تحرير / تعديل git؟

jrieken - الإصدارات في 1.18. أود أن أشكرك على عملك حتى الآن. لقد اختبرت للتو الإصدار 1.18 من المطلعين. لقد قمت بقشط الخيط أعلاه ، لذا عفوا إذا كان لديك بالفعل شيء قيد الإعداد لـ 1.19 لمعالجة ما أذكره أدناه.

1) تبدو الحالة "المضافة" في شجرة الملفات "محدثة وغير مدمجة" بشارة "U". يجب أن يكون للملفات المضافة شارة "A".

2) لا يوجد خيار لوني لـ git.color.added

3) لا يوجد خيار لوني لـ git.color.ignored .

4) (خلل) يتعامل مع الملفات "المضافة" على أنها "غير متتبعة". لقد قمت بفحص ملف "تمت إضافته" ، ويبدو أنه في html ، يعتقد أنه لم يتم تعقبه. (يظهر العنوان span "untracked" والفئة هي monaco-decorations-style-32 ، رمز "U"). يتضح هذا عند تغيير اللون على workbench.colorCustomizations مقابل git.color.untracked ، حيث يتحكم في الملفات المفترضة "المضافة".

5) دعم الحالة "R" ، من أجل "إعادة التسمية" أو نقلها ، أضف شارة "R" ، وأضف الإعداد المطابق git.color.renamed .

شكرًا ، أتطلع إلى تجربة 1.19 👍

danjjl @ هناك PR معلق لـ # 7829 مع تطبيق ذلك ، تحصل وحدات git الفرعية على التلوين.

هناك مشكلة محتملة ، تتمثل في أنه إذا تم تغيير الوحدة الفرعية ، فلا أعرف ما إذا كان سيتم التعامل معها (الدليل الذي يمثل جذر الوحدة الفرعية) على أنها لون حالة الدليل في مستودع git الرئيسي ، أم أنها مختلفة اللون على أساس الملفات المضمنة.

أي ، لا أعرف ما إذا كان لون دليل الوحدة الفرعية سيعتمد على "حالة git" في الدليل الأصلي ، أو في الوحدة الفرعية. قد لا يهم على أي حال.

jrieken هل لديك مجموعة Slack ، أو في مكان آخر لمناقشة هذه المشكلة؟ يمكنني المساعدة :) لقد تمكنت من سحب التغييرات الحالية من الفرع الرئيسي وتطويرها وتصحيحها. لقد أصلحت الملفات "المضافة" التي تظهر كـ "U" ، بل وأضفت دعمًا "مرحليًا". نظرًا لأنها كانت المرة الأولى لي في المشروع ، فأنا أعيد ضبطه مرة أخرى لإتقانه والقيام به مرة أخرى. لقد أجريت مجموعة من التغييرات ، وأريد أن أذهب مثل الجراح وليس سلاحًا نوويًا.

لماذا توجد شيكات على raw.x + raw.y متبوعة بشيكات على raw.x ثم raw.y ؟ يبدو أنه يتسبب في مطابقة حالتين مختلفتين.

لماذا يوجد 2 من ثوابت الحالة لـ ADDED / INDEX_ADDED ، MODIFIED / INDEX_MODIFIED ، وعدد قليل من الثوابت الأخرى؟ أفهم جميع حالات git المختلفة ، ولكن سيكون من المنطقي التعامل معها للمستخدم النهائي ، وليس تسمية حالات Git. ADDED لما لديك الآن كـ UNTRACKED حتى يكون لديك رمز إعدادات git.color.added . أعتقد أن بعض ثوابت الحالة هذه مكررة ويجب تبسيطها وتنظيفها.

حالة git _M <- شرطة سفلية = مسافة / لا شيء ، تتطابق مع raw.y وأنت يا رفاق لديك INDEX_MODIFIED . هذا غير صحيح ، الحالة حيث x = لا شيء و y = M تعني staged .

لسبب ما ، وأحيانًا بشكل عشوائي ، يبدو أنه لا يعكس التغييرات. أيضًا ، يبدو أن تغييرات حالة git يتم مسحها بشكل متكرر من أعلى إلى أسفل. إذا كان لديك مشروع كبير ، يمكنك مشاهدة حالة "التجاهل" وهي تتساقط من خلال المجلدات / الملفات الخاصة بك. لتسريعها ، والتنقل بشكل أعمق ، بدا وكأنه يركلها في هذا الدليل ويظهرها باللون الرمادي. - هل هذه العملية تبطئ النظام / VSCode كثيرًا؟ هل قام أي شخص بقياس ذلك؟ ليس هناك حقًا حاجة للتنقل بين كل ملف / مجلد عندما يتم تجاهل الوالد. يجب أن يحصل الأطفال على أوضاعهم من والديهم. - إذا كان لديك 5000 ملف ignored ولكن جميعها في دليلين (على سبيل المثال: node_modules ، بائع) ، فلا يجب علينا معالجة 5000 ملف ، فقط دليلان يتحكمان في مظهر أطفالهم.

سأعيد التغييرات في وقت لاحق اليوم وأصدر PR.

أشكرك مجددا لأجل عملك. أنا أحاول فقط المساعدة بدلاً من العزف عليك ، حيث يمكنني فعل ذلك في الواقع لول 👍

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 ، والتي من شأنها أن تتطابق مع MODIFIED ، الفهرس غير معدل (أي ليس على مراحل). ما لم تكن بالطبع تبحث في نسخة مكررة من هذا الرمز في مكان آخر.

petkahl شكرًا ، أنا على دراية Git Status . لقد استخدمته منذ أسابيع لإجراء إصلاح لحالة vsc git لإضافة حالات Git الأساسية حتى يتم حل ذلك رسميًا.

من الممكن (بطريقة ما) الحصول على _M (شرطة سفلية = مسافة). لست متأكدًا من كيفية ولماذا ومتى .. حصلت على هذا في وقت سابق اليوم (وكذلك قبل بضعة أسابيع عندما كنت أعمل على Gist):

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

الآن بعد بضع ساعات ، قمت بتشغيله وحصلت على "A". لا أعلم ما الذي تغير منذ ذلك الحين ..

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

عندما كنت أقوم بإجراء بحث عن Gist الخاص بي ، أعتقد أنني استنتجت أنه من الممكن الحصول على "A_" و "_M" للتنظيم. لقد وجدت أيضًا موقعًا قام بتقسيم الحالة بشكل أكثر وضوحًا من مستندات git-status ، ولا يمكنني العثور عليها مرة أخرى.


يمكنك أيضًا الحصول على "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/

إذن ، هل يجب أن يحتوي هذا على شارتين ، "[S] [M]"؟ أفضل معرفة الملفات التي قمت بإعدادها. مفيد عند قطف الكرز. قد يكون من المفيد الاستمرار في معرفة ما إذا كنت قد قمت بتعديل ملف مرحلي. يجب أن يكون على الأقل شارة مرحلية.

WadeShuler يمكنني الحصول على _M باستمرار من خلال الالتزام
وبالتالي:
إنشاء ملف: ؟؟
بوابة إضافة ملف A_
git الالتزام (ليس في الحالة ، ولكن ما يعادل مساحة الفضاء)
تعديل الملف: _M
بوابة إضافة ملف M_
تعديله مرة أخرى: مم

ليس لدي رأي حقًا بشأن الشارات عندما تحتوي على شارتين. لا أقوم بتسجيل الوصول أبدًا دون النظر إلى نافذة الحالة ، التي تقسمها بوضوح ، تمامًا كما تفعل حالة git العادية. ربما مجرد إعداد يتيح لك اختيار أيهما له الأولوية؟ أستطيع أن أرى الحجج لكليهما. أو شارتين ، على ما أعتقد. هل سيكون نفس الشيء بالنسبة للتلوين؟

لقد قمت بإضافة دعم Staged . يمكنك رؤية التغييرات هنا: WadeShuler / vscode: gitstatus-fix . لقد جعلت أيضًا بعض الشارات الموجودة في علامة تبويب Git Status تبدو أفضل قليلاً من خلال جعلها أكبر قليلاً.

لسبب ما ، أزال تعتيم / تجاهل الدليل vendor ، لكن محتوياته بالداخل لا تزال رمادية اللون ويتم تجاهلها. لا أفهم لماذا توقف تعديلي البسيط عن تحويل الدليل vendor إلى اللون الرمادي؟ هذه هي المشكلة الوحيدة فيما فعلته للتو ، ولماذا لم أقم بإصدار العلاقات العامة حتى الآن ...

git-status-staged-updates

إذا كان سيتم تضمين ألوان / أيقونات الملف المرحلي ، فيجب أن يكون هذا اختياريًا بالتأكيد. أنا شخصياً أفضل ألا أرى في قائمتي لوناً مختلفاً عن اللون الأصلي الجديد / المعدل.

بمجرد البدء في تضمين التدريج ، يمكن أن يصبح الأمر معقدًا سريعًا نظرًا لوجود إمكانية لتضمين جميع التوليفات والتبديل بين new / new-staged / modified / modified-staged / modified-staged-modified / new-staged-modified ، إلخ. ، الأمر الذي سيؤدي إلى مصفوفة ضخمة من الألوان والارتباك.

أنا أصوت نحن لا نبالغ في تعقيد الأمر.

أوافقdseipp. هذا هو السبب الدقيق لعدم دمج دعم الملفات المرحلية في الاختراق الأولي الخاص بي عندما قمت به ، حيث لم أجد أي فائدة للملفات المرحلية لتلوينها.

الغرض من تمييز الألوان هو أنه يسمح لي بالعثور على ملفات جديدة / معدلة في لمحة في مستكشف الملفات. إذا قمت بترتيب بعض الملفات ، فعادة ما يكون ذلك قبل الالتزام أو إذا انتهيت منها بطريقة أخرى ، لذلك ليس لدي أي استخدام لتلوينها بشكل طبيعي.

إذا أضفنا لونًا لكل نوع ممكن من حالات git ، فسيبدأ مستكشف الملفات في الظهور كشجرة عيد الميلاد وسيكون من المربك جدًا رؤية ما يحدث بالفعل.

jrieken تقرير خطأ آخر ، يحدث على المطلعين

  • إصدار VSCode: Code - Insiders 1.18.0-insider (82dcf9835265cd0a45ec135587ae2a82673f1c8f، 2017-10-20T04: 24: 25.632Z)
  • إصدار نظام التشغيل: Windows_NT x64 10.0.15063

بشكل أساسي ، "ينسى" VS Code من وقت لآخر أن بعض الملفات يتم تعديلها وتحتاج إلى تلوينها وفقًا لذلك. على سبيل المثال ، لدي 6 ملفات تم تعديلها في الوقت الحالي. يُظهر رمز VS (بشكل صحيح) الرقم "6" على زر git. لكن ، في شجرة ملفات المشروع ، أرى ملفًا واحدًا فقط باللون الأصفر ، والملفات الخمسة الأخرى تبدو وكأنها لم يتم تعديلها. ومن المثير للاهتمام أن جميع الملفات الستة ملونة بشكل صحيح في قسم المحررين المفتوح.

dseipp يمكن أن يكون اختياريًا. ومع ذلك ، لن ترى اللون "المرحلي" أبدًا حتى تقوم بترتيب الملفات ... لذلك لا يتم رؤيته حتى 99٪ من الوقت ، ولا ينبغي أن يزعج أي شخص حقًا ..

@ karabaja4 لا أوافق على أنه لا فائدة منه. لقد أوضحت النقطة ، أنك لا تستخدم أبدًا / تلاحظ / تحتاج إلى تلوين مرحلي ...

الغرض من تمييز الألوان هو أنه يسمح لي بالعثور على ملفات جديدة / معدلة في لمحة في مستكشف الملفات. إذا قمت بترتيب بعض الملفات ، فعادة ما يكون ذلك قبل الالتزام أو إذا انتهيت منها بطريقة أخرى ، لذلك ليس لدي أي استخدام لتلوينها بشكل طبيعي.

لذلك حتى لو تمت إضافة هذه الميزة ، فلا ينبغي أن تزعجك ...

تساعد القدرة على رؤية الملفات المرحلية في اختيار ما تريد الالتزام به. إذا تم تغيير 100 ملف ، ثم نحتاج إلى تجميعها ، يمكننا البحث في شجرة الملفات ورؤية ما تم تنظيمه بسهولة ، والتقاط الملفات التي فاتناها ، للتأكد من أنها في نفس الالتزام.

كم مرة قمت بتخصيص حفنة من الملفات ، ثم أدركت أنك فقدت واحدة؟ لديك بعد ذلك خياران ، قم بتعديل الالتزام الأخير لتضمين الملفات المفقودة ، أو قم بإجراء التزام جديد. عند العمل مع فرق ، يكون من الأنظف والأقل إرباكًا أن يكون لديهم نفس الالتزام.

في المرحلة المرحلية ، لا يهم إذا تمت إضافة الملف أو تعديله أو أي شيء آخر ..


لنكون صادقين ، فإن الطريقة التي يتعامل بها Visual Studio Code مع Git ، هي أسلوب بسيط وعربات التي تجرها الدواب. أشجار الملفات الكبيرة ، يمكنك حرفيًا مشاهدة تنقيط التلوين من خلال الملفات / المجلدات. عشوائيا يسقط التلوين ...

أعتقد أن جميع احتياجات دعم Git قد أسقطت إعادة كتابتها من الصفر.

أود أيضًا أن أعبر عن دعمي لوجود تلوين مرحلي للملفات (اختياري جيد طالما يمكنني تمكينه).

إليك سير العمل الخاص بي: أبدأ العمل على بعض الميزات / إصلاح الأخطاء ، اجعلها في حالة "موافق" ، مما يعني أن الكود يعمل بشكل أو بآخر ولكنه يتطلب بعض التلميع / التعديلات / التنظيف أو إعادة البناء. في تلك اللحظة أقوم بإجراء تغييراتي. ثم قم بالتنظيف وإعادة البناء. إذا فشلت عملية إعادة الهيكلة أو أصبحت فوضوية للغاية ، فأنا أعود إلى الحالة المرحلية.

إن امتلاك القدرة على معرفة الملفات التي أقوم بتعديلها حاليًا أمر مفيد للغاية ، وعندما أقوم بإجراء التغييرات ، لا أريد أن أفقد كل هذه المعلومات والوصول إلى الشجرة العادية بدون ألوان.

vvs أوافق على عدم فقد ألوان الملفات المرحلية. يجب أن تظل الألوان حتى الالتزام. أفضل فقط أن يحافظ اللون المرحلي على الألوان الجديدة / المعدلة ويظل اللون (الألوان) المرحلي الإضافي اختياريًا.

ربما يمكن أن يحتفظ Staged بنفس الألوان ولكن فقط أضف نوعًا من الإبراز أو الغامق لمنحه التباين.

قد يكون من المفيد إلقاء نظرة على حالة التقنية الصناعية السابقة .. لا تتذكر رؤية مؤشر مرحلي ، ولكن ربما تغيرت الأوقات

هل الرموز الموجودة في مستكشف الملفات للملفات المعدلة / غير المدرجة / ... ضرورية حقًا؟ لدي بعض المشاكل في الانتباه ، لذلك تشتت الألوان والأيقونات بسهولة شديدة. ألا يمكن أن يكون اختياريًا ويتم تعطيله افتراضيًا؟ هل أنا الوحيد الذي يشتت انتباههم؟

من وجهة نظر تجربة المستخدم ، أحيانًا يكون القليل أكثر ، ولن يكلف الكثيرون عناء البحث عن خيار تعطيل هذه الأشياء وسيستمرون في المعاناة أو حتى يغيروا المحررين. أعتقد أنه سيكون من الجيد التفكير في هذا الأمر وتحديد ما إذا كان هذا ضروريًا حقًا لتجربة مستخدم أفضل (والتي أفترض أنها نقطة هذه الرموز.)

* لم يكن لدي الوقت لقراءة كل تعليق على هذه المسألة ، لذا يرجى إخباري إذا كان ما أطلبه قد تمت مناقشته بالفعل وسأستغرق وقتي لقراءة كل شيء في أقرب وقت ممكن للتوافق مع ما قيل. شكرا.

أعتقد أنه سيكون من الجيد التفكير في هذا الأمر وتحديد ما إذا كان هذا ضروريًا حقًا لتجربة مستخدم أفضل (والتي أفترض أنها نقطة هذه الرموز.)

https://github.com/Microsoft/vscode/issues/178#issuecomment -336960308 هو سبب وجود الألوان والشارات افتراضيًا. متفق عليه أنه يجعل واجهة المستخدم أكثر ازدحامًا قليلاً ، ومفتوحة للحصول على الاقتراحات التي يمكن الوصول إليها / شاملة ولكنها أيضًا نظيفة ونظيفة.

@ jrieken شكرا لك! هل يمكنك أن تدلني من فضلك على الالتزام الذي قدم الشارات؟ سأحاول أن أجد شيئًا مفيدًا لكلتا المشكلتين (مواجهة صعوبات في رؤية الألوان أو عدم معرفة الغرض منها ، ومشاكل الهاء).

vscode-git

jrieken لنأخذ صفحة من Xcode ونجعل الشارات أكثر دقة.

تُعد الشارات مفيدة لإعطاء تلميحات للمبتدئين ، ولكنها تصبح فوضى بعد التعرف على الألوان.

للحصول على مزيد من التخلص من الدراجات ، أفضل الشارات الملونة بـ git.color.ignored (_ اليسار_ أعلاه) لأنها تتمتع بنفس الأهمية المرئية. هذا هو ، تتلاشى ولكن لا تختفي في حال احتجت إليك.

إذا قمنا بتطبيق شارات خفية ، فيجب تحديث شارات الشريط الجانبي للتحكم في المصدر من أجل الاتساق.

أيا كان الاتجاه الذي تسلكه مناقشة الشارة ، فهل يمكن أن يكون تصميم الشارة على الأقل متسقًا مع تلك الموجودة في الشريط الجانبي لـ Git؟ يبدو الأمر مفككًا بعض الشيء عند وجود تصميم واحد للشريط الجانبي Explorer وتصميم مختلف لشريط Git الجانبي.

يعجبني اقتراح الحرف الواحد منjayjun. سأجربها اليوم.

إذا قمنا بتطبيق شارات خفية ، فيجب تحديث شارات الشريط الجانبي للتحكم في المصدر من أجل الاتساق.

سيحدث ذلك ، إنه على خطتي لشهر أكتوبر.

لقد قمت بتحديث https://github.com/Microsoft/vscode/issues/178#issuecomment -335511695 بأحدث لقطات الشاشة وأسماء الألوان. أيضًا ، مع Tomorrows Insider ، سنعرض نفس الشارات في عرض SCM ، لكن بدون ملصقات ملونة. مثل ذلك

oct-24-2017 19-55-03

إنها تبدو أفضل لجهودك المستمرة. أعتقد أن الشارات تبدو أفضل بكثير!

هل يجب أن تكون الشارة U رغم ذلك؟ أعتقد أن المجتمع يجب أن يثقل كاهله. يجعلني U أفكر أولاً في updated . أعلم أنه untracked في مصطلحات Git ، لكنني أعتقد أن A أكثر ملاءمة ، خاصة بالنسبة لأولئك الذين ليسوا على دراية بالمصطلحات الأساسية ، أن U غير متتبع. - أنا شخصياً أصوت لـ A للإضافة. كما هو الحال في ، تمت إضافته إلى المستودع الخاص بك.

ثم دعم staged (اختياري عبر الإعدادات) وهو قريب جدًا 👍

WadeShuler ، ماذا عن علامة الاستفهام (؟) لعدم تعقبها؟ لا أحب A لأنه يحتوي على دلالة مختلفة لـ git عن المقصود هنا ، على الأقل في ذهني.

تحرير: لكنني أوافق على أن U قد تكون مربكة.

أعتقد أنني سأكون بخير مع علامة الاستفهام. ومع ذلك ، لا أعتقد أن Code
يدعم Git فقط ، أليس كذلك؟ لا أعتقد أننا يجب أن ننظر إليه بصريًا في
المحرر باسم "Git" ، ولكن المزيد من التحكم في الإصدار بشكل عام.

مهما كان الأمر ، أنا حقًا لا أحب "U" لول

يوم الثلاثاء 24 أكتوبر 2017 الساعة 2:20 مساءً Peter Kahle [email protected]
كتب:

WadeShuler https://github.com/wadeshuler ، ماذا عن علامة الاستفهام
(؟) لم يتم تعقبها؟ لا أحب "أ" لأن لها دلالة مختلفة
git مما هو مقصود هنا ، على الأقل في ذهني.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/178#issuecomment-339084261 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AJHVkJJNzw89umFiPB0BmgQAZYJNXTHzks5svip7gaJpZM4GlYyH
.

عادل بما فيه الكفاية ، يجب أن يكون محايدا دينيا. لكن "غير معروف لنظام التحكم في الإصدار" باعتباره؟ له معنى بالنسبة لي. لكن N (للجديد) يمكن أن تعمل أيضًا ، ولا يمكنني التفكير في أي أعباء زائدة على ذلك ، على الرغم من أنني متأكد من أن شخصًا آخر سيفعل ذلك.

نعم ، jrieken ، جهودك موضع تقدير كبير! تبدو جيدة حقا! شارات خفية هي ميزة إضافية.

أنا مع WadeShuler و petkahl بشأن رغبتي في تغيير U إلى شيء آخر. "N" أو "؟" الشغل. ومع ذلك فأنا أميل نحو N كما لو كانت "جديدة" و "M'odified".

متحمس لرؤية هذا يأتي معا!

هل يعمل workbench.colorCustomizations.git.color.ignored للجميع؟
تم تحديث 1.18.0-insider اليوم وما زال اللون الذي تم تجاهله لم يتم التقاطه. أيضًا ، يبدو أن "_deleted_" و "_conflict_" لا تعمل بعد ... ربما مع تحديث الغد ،
لكن ما يزعجني هو اللون المتجاهل. يبدو اسم الملف هو نفسه ملف إصدار - غير معدل ، مما يعني عدم تطبيق لون خاص عليه.
ملاحظة: لا يحتوي الريبو الموجود في لقطة الشاشة على ملفات متعقبة على الإطلاق. جميع الملفات غير متعقبة. بمجرد إزالة "_shared.module.ts_" من .gitignore ، فإنه يظهر باللون البني (إعداد اللون الذي لم يتم تعقبه).

image

هل يجب أن تكون الشارة U رغم ذلك؟ أعتقد أن المجتمع يجب أن يكون له رأي. يجعلني U أول من أفكر في التحديث. أعلم أنه لم يتم تعقبه في مصطلحات Git

لقد استخدمنا حرف "U" من قبل ، فهذه ليست المشكلة الصحيحة لمناقشة ما هو أفضل ولكن أعتقد أن مستخدمي git يعرفون المصطلحات وبالنسبة لموفري SCM الآخرين يمكن / يجب استخدام الأحرف / الرموز الأخرى (وهذا هو الحال اليوم).

لم تتم إضافة هذه الميزة ، وأنا نشط في هذا الموضوع منذ ذلك الحين
بدأت تتحرك إلى الأمام. لقد ذكرت شارة "U" منذ البداية.

يدور هذا الخيط حول تطوير وتسوية الميزة بالكامل ، منذ ذلك الحين
إنها جديدة. إذا كان لون الخط ونمط الشارة وألوان الشارة جميعها مقبولة
في هذا الموضوع ، فكذلك الحروف.

إذن في أي مكان آخر ، خارج هذا الموضوع ، استخدمنا "U"؟

إذن في أي مكان آخر ، خارج هذا الموضوع ، استخدمنا "U"؟

تحقق من الثبات ، وليس المطلعين ، ومن وجهة نظر SCM مع git. ويستخدم U لأجلك ntracked الملفات.

WadeShulerjrieken يميز عرض SCM الحالي (1.17.2) ملف _untracked_ بحرف U رمادي ، وملف _ملف مضاف_ مع A أخضر . يظهر git status _ملفات مضافة (مرحلية )_ باللون الأخضر ANSI .

لذلك أفهم الالتباس مع حرف U أخضر لملف _untracked_. وأود أيضا أن نتوقع عيني إيذاء من الخضراء U الصورة خلط مع الأخضر والصورة.

ألوان Atom كلاً من الملفات الجديدة غير المتعقبة والمرحلة باللون الأخضر ، ويضع Xcode علامة على الملفات المضافة على أنها A طالما أنها ملف جديد. كلاهما لم يزعجني أبدًا (لكن حرف U الأخضر يفعل ذلك).

لذا سأقوم جميعًا باستخدام الأخضر A s للملفات الجديدة التي لم يتم تعقبها.

دعنا نواصل "U" مقابل "A" مقابل "؟" مناقشة في https://github.com/Microsoft/vscode/issues/36912. شكرا.

أنا موافق. أعتقد أنه من الأفضل الاستمرار في استخدام الأحرف في الواجهة اليوم. لا أحب حرف "U" أيضًا ولكني أعتقد أن هذا خارج نطاق طلب الميزة هذا. إذا تغير هذا ، يجب أن يتغير في البرنامج بأكمله.

حسنًا ، هذا خيط ضخم ولدي الوقت فقط لقراءته ، لذلك سأقول هنا فقط: آمل أن يكون هناك إعداد لتعطيل هذا. أفضل جميع أسماء الملفات بنفس اللون وعندما أحتاج إلى رؤية حالتها ، اكتب git status . :-)

هل تم التخلي عن هذا المنتج؟ يبدو أن يكون.

حاليًا ، يبدو أن للأولوية list.activeSelectionForeground على نمط حالة git ، لذلك لا يمكن رؤية ألوان حالة git في الملف المحدد. أجد هذه المعلومات مفيدة ، حتى في الملف المحدد حاليًا. هل هناك احتمال أن يأخذ تصميم حالة git الأولوية عندما يكون explorer.decorations.colors صحيحًا؟
لوحظ هذا السلوك على المطلعين 1.18 8dfa696.

حاليًا ، يبدو أن list.activeSelectionForeground لها الأسبقية على نمط حالة git ، لذلك لا يمكن رؤية ألوان حالة git في الملف المحدد.

في الواقع ، نفس الشيء هنا على أحدث المطلعين (تم التحديث للتو). عندما أنقر على اسم الملف في شجرة المشروع ، يتغير لون إدخال الملف (على سبيل المثال ، من الأصفر / المعدل إلى الحيادي). أعتقد أيضًا أن هذا سلوك محير إلى حد ما. يجب ألا يتغير لون الملف عندما ينقر المستخدم على الملف.

بالمناسبة ، نفس المشكلة مع قائمة الملفات المفتوحة ، عند النقر فوق الملف هناك ، يتم استبدال لون حالة git بلون التحديد المحايد.

بالمناسبة ، نفس المشكلة مع قائمة الملفات المفتوحة ، عند النقر فوق الملف هناك ، يتم استبدال لون حالة git بلون التحديد المحايد.

حسنًا ، لقد تم ذلك عن قصد لأن لون المقدمة المختارة غالبًا ما يتعارض مع ألوان الزخرفة. لا تبدو إضافة المزيد من الألوان ، مثل git.untrackedSelectedForeground و git.untrackedFocusedForeground جذابة للغاية بالنسبة لنا. لذلك تركنا الفوز اختيار اللون عند تحديد عنصر وعليه التركيز.

لا يبدو أن لدى Atom مشكلة في ذلك ....

atom-selected-color

ليست هناك حاجة لإعدادات جديدة ... سيتم تحديث السمات لتلائم ما إذا كان لون خلفية العنصر المحدد يتداخل. أولئك الذين يفشلون في القيام بذلك ، سيقرر المجتمع عدم استخدام هذه الموضوعات.

لم أتحقق من ذلك ، لكنني آمل أن "الشارات" (أي: U ، M) ، لا تزال ملفات svg. يجب أن تكون فقط نصًا خامًا يمكن تنسيقه / تلوينه.

بصراحة ، كان من المفترض أن يكون VSCode قد استخدم للتو أوراق أنماط لهذه الأشياء بدلاً من إعدادات التكوين غير المرغوب فيها. لقد أفرط في تعقيد عملية بسيطة إلى حد ما.

WadeShuler هناك تحديد وتركيز ولأنني أرى مؤشر محرر في لقطة الشاشة ، أعتقد أن العنصر الخاص بك محدد فقط وليس مركّزًا. في الحقيقة ، لا أرى فرقًا في Atom بين المحدد والمركّز. هذه هي الطريقة في VS Code

مختار لكن غير مركّز

screen shot 2017-11-01 at 16 16 35

مختار ومركّز
screen shot 2017-11-01 at 16 16 47

jrieken لقد تحققت مرتين ، وفي Atom الخاص بي ، تم تحديد النتيجة مقابل التركيز. لا يفقد أبدًا لون الخط yellow في نافذة مستكشف الملفات اليسرى. في لقطة الشاشة الثانية ، يتم فقد اللون red من test.foo ، وهي المشكلة.

لقد جربت نسق Atom الافتراضية الداكنة والخفيفة ، بالإضافة إلى حوالي 3 سمات أخرى. الإعداد الافتراضي (كما ترى في SS الخاص بي) هو Seti (كل من واجهة المستخدم والموضوع). لا يمكنني الحصول على Atom لإسقاط اللون yellow من مستكشف الملفات ، بغض النظر عما أفعله. إصدار Atom 1.21.2.

المحدد
selected

محدد ومركّز
selected-focused

خارج الصندوق ، يجب أن يحافظ VS Code على لون حالة git بغض النظر عن الحالات المحددة أو المركزة.

إذا كانت مشكلتك موضوعات ، فهذه ليست مشكلتك. هذه هي مسؤولية مطوري السمات للتحديث والاستيعاب.


في ملاحظة جانبية: لم أقم بسحب أحدث المطلعين أو عرض الكود ، لكن ملفات git ignored يجب أن تستخدم opacity ليس لون الخط لذا فهو دائمًا x أغمق من الملفات العادية ، بغض النظر عن لونها.

WadeShuler نشكرك على ملاحظاتك حول كيفية تعامل مديري

fernandofleury لم السمات بواجهة برمجة تطبيقات لإدارتها. منشوري لم يقل شيئا من هذا القبيل. لذا فإن تعليقك المزعج هو ببساطة غير صالح وغير مبرر.

jrieken قال:

حسنًا ، لقد تم ذلك عن قصد لأن لون المقدمة المختارة غالبًا ما يتعارض مع ألوان الزخرفة.

انا قلت:

إذا كانت مشكلتك موضوعات ، فهذه ليست مشكلتك. هذه هي مسؤولية مطوري السمات للتحديث والاستيعاب.

قد تكون المشكلة عبارة عن تعارض بين لون المقدمة (في الواقع ، لون الخلفية) لعنصر شجرة الملف / المجلد (عادي ، محدد ، مركز) ، وخيارات ألوان الخط لحالات git المختلفة.

هذا _ سيكون من مسؤولية مطوري السمات. ينبغي لها أن تختار كل من ألوان المقدمة من العناصر الموجودة في شجرة وألوان الخط لمختلف الحالات بوابة بحيث لا تتعارض.

على سبيل المثال: مطور القوالب لديه ThemeX ولون خطه للعناصر الموجودة في شجرة ملفات المستكشف هو yellow . حسنًا ، سيتعارض لون خطه الافتراضي مع لون حالة git الافتراضي yellow . لن تتمكن من معرفة الملفات التي تم تعديلها بعد الآن. لذلك ستكون هذه مسؤولية مطوري السمات! - الأمر نفسه ينطبق على لون الخلفية للعناصر المحددة / المحددة المركزة في شجرة ملفات المستكشف مقابل ألوان الخط لحالات git.

هل هذا مؤجل الآن؟

IljaDaderko لا أعتقد ذلك لأنه يظهر في الإصدار القادم من

IljaDaderko VSCode v1.18 خارج بالفعل ويتضمن التغييرات التي تمت مناقشتها هنا.

هل من المفترض أن تكون ألوان الملفات التي تم تجاهلها جزءًا من تحديث الإصدار 1.18؟ تقول المستندات إنه يمكن استخدام gitDecoration.ignoredResourceForeground لتلوين الملفات التي تم تجاهلها ، لكن حتى الآن لم أتمكن من رؤية ذلك يؤثر على أي شيء. على الرغم من ذلك ، فإن التلوين المعدل / غير المتعقب يعمل بشكل رائع. هذا على مستقر 1.18.0 ، windows.

نفس الشيء هنا (حول اللون المتجاهل). لم يعمل معي أيضًا ، منذ أن بدأ تطبيق Git بالكامل. باستخدام المطلعين.
كل ما يفعله gitDecoration.ignoredResourceForeground هو تجاهل الملفات المتجاهلة من التلوين :)

إنه يعمل بالنسبة لي ويبدو رائعًا.

أخيرًا إنه هنا

arxpoetica هذا ما أحصل عليه:
image

كيف يمكن أن يعمل مع البعض وليس للآخرين ، أنا لا أفهم. إنه مجرد إعداد واحد gitDecoration.ignoredResourceForeground
هل أنا الوحيد الذي لا يعمل من أجله؟ حقا لا أحد آخر؟ :) أوه ، و @ shurelia
هل قام أي شخص آخر (نحن ، المستخدمون) بالفعل باختبار إعداد اللون الذي تم تجاهله قبل أن يقول إنه يعمل؟

نظام التشغيل: Windows 10 PRO (1709)
VSCode: 1.19.0-insider (تم تحديثه للتو في وقت سابق)
نفس الشيء على جهاز الكمبيوتر المحمول الخاص بعملي وسطح المكتب المنزلي.

هل هو في المطلعين؟ كيف استطيع ان استعمله؟

مبروك للجميع!

nkkollaw في كل من المطلعين والمستقرة (1.18)

MrCroft برجاء مناقشة مشكلات git-ignore هنا: https://github.com/Microsoft/vscode/issues/37857

نظرًا لأننا قمنا بشحن هذه الميزة في أحدث بنية مستقرة لدينا ، فقد حان الوقت لإغلاق هذه المشكلة وإغلاقها. يرجى إنشاء قضايا جديدة لمناقشات الموضوع وتقارير الأخطاء. يتم تمييز المشكلات حول هذه المنطقة بعلامة file-decorations -label.

نشكرك جميعًا على التعليقات الرائعة والمستمرة التي جعلت هذه الميزة على ما هي عليه!

لتلخيص وتكرار تعليقي السابق .

screen shot 2017-10-24 at 19 51 36 2

شيئين

  • بشكل افتراضي ، هناك مزيج من اللون والباجدي.

    • تمكين / تعطيل الرموز بـ: "explorer.decorations.badges": true|false

    • تمكين / تعطيل الألوان باستخدام "explorer.decorations.colors": true|false

  • تظهر الألوان في شجرة الملفات ، وقسم برامج التحرير المفتوحة ، وفي عرض SCM
  • هناك ثلاثة ألوان لتبدأ. يمكنك تخصيصها في إعداد workbench.colorCustomizations . الألوان هي gitDecoration.modifiedResourceForeground ،
    gitDecoration.deletedResourceForeground ،
    gitDecoration.untrackedResourceForeground ،
    gitDecoration.ignoredResourceForeground و
    gitDecoration.conflictingResourceForeground
هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات