Vscode: Статус Git в проводнике

Созданный на 19 нояб. 2015  ·  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

Было бы здорово, если бы это каким-то образом было представлено как расширение. Меня беспокоит, что в некоторых случаях елка может быть немного загрязнена цветом и выглядеть как новогодняя елка. Или, если нет, по крайней мере, есть возможность включать и выключать его.

Да, я согласен. Я создал отдельную проблему, чтобы показать это в API расширения (см. №1394).

+1

Мне бы тоже понравилось. Вкладка Git очень удобна, но она предназначена для другой цели - наличие цветов, подобных в Atom, было бы очень полезным, чтобы сразу увидеть, что и где изменилось (с автоматическим распространением цвета в верхний каталог). Вероятно, это функция, которую мне больше всего не хватает в Atom.

Обычно у вас нет 10 или 100 незафиксированных измененных файлов, поэтому вряд ли это будет похоже на новогоднюю елку :)

Похоже, PR по этому поводу был закрыт. @bpasero @joaomoreno - есть ли обновления о статусе этой работы?

Нет обновлений ...

Большое спасибо за интерес к этому вопросу! В настоящее время он отнесен к невыполненной работе. Каждый месяц мы выбираем элементы из невыполненной работы, чтобы спланировать текущую итерацию. См. 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 есть ли такое расширение? Я не мог найти ни одного.

Скорее всего, у файлового проводника нет API для его модификации в соответствии с
git изменения. Мне подойдет расширение.

Пт, 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
.

@ rahul Never2far Нет, это было просто предложение, поскольку ранее предполагалось, что он может быть представлен как API расширения (что, я полагаю, тоже нормально).

Недавно решил перейти на VSCode и очень скучаю по этой функции

Пожалуйста, добавьте. Добавляет трение к производительности при попытке перепрыгнуть с Atom.

@KozhokarAlex @bhudgens и другие: щелкните значок с изображением большого пальца вверх в первом сообщении, чтобы показать разработчикам, что вы запрашиваете эту функцию. Они сортируют проблемы по поднятию большого пальца, чтобы определить, какие запросы функций являются наиболее популярными.

Как видно из сортировки такого рода проблем, на данный момент эта проблема является третьей наиболее востребованной функцией.

Пальцы вверх. Недавно пришел с 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.

Пожалуйста, поставьте отметку "Нравится" на первом посте.

У меня есть интересный пример использования и аргумент в пользу создания универсального API, который позволил бы плагину раскрашивать отдельные файлы и папки:

Старение файлов / папок аналогично старению Trello - я бы хотел, чтобы файлы и папки, к которым не прикасались долгое время (судя по истории git), исчезли, чтобы `` рабочий набор '' был более отчетливым и легче найти.

Почему: у меня есть большое количество крошечных проектов (думаю, куча скриптов для аналитического отчета), где 90+% работы больше не будут затронуты (но я не могу переместить старые вещи в подпапку, потому что это сломает много ссылки, указывающие на репо).

Если бы существовала конечная точка API для раскрашивания элементов дерева, я мог бы написать плагин, который считывает журнал git и окрашивает каждый файл / папку в соответствии с некоторым набором правил.

Так что насчет этого, не существует ли еще API, позволяющего создавать для этого расширения, или это будет реализовано как интегрированная функция?

Есть новости по этому поводу?

+1

+1

+1

Не могли бы вы, ребята, прекратить +1 и спамить в наших почтовых ящиках ???

Это совершенно бесполезно.

+1 к запрету спама xD

protip: отфильтровывать сообщения из github, где тело равно / match / lolwuts "+1"

вы не можете остановить этих людей.

@jmbelloteau, как @fredrikaverpil сказал ранее в комментариях, проблемы VSCode сортируются по количеству больших пальцев до исходного комментария. Так что комментирование «+1» вместо добавления реакции на первый комментарий действительно является спамом, поскольку это неправильный способ предоставления обратной связи и отправка всем только бесполезных писем. И вопреки добавлению реакции, она даже не будет учтена.

+1

Я так привык к этому и в Webstorm: D. Но, как я вижу, это, вероятно, будет разработано раньше, чем позже. Вот скриншот из Webstorm для вдохновения (после @abdonrd):

screen shot 2017-04-16 at 19 03 16

Ах, еще неотслеживаемые файлы отображаются красным цветом!

+1

Просто сегодня впервые попробовал код VS (исходящий от Atom), и одним из первых расширений, которые я искал, было выделение "git status" в представлении проводника. Вкладка «Управление исходным кодом» сама по себе очень хороша, но выделение папок / файлов позволяет мне быстро переходить к компоненту, над которым я работаю, без необходимости всегда оставлять мое дерево каталогов развернутым (очень полезно для кодовых баз FE, которые имеют тенденцию имеют более глубоко вложенные структуры).

В идеале было бы здорово, если бы цвета можно было изменять индивидуально.

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

+1

Некоторое время я искал хорошее приложение, которое напоминало бы мне пить воду.
Потом я понял, что подписан на эту ветку.
Держите +1, ребята, они больше не бесполезны 🚰

@mmazzarolo
Зачем нужно напоминание о питье воды? Разве недостаточно пить, когда хочется пить?

В любом случае, пожалуйста, прекратите +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-Team.

@AndreasGassmann круто ! Я посмотрю.

Последняя ключевая особенность не позволяет мне переключиться на vs code

Когда эта функция будет включена, я перейду на vscode

Я подписался на этот выпуск, потому что хотел бы знать, когда будет достигнут некоторый прогресс.
Все знают, насколько востребована эта функция, и на данный момент это вторая проблема, получившая наибольшее количество голосов :).

Если вам действительно нужна эта функция, просто проголосуйте за первый комментарий и избегайте добавления повторяющихся комментариев .

Для людей, которые считают, что эта функция необходима для перехода на VS Code. Я могу сказать, что это была первая функция, которую я пропустил при переходе с Atom, но, IMO, это небольшая цена за эту потрясающую IDE.
Более того, на прошлой неделе мне пришлось немного поработать в Atom, и мне очень не хватало git view 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 открытых вопросов. Придется проявить терпение.

(или пока воспользуйтесь хаком

+1
Делаем это потому, что просто послушайте разговор в чате разработчиков, и проблемы с большим количеством комментариев

@ karabaja4 отличная работа. Другой подход: как насчет запуска git status при инициализации и последующего обновления всякий раз, когда запускается событие onFileSave ? это было бы более эффективно?

возможно, мы могли бы настроить способ обновления статуса git.

+1 это было бы очень полезно, если бы добавили

@Kaijun Я не уверен, как мне это реализовать. Откуда взялось бы событие onFileSave ?

Если он поступает из кода при сохранении документа (при условии, что я знаю, как прикрепить к нему), файлы, измененные вне кода, будут проигнорированы, как и такие изменения, как перемещение и копирование файлов.

Если он исходит из логики наблюдения за папками, которая реализована в дереве решений, это нужно делать рекурсивно для всего дерева. Я не уверен, стоит ли это с точки зрения производительности.

@ karabaja4 Я думаю, что Код

Этого действительно не должно быть в очереди. В добавлении этой, казалось бы, небольшой функции есть очень реальная ценность. Счастье разработчиков идет своим чередом. Прискорбно видеть, что эта проблема имеет тысячи +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 Каждая новая проблема попадает в очередь и остается там, пока не будет решена. Я не думаю, что эту особенность вообще игнорируют. просто требуется больше изменений, чем вы думаете. Насколько я знаю, они хотят сделать это частью api расширений, и в настоящее время в дереве файлов отсутствует множество функций, чтобы это произошло.

Если вы отсортируете проблемы, подняв палец вверх, вы увидите, что эта проблема является второй по популярности, первая находится в стадии разработки и почти решена. Я почти уверен, что они начнут работать над этим, как только будет завершена вторая.

Хотя было бы здорово периодически обновлять эту тему.

При переключении с Atom, но в большом проекте, когда обновленные файлы не выделяются, становится сложно работать.
Вернуться на Atom, пока эта функция не станет доступной

Возможно, стоит упомянуть, что альтернативное / временное решение, которое сработает для меня ... состоит в том, чтобы дублировать древовидную структуру в представлении «Открытые редакторы». Обычно представление показывает мне «обновленные» файлы, но это просто дамп имен файлов, с которыми труднее работать, в отличие от того, если бы было ясно, где в проекте эти файлы находятся.

Есть обновления по этому поводу?

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

Я мазохистски мой собственный комментарий.

Я продолжаю пробовать VSCode, но поскольку этой функции нет, она не позволяет мне переключиться. Не осознавал, насколько я полагаюсь на эту функцию в Atom, пока не попытался переключиться.

Просто жду, пока это переключится на код VS из атома, надеюсь, что это скоро будет реализовано.

+1

прошло два года 。。。

и, что удивительно, ваш комментарий не изменил этого. Те из нас, кто заботится о развитии и потенциальном вкладе, подписываются на эти темы, ваш комментарий ничего не помог, и он отправил бесполезное электронное письмо 99 людям.

Эй, ты не получишь никаких результатов, если не попробуешь, верно?

Сначала мне его очень не хватало, и хотя было бы очень удобно иметь его, 'diff explorer' (третий значок в вертикальном меню) действительно мощный и очень полезный

+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

@matti плюс один

_Отправлено из моего HTC MSM8996 для arm64 с использованием FastHub _

@ibrokemypie минус два

Отправлено с моего HTC MKB826262 для arm32 с помощью Lolbug

Есть новости по этой функции?

+1

+1

+1

@ karabaja4 СПАСИБО man = D <3

+1

Ого, это должно было быть реализовано два года назад

@eosrei +1

+1

+1
Посмотрим правде в глаза; Я люблю VSCode, но вкладка Git действительно отстой

@ 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, и подумал, что моя жизнь так проста с цветными файлами в дереве файлов.

Изменить: только что нашел обходной путь. Добавление строки в один из файлов кода vs (<1 мин. Усилий) работает как шарм! https://github.com/karabaja4/vscode-explorer-git-status

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

Вы когда-нибудь видели, что можно использовать реакцию смайликов вместо сообщения +1 ?

Каждый раз, когда мы публикуем комментарии на github, все подписчики темы получают уведомления, а некоторые пользователи также получают электронные письма. Это своего рода разочарование при чтении электронного письма, написанного: +1 и вы можете видеть в этих комментариях, их много: -1 :.

Сообщество признательно, если мы все начнем использовать вместо этого реакции:
https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments

Я приношу свои извинения за любые нарушения, связанные с этой информацией, и за других, получивших это уведомление.

В других обсуждениях я читал, что Microsoft оценивает приоритет функции по количеству комментариев +1. Прошу прощения, если я сделал это неправильно, и это никоим образом не соответствует рейтингу функции. Я удалил свой комментарий. В любом случае, что с агрессивным отношением, братан? Вы могли бы указать на то же самое лучшим тоном @leocaseiro

Ваше здоровье.

Привет, @aecorredor , прошу прощения, если это прозвучало грубо.
Я не являюсь носителем английского языка, и, возможно, одно из моих переведенных выражений звучало плохо. Пожалуйста, помогите мне улучшить описание этого комментария. Стоит ли заменить слово раздражает? бесполезный? Спасибо.

PS: Я рад, что вы отредактировали мир, который я прочитал в моем электронном письме, потому что я, возможно, звучал грубо, но я никогда не собирался никого обижать.


Обновление: я заменил свой предыдущий комментарий, дайте мне знать, если звучит лучше. Спасибо

Привет @leocaseiro ,

Во-первых, извините за то, что написал это плохое слово. Я действительно понял
что языковой барьер, вероятно, был причиной путаницы. Но
да, я бы заменил эти два слова чем-то более похожим на:
"Пожалуйста, мы все пытаемся улучшить общий опыт работы с github для
открытые вопросы / запросы функций, и было бы неплохо, если бы люди начали использовать
реакции смайликов вместо комментариев типа «+1», которые просто создают
ненужные накладные расходы в потоке и запускать электронные письма, которые на самом деле не
вносить какой-либо значимый вклад. Перейдите по этой ссылке, чтобы узнать, как
Смайлики работают: {Ссылка здесь}

Ура и без обид.

Лучшие.

В понедельник, 18 сентября 2017 г., в 23:44, Лео Касейро [email protected]
написал:

Привет @aecorredor https://github.com/aecorredor , прошу прощения, если озвучил
грубый.
Я не являюсь носителем английского языка и, возможно, один из моих переводчиков
выражения звучали плохо. Пожалуйста, помогите мне улучшить описание для
этот комментарий. Стоит ли заменить слово раздражает? бесполезный? Спасибо.

PS: Я рад, что вы отредактировали мир, который я прочитал в моем электронном письме, потому что я могу
звучало грубо, но я никогда не собирался никого обидеть.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на 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 не @dseipp, который никогда не объединялся. С его пиаром все еще что-то не так (я думаю, не хватало поэтапной поддержки?), Поэтому я исправил это.

Итак, если вы хотите, чтобы это работало намного лучше, ознакомьтесь с моей сутью: https://gist.github.com/WadeShuler/1637073371ad126779076344c34278f3

@ikatyang : извините, это означает, что эта функция будет представлена ​​в октябре (2017 г.) ..?

@nkkollaw ссылка была из этого комментария: https://github.com/Microsoft/vscode/issues/34160#issuecomment -331066864

В комментарии просто просили обсудить вещи, связанные с этой проблемой, здесь, а не в «Плане итераций» (и просили обсудить их на английском языке).

Ах, понял @tiangolo , спасибо.

Я постараюсь смириться с Atom, пока не появится API для реализации этой функции (извините, я недостаточно хорош, чтобы помочь с этим).

Я работаю над обновлением внутри самого проекта.
На данный момент я сделал доказательство того, что концепция работает, но я не передаю tslint, потому что мне все еще нужно понимать слои, чтобы разместить все в нужном месте.
Я выложу здесь несколько обновлений, и если кто-то захочет мне помочь, я позже добавлю ссылку на свой запрос на перенос, так что вы можете помочь.

Планируется в октябре 2017 года итерация !! 👍

У нас есть первая версия этого. Все уверены, что это произойдет в октябре.

oct-09-2017 18-09-19

Еще немного информации:

  • Цвета будут определены в темах, что означает, что они могут быть адаптированы к вашему вкусу.
  • Будет настройка для включения / отключения этого
  • Это не только для контроля версий. Мы также изучаем возможность выделения ошибок / предупреждений в файловом проводнике (см. № 782), и мы думаем о том, чтобы показать это авторам расширений.

Открытые вопросы:

  • Достаточно ли использовать только цвет? Должна ли быть также текстовая подсказка и / или иконка?
  • Какой дочерний статус должен выбрать родитель? Следует ли это учитывать по важности? Это легко с ошибками и предупреждениями, но что важнее: измененный, неотслеживаемый или проигнорированный файл?
  • Должны ли мы показывать эти художественные оформления файлов также в сегменте «Открытые редакторы» и / или в средстве выбора файлов и т. Д.?

Я буду обновлять этот выпуск, пока что-то происходит. Как всегда, используйте эмоции вместо комментариев «+1». Спасибо и удачного кодирования!

Лично мне достаточно того, что я вижу на изображении выше. Выглядит отлично и спасибо!

Кажется, не хватает файлов, игнорируемых .gitignore темно-серым цветом?

Вы не меняете цвет (серый) родительской папки только для игнорируемого файла внутри. Вы только закрашиваете его серым цветом, ЕСЛИ игнорируется сама папка. Пожалуйста, посмотрите мой комментарий / исправьте несколько комментариев. Он заставляет Git сбрасывать статусы и определяет, каталог это или файл. Простое добавление классов к файлам / папкам в дереве файлов будет работать ... Например, «git-status-modified» или «git-status-added». Тогда темы могут творить чудеса.

Было бы хорошо, если бы вы, ребята, позволили нам тянуть то, над чем вы работаете, чтобы мы могли играть с этим и создавать PR. Честно говоря, если что-то не так, люди, вероятно, перестанут использовать Code, если жизнеспособное решение не может быть достигнуто в разумные сроки. Многие (в том числе и я) покинули Atom по аналогичным причинам.

Я также думаю, что если есть ошибки, возможно, стоит поставить точку перед или после имени файла в дереве. Это было бы ненавязчиво, позволило бы темам стилизовать их и не мешало бы выделению цвета Git.

Да, это ДОЛЖНО быть открыто для разработчиков расширений! Это уже должно было быть сделано. Почему бы нам не иметь контроль над деревом файлов, чтобы создавать интересные расширения или исправлять то, чего вы, ребята, не делали?

Кажется, не хватает файлов, игнорируемых .gitignore, темно-серыми?

Конечно, работа продолжается, и все происходит по очереди. Игнорируемые файлы появятся также в октябре.

Было бы хорошо, если бы вы, ребята, позволили нам тянуть то, над чем вы работаете, чтобы мы могли играть с этим и создавать PR.

Конечно, дело в ветке 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/*

Мое сообщение было ответом на ответ WIP @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/ выглядит следующим образом (в настоящее время требуется 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 правила CSS. Поэтому я думаю, что при этом мы должны пойти дальше и сделать title в элементе HTML для каталогов, включив в него завершающую косую черту. Вы можете увидеть, о чем я говорю, на этом скриншоте:

vsc-dir-trailing-slash

Да, ваш комментарий был пассивно-агрессивным, так как вы были грубым / язвительным / дерьмовым, не сказав на самом деле слов. К тому же ты ошибался. Никто ничего не сказал о детях, и мы даже не об этом.


@jrieken
Как работает моя установка Atom: «отредактировано» имеет приоритет над «добавленным». Удаление файла не показывает статуса. Статус "постановочный" отсутствует. Я думаю, что другим следует проверить свою настройку Atom и посмотреть, верно ли это и для них, и что это не только моя настройка. Было бы хорошо добавить код для каждой ситуации и позволить пользователю редактировать его, чтобы он работал так, как он хочет.

Может быть, добавить несколько классов, чтобы родительские каталоги на всем протяжении дерева имели «git-status-added» и «git status-modified». Может быть, даже добавить "git-status-deleted", если что-то было удалено под ним.

Затем просто используйте CSS, чтобы сопоставить их. Если вам нужен другой цвет для .git-status-added.git-status-modified , вы можете сделать оранжевый шрифт с зеленым подчеркиванием (оранжевый для изменения, зеленый для добавления). Если бы у него был только класс .git-status-added , сделайте шрифт зеленым.

Это не имеет особого значения, если вы добавите к ним классы, каждый может создать какой-нибудь CSS, как ему заблагорассудится. Тем не менее, вам может потребоваться "довольно хороший" стандартный стиль "из коробки".

Я вытащу эту ветку, когда у меня будет время, и посмотрю.


Как обрабатывать ошибки lint И статус git?

Atom помещает красную волнистую линию под именем файла, как вы можете видеть здесь:

image

Я думаю, мы должны добавить класс, такой как lint-error к тому же элементу, что и статус git, который мы (и темы) можем переопределить с помощью наших собственных таблиц стилей.

Итак, div для того же элемента в дереве файлов, который я использовал в качестве примера выше (backend / web / assets / 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;
}

Ребята, у вас есть Slack? В коммите много отредактированных файлов. Я ищу, где именно вы применяете цвет статуса git к дереву файлов. Это в /extensions/git/src/repository.ts ?

Спасибо всем и спасибо за разъяснение правил изменения, неотслеживаемых и игнорируемых файлов. Завтра инсайдеры выпустят раннюю версию этого.

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 который дает и значки, и цвета.

Я бы хотел, чтобы были только цвета, а не значки. IE "старое" поведение scm.fileDecorations.useIcons : false и scm.fileDecorations.useColors : true

Я пробовал поэкспериментировать с explorer.decorations.badges и explorer.decorations.colors но они, похоже, не действуют.

РЕДАКТИРОВАТЬ:
Я использую инсайдерскую версию 1.18, Commit f1ee80be081b0d ... в Windows 10
(Было бы неплохо, если бы текст в диалоговом окне «О нас» выделялся, чтобы его можно было скопировать)

Спасибо, что собрали это,

Пару мыслей:

  • похоже, что выбранный цвет по-прежнему старый серый, а не цвет статуса
  • согласился с возможностью иметь значки или нет (за @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

Со следующими инсайдерами, вероятно, завтра 19-го, будет специальный рендеринг для игнорируемых файлов ( git.color.ignored ), а цвета / значки будут отображаться в разделе «Открытые редакторы». Я обновил https://github.com/Microsoft/vscode/issues/178#issuecomment -335511695 соответственно.

@jrieken Замечательно ! Как насчет цветового ключа для переднего плана значков 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.

@jrieken Замечательно ! Как насчет цветового ключа для переднего плана значков git?

@equinusocio Не беспокойтесь, это произойдет, но нужно подумать. Это запланировано на октябрь

@jrieken Спасибо !. Я что-то пропустил .. значки папок тоже получают измененный / добавленный цвет? Есть ли новый ключ, который нужно добавить в тему значков, чтобы установить разные значки для папок при редактировании / изменении git?

@jrieken - Проблемы в 1.18. Я хочу сказать вам спасибо за вашу работу до сих пор. Я только что протестировал инсайдеров v1.18. Я просмотрел ветку выше, так что извините, если у вас уже есть что-то в работе для 1.19, чтобы решить то, что я упоминаю ниже.

1) Статус «добавлен» в дереве файлов выглядит как «обновлен и не объединен» со значком «U». Добавленные файлы должны иметь значок «А».

2) Нет варианта цвета для git.color.added

3) Для git.color.ignored нет варианта цвета.

4) (Глюк) Считает "добавленные" файлы "неотслеживаемыми". Я проверил "добавленный" файл, и похоже, что в html он не отслеживается. (заголовок span говорит "не отслеживается", а класс - monaco-decorations-style-32 , значок "U"). Это очевидно при изменении цвета workbench.colorCustomizations на git.color.untracked , поскольку он управляет предполагаемыми "добавленными" файлами.

5) Поддержите статус «R» для «переименовано» или «перемещено», добавьте значок «R» и добавьте соответствующую настройку git.color.renamed .

Спасибо, с нетерпением жду возможности попробовать 1.19 👍

@danjjl Есть ожидающий PR для # 7829. После этого подмодули git получают окраску.

Существует потенциальная проблема в том, что если подмодуль изменяется, я не знаю, будет ли он (каталог, который является корнем подмодуля) обрабатываться как цвет статуса каталога в основном репозитории git или другой цвет на основе содержащихся файлов.

То есть я не знаю, будет ли цвет каталога подмодуля основываться на «git status» в родительском каталоге или в подмодуле. В любом случае это может не иметь значения.

@jrieken У вас есть группа Slack или еще где-нибудь, чтобы обсудить эту проблему? Я могу помочь :) Мне удалось вытащить, разработать и отладить текущие изменения из основной ветки. Я исправил «добавленные» файлы, отображаемые как «U», и даже добавил «поэтапную» поддержку. Так как это был мой первый раз в проекте, я возвращаю его к мастеру и делаю это снова. Я сделал кучу изменений и хочу действовать как хирург, а не ядерщик.

Почему есть чеки на raw.x + raw.y за которыми следуют чеки на raw.x затем на raw.y ? Кажется, это приводит к тому, что он соответствует 2 различным статусам.

Почему есть 2 константы статуса для ADDED / INDEX_ADDED , MODIFIED / INDEX_MODIFIED и некоторых других? Я понимаю все различные статусы git, но имело бы смысл обрабатывать их для конечного пользователя, а не называть статусы Git. ADDED следует использовать для того, что у вас есть сейчас как UNTRACKED чтобы затем иметь код настроек git.color.added . Я думаю, что некоторые из этих констант состояния дублируются, и их следует упростить и очистить.

Статус git _M <- underscore = space / ничего, будет соответствовать raw.y а у вас, ребята, это будет INDEX_MODIFIED . Это неверно, статус, в котором x = ничего, а y = M означает staged .

Почему-то иногда случайно, кажется, не отражает изменений. Кроме того, похоже, что изменения статуса git рекурсивно сканируются сверху вниз. Если у вас большой проект, вы можете наблюдать, как статус "игнорируется" просачивается вниз по вашим папкам / файлам. Чтобы ускорить его, более глубокая навигация, казалось, включила его для этого каталога и закрасила их серым цветом. - Сильно ли этот процесс замедляет работу системы / VSCode? Кто-нибудь тестировал это? На самом деле нет необходимости просматривать каждый файл / папку, когда родительский элемент игнорируется. Дети должны получить свои статусы от своих родителей. - Если у вас есть 5000 файлов ignored но все они находятся в 2 каталогах (то есть: node_modules, vendor), тогда мы не должны обрабатывать 5000 файлов, а только 2 каталога, которые контролируют внешний вид своих дочерних файлов.

Позже сегодня я повторю свои изменения и сделаю 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, Index unmodified (то есть не поэтапно). Если, конечно, вы не видите дубликат этого кода в другом месте.

@petkahl Спасибо, я знаком с кратким форматом Git Status . Я использовал его несколько недель назад, чтобы исправить свое

Возможно (как-то) получить _M (подчеркивание = пробел). Я не уверен, как, почему, когда ... Я получил это сегодня ранее (а также несколько недель назад, когда работал над своим Gist):

➜  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/

Когда я проводил исследование для своего Gist, я думаю, что пришел к выводу, что для постановки можно получить «A_» и «_M». Я также нашел сайт, на котором статус был разбит намного яснее, чем в документации по git-status, я просто не могу найти его снова, lol.


Вы также можете получить "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, совершая и изменяя. Это означает, что он не изменился (_ = пробел) в индексе, но был изменен в рабочем дереве.
так:
Создать файл: ??
git добавить файл A_
git commit (не в статусе, а в эквиваленте пробела)
изменить файл: _M
git добавить файл M_
измените его снова: MM

У меня действительно нет мнения о значках, когда их два. Я никогда не регистрируюсь, не глядя в окно состояния, которое четко разбивает его, как и в случае с обычным статусом git. Может быть, просто параметр, позволяющий выбрать приоритетное? Я видел аргументы в пользу обоих. Или два значка, наверное. Будет ли то же самое с окраской?

Я добавил поддержку Staged . Вы можете увидеть изменения здесь: WadeShuler / vscode: gitstatus-fix . Я также улучшил внешний вид некоторых значков на вкладке Git Status, сделав их немного больше.

По какой-то причине он удалил затемнение / игнорирование каталога vendor , но его содержимое внутри все еще неактивно и игнорируется. Я не понимаю, почему моя простая модификация перестала окрашивать каталог vendor серый цвет? Это единственная проблема, связанная с тем, что я только что сделал, и почему я еще не опубликовал PR ...

git-status-staged-updates

Если будут включены поэтапные цвета / значки файлов, это обязательно должно быть необязательно. Лично я бы предпочел не видеть в моем списке выделенный цвет, отличный от исходного нового / измененного цвета.

Как только вы начнете включать поэтапное, это может быстро усложниться, поскольку есть возможность включить все комбинации и перестановки new / new-staged / modified / modified-staged / modified-staged-modified / new-staged-modified и т. Д. , что приведет к огромной матрице цветов и неразберихе.

Я голосую, что мы не слишком усложняем дело.

Я согласен @dseipp. Это точная причина, по которой я не объединил поддержку поэтапных файлов в моем первоначальном взломе, когда я его сделал, поскольку я не видел смысла в раскрашивании поэтапных файлов.

Цветовая подсветка позволяет мне быстро находить новые / измененные файлы в проводнике. Если я обрабатываю некоторые файлы, это обычно перед фиксацией или если я иным образом с ними покончил, поэтому мне не нужно их раскрашивать обычным образом.

Если мы добавим цвет для каждого возможного типа статуса git, файловый менеджер начнет выглядеть как рождественская елка, и будет очень сложно увидеть, что на самом деле происходит.

@jrieken Еще один отчет об ошибке, произошедший с самыми последними инсайдерами:

  • Версия VSCode: Код - Инсайдеры 1.18.0-insider (82dcf9835265cd0a45ec135587ae2a82673f1c8f, 2017-10-20T04: 24: 25.632Z)
  • Версия ОС: Windows_NT x64 10.0.15063

По сути, VS Code время от времени "забывает", что некоторые файлы изменены и их нужно соответствующим образом раскрасить. Например, у меня на данный момент изменено 6 файлов. Код VS (правильно) показывает цифру "6" на кнопке git. Но в дереве файлов проекта я вижу только ОДИН файл желтым цветом, остальные пять файлов выглядят так, как будто они не были изменены. Что интересно, все 6 файлов правильно раскрашены в разделе открытых редакторов.

@dseipp Это может быть необязательно. Тем не менее, вы никогда не увидите "постановочный" цвет, пока не подготовите файлы ... Так что его даже не видно в 99% случаев, и это не должно никого беспокоить ...

@ karabaja4 Я не согласен с тем, что в этом нет

Цветовая подсветка позволяет мне быстро находить новые / измененные файлы в проводнике. Если я обрабатываю некоторые файлы, это обычно перед фиксацией или если я иным образом с ними покончил, поэтому мне не нужно их раскрашивать обычным образом.

Так что даже если эта функция будет добавлена, она не должна вас беспокоить ...

Возможность видеть поэтапные файлы помогает выбрать то, что вы собираетесь совершить. Если у нас было изменено 100 файлов, то необходимо сгруппировать их, мы можем просмотреть дерево файлов и легко увидеть, что поставлено, и поймать те, которые мы пропустили, чтобы убедиться, что они находятся в одной фиксации.

Сколько раз вы фиксировали несколько файлов, а потом понимали, что пропустили один? Затем у вас есть 2 варианта: изменить последнюю фиксацию, чтобы включить пропущенные файлы, или сделать новую фиксацию. Когда вы работаете с командами, их проще и проще держать в одном коммите.

На этапе подготовки не имеет значения, был ли файл добавлен, изменен или что-то еще.


Если честно, то, как Visual Studio Code обрабатывает Git, коряво и ошибочно. Большие файловые деревья, вы можете буквально наблюдать, как раскраска капает по файлам / папкам. Случайно выпадает раскраска ...

Я думаю, что вся поддержка Git была переписана с нуля.

Я также хотел бы выразить свою поддержку поэтапной раскраски файлов (необязательно, если я могу ее включить).

Вот мой рабочий процесс: я начинаю работать над некоторыми функциями / исправлениями, довожу их до состояния «ОК», что означает, что код более или менее работает, но требует некоторой доработки / настроек / очистки или рефакторинга. В этот момент я вносю свои изменения. Затем выполните очистку и рефакторинг. Если рефакторинг терпит неудачу или становится слишком беспорядочным, я просто возвращаюсь к поэтапному состоянию.

Возможность видеть, какие файлы я модифицирую в настоящее время, очень полезна, и когда я делаю изменения, я не хочу терять всю эту информацию и переходить к простому дереву без цветов.

@vvs Я согласен, что постановочные файлы не теряют цвет. Цвета должны оставаться до фиксации. Я бы просто предпочел, чтобы поэтапный цвет сохранял новые / измененные цвета, а дополнительные поэтапные цвета оставались необязательными.

Возможно, Staged может сохранить те же цвета, но просто добавить какой-то свет или жирный шрифт, чтобы придать ему контраст.

Было бы полезно взглянуть на предшествующий уровень техники ... не помню, чтобы видел поэтапный индикатор, но, возможно, времена изменились

Действительно ли нужны значки в проводнике для измененных / неустановленных / ... файлов? У меня проблемы с вниманием, поэтому цвета и значки меня очень легко отвлекают. Разве он не может быть необязательным и отключен по умолчанию? Я единственный, кто отвлекается на них?

С точки зрения пользовательского опыта, иногда меньше значит больше, и многие не будут беспокоиться о возможности отключить эти вещи и будут продолжать страдать или даже менять редакторов. Я думаю, что было бы хорошо подумать над этим и решить, действительно ли это необходимо для лучшего UX (что, как я полагаю, является сутью этих значков).

* У меня не было времени читать все комментарии по этой проблеме, поэтому, пожалуйста, скажите мне, если то, о чем я прошу, уже обсуждалось, и я не тороплюсь, чтобы прочитать все, как только смогу, чтобы соответствовать что было сказано. Спасибо.

Я думаю, что было бы хорошо подумать над этим и решить, действительно ли это необходимо для лучшего UX (что, как я полагаю, является сутью этих значков).

https://github.com/Microsoft/vscode/issues/178#issuecomment -336960308 - вот почему по умолчанию у нас есть цвета и значки. Согласились, что это делает пользовательский интерфейс немного более загроможденным, открытым для предложений, которые являются доступными / инклюзивными, но также гладкими и чистыми.

@jrieken Спасибо! Не могли бы вы указать мне на коммит, который ввел значки? Я постараюсь найти что-то, что было бы полезно для обеих проблем (трудности с восприятием цветов или незнание, для чего они нужны, а также проблемы с отвлечением).

vscode-git

@jrieken Давайте возьмем страницу из Xcode и сделаем значки более тонкими.

Значки полезны для подсказки новичкам, но после изучения цветов они становятся беспорядочными.

Для дополнительной защиты велосипеда я предпочитаю значки, окрашенные в git.color.ignored (_left_ выше), потому что они имеют одинаковую визуальную значимость. То есть исчезнуть, но не исчезнуть, если вы мне понадобитесь.

Если мы реализуем тонкие значки, значки боковой панели Source Control должны быть обновлены для единообразия.

В каком направлении идет обсуждение значка, может ли дизайн значка хотя бы соответствовать таковому на боковой панели Git? Кажется немного бессвязным иметь один дизайн для боковой панели Explorer и другой для боковой панели Git.

Мне нравится предложение из

Если мы реализуем тонкие значки, значки боковой панели Source Control должны быть обновлены для единообразия.

Это произойдет, это у меня в планах на октябрь.

Я обновил https://github.com/Microsoft/vscode/issues/178#issuecomment -335511695 последними снимками экрана и названиями цветов. Кроме того, с помощью завтрашнего инсайдера мы будем показывать те же значки во вьюлете SCM, но без цветных меток. Вот так

oct-24-2017 19-55-03

Выглядит лучше

Должен ли значок быть U ? Я думаю, сообщество должно взвесить. U заставляет меня сначала подумать updated . Я знаю, что это untracked в терминологии Git, но я думаю, что A более уместно, особенно для тех, кто не знаком с основными терминами, что U не отслеживается. - Я лично голосую за A за добавленные. Например, он был добавлен в ваш репозиторий.

Затем поддержка staged (необязательно через настройки), и это довольно близко 👍

@WadeShuler , как насчет вопросительного знака (?) Для неотслеживаемых? Мне не нравится A, поскольку он имеет другой оттенок для git, чем здесь подразумевается, по крайней мере, в моем понимании.

Изменить: Но я согласен, что U может сбивать с толку.

Думаю, мне бы понравился вопросительный знак. Однако я не думаю, что Код
поддерживает только Git, не так ли? Я не думаю, что мы должны смотреть на это визуально в
редактор как «Git», но больше контроля версий в целом.

Как бы то ни было, мне действительно не нравится "U" lol

Во вторник, 24 октября 2017 г., в 14:20 Питер Кале [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 (для New) тоже может работать, и я не могу придумать никаких перегрузок для этого, хотя уверен, что это сделает кто-то другой.

Да, @jrieken , ваши усилия очень

Я с @WadeShuler и @petkahl, желая изменить U на что-то другое. Буквы «N» или «?» Работа. Однако я склоняюсь к N, так как тогда это было бы 'N'ew и' 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 файлов.

@WadeShuler @jrieken Текущее представление SCM (1.17.2) помечает _отслеживаемый файл_ серой буквой U , а _ добавленный файл_ - зеленой буквой git status показывает _добавленные (поэтапные) файлы_ зеленым цветом ANSI .

Итак, я понимаю путаницу с зеленой буквой зеленого U с зеленым A s.

Atom окрашивает как неотслеживаемые, так и поставленные новые файлы в зеленый цвет , а Xcode отмечает добавленные файлы как A, если это новый файл. И то, и другое меня нисколько не беспокоило (а вот зеленая буква U действительно).

Так что я всецело за то, чтобы использовать зеленые буквы

Давайте продолжим "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 по умолчанию, а также еще около трех тем. Мое значение по умолчанию (как вы видите в моем SS) - это Сети (как пользовательский интерфейс, так и тема). Я не могу заставить Atom удалить цвет yellow из файлового проводника, что бы я ни делал. Atom версии 1.21.2.

Выбрано
selected

Выбранные и сфокусированные
selected-focused

По умолчанию VS Code должен сохранять цвет статуса git независимо от выбранного или сфокусированного состояния.

Если ваша проблема связана с темами, это не ваша проблема. Разработчики темы несут ответственность за обновление и адаптацию.


Кстати, я не проверял последних инсайдеров и не просматривал код, но файлы git ignored должны использовать opacity не цвет шрифта, поэтому всегда x темнее обычных файлов, независимо от их цвета.

@WadeShuler благодарит вас за отзыв о том, как менеджеры тем должны вести свой бизнес! Как посмела команда VSCode предоставить API, чтобы помочь им в этом? Эти ленивые разработчики!

@fernandofleury Никто ничего не сказал о том, что менеджерам тем не предоставляется API для управления. В моем посте ничего подобного не говорилось. Так что ваш язвительный комментарий просто недействителен и необоснован.

@jrieken сказал:

Что ж, это было сделано специально, потому что цвет переднего плана часто конфликтует с цветами декораций.

Я сказал:

Если ваша проблема связана с темами, это не ваша проблема. Разработчики темы несут ответственность за обновление и адаптацию.

Проблема может заключаться в конфликте между цветом переднего плана (на самом деле, это цвет фона) элемента дерева / папки файлов / папок (нормальный, выбранный, сфокусированный) и выбором цвета шрифта для различных статусов git.

За это _обязательно_ несут ответственность разработчики темы. Они должны выбрать как цвета переднего плана элементов в дереве, так и цвета шрифта для различных статусов git, чтобы они не конфликтовали.

Например: у разработчика темы есть ThemeX, и его цвет шрифта для элементов в дереве файлов проводника - yellow . Что ж, его цвет шрифта по умолчанию будет конфликтовать с цветом статуса по умолчанию yellow git. Вы больше не сможете определить, какие файлы были изменены. Так что это ответственность разработчиков темы! - То же самое для цвета фона для выбранных / выделенных элементов в дереве файлов проводника по сравнению с цветами шрифта статусов git.

Это сейчас отложено?

@IljaDaderko Я так не думаю, так как он появится в грядущем Release Note v1.18 следующей стабильной версии. Вопрос может заключаться в следующем: будет ли это закрыто или предстоит еще работа?

@IljaDaderko VSCode v1.18 уже вышел и включает изменения, обсуждаемые здесь.

Являются ли игнорируемые цвета файлов частью обновления v1.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 .

Всем спасибо за отличные и постоянные отзывы, которые сделали эту функцию такой, какая она есть!

Подведем итог и повторим свой предыдущий комментарий .

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 рейтинги