GitHub Pull Requests в Visual Studio Code

[Leopotam]

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

[Leopotam]

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

[betatank]

Посмотрите в строну Cement. Все ваши проекты продолжат быть отдельными git репозиториями, сможете легко их обновлять и ссылаться на нужную ветку зависимости в своём проекте. Единственное, что автоматическая сборка зависимостей только для C#.

[Leopotam]

Вряд ли MS запилят фичу, на которую нет спроса. Самое время создать такой issue?

А вы уверены, что искали и не нашли? Вот, 2 года назад: github.com/Microsoft/vscode/issues/7829
Ну и комментарии соответствующие (спустя год после открытия issue):

This feature is a basic usage of git, i really don't understand why the project maintainers haven't yet implemented it. Maybe they don't use anymore VSCode at work?

[Leopotam]

Нет, вся ветка комментариев про git modules как про часть git-интеграции в vscode:

• https://git-scm.com/book/ru/v1/Инструменты-Git-Подмодули
• https://habr.com/post/60860/

[Kobalt_x]

Так issue закрыта же, даже гифка где показывается новый интерфейс

[Leopotam]

Закрыть — не значит реализовать. Они по сути смерджили в свой реп базовый функционал, реализованный через PR членом community, после чего благополучно посчитали, что все работает как надо и issue можно закрыть. Если почитать комменты, то это не так.

[Kant8]

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

[Sly_tom_cat]

Вот только «располнел» VSC за последнее время неслабо, дома на 4GB оперативки уже трудно его запускать стало…

[Leopotam]

Можно попробовать поотключать builtin-расширения, может поможет. Делается через вкладку расширений и пункт меню "Show Built-In Extensions". Ненужные можно деактивировать.

[rd_nino]

Это не VSC располнел, а его расширения.
Результат развивающейся экосистемы в самом начале пути — некоторые расширения не оптимизированы и кушают память.
Для проверки — удалите расширения и оставьте только два-три самых нужных. Аппетиты по памяти у VSC сразу уменьшатся.

[Sly_tom_cat]

Так ненужных я и не ставил. Стоит по минимуму всего для GO и Python.
Но раньше работало, а теперь еле ворочается.

[dimka11]

Раньше он был 32-битным, а сейчас 64.

[QtRoS]

Да нет, я бы не сказал, что медленно работает и много памяти — сейчас открыты исходники Go 1.11, потребляет всего 300мб.

[SanSYS]

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

Я попробовал, мне даже очень понравилось
Не все фичи доступны, конечно
Например фото через Ctrl+v не приложить в (

[maydjin]

deleted