Комментарии 51
И страницы, которые хостятся на github pages недоступны =\
Сайты на гитхаб.ио открываются. Пример: https://jaydi85.github.io/xmage-web-news/news.html
Вы бы хоть ссылку на https://www.githubstatus.com/ оставили, а то пост вообще ниочём.
лёгкий, надёжный сервис GitHub - говорили они..
Майкрософт уже навели свои порядки?
К сожалению, GitHub отучает своих пользователей от того, что git является DVCS. Печально видеть, когда у команд разработчиков чуть ли не останавливается работа, если случается очередной инцидент в GitHub.
Я предпочитаю всегда иметь доверенный mirror, который в случае проблем с основным репозиторием просто берет на себя роль "главного". Потом изменения подтягиваются вернувшимся в строй основным репозиторием.
С CI и баг-трекером уже посложнее. Развернуть полноценную локальную копию GitHub позволяет только за большие деньги. Так что, сопоставляя риски и объем работ, предпочитаю другие решения, между которыми уже отлажена миграция в случае аварий или даже блокировок.
GitLab CE/CI пользуетесь?
С удовольствием пользуемся, отличный self-hosted git, да еще и с приятным CI.
Да. На некоторых проектах в качестве CI — Jenkins.
Мне нравится идея Fossil, много читал о нём, но пока что не решался его брать в проекты. Надеюсь, что однажды попробую Fossil на практике.
Fossil всем хорош, кроме отсутствия стандартного хостинга для него, наподобии того же github.
Во первых, chiselapp же. Во вторых – если на подобии github, то будет и все недостатки github из за которых мы и ищем альтернативу.
Почему люди не хостят свои git проекты сами? А потому что это очень сложно для поддержки. Нужны несколько веб приложении, которые устанавливаются отдельно на сервере, настраиваются отдельно и поддерживаются отдельно. По сути, каждый должен развернуть свой GitHub/GitLab, что чаще всего не оправдано.
A вот, с fossil все эти сложности отсутствуют в принципе. Запустил на сервере бинарник и все работает из коробки.
Если нет — то совместимость с современным миром будет нарушена, такой себе vendor lock.
Не совсем. В смысле, в fossil хранится намного больше информации чем в git. Сделать однозначное соответствие просто невозможно. Обычно делают просто зеркало на git.
Сам код, синхронизировать более менее возможно. А багтракер, вики, форум и т.д. увы у git соответствующая функциональность просто нет.
Есть еще Gitea - маленький GitLab. Очень приятный, для чего-то небольшого в самый раз.
Поддерживаю. Очень классная и лёгкая штука.
Fossil пробовал, но слегка недопонял его концепцию с отдельным файлом БД. Непонятно, где его хранить.
Специфика: git-flow и прочие подходы с толпой персональных веток на сервере — не для него. Основной метод — короткие почти безымянные цепочки коммитов поверх длительных веток (master/main/trunk, релизные ветки). Зато комментарии, например, на каждую строчку и на коммит отдельно (а не как местами можно написать только на весь pull request).
Ещё недостаток — логика кастомизации оценок делается хуками на Prolog с хитрыми правилами раскрытия — освоить ой нетривиально. (Или я отстал и сделали удобнее?)
Блин, я то думал опять Idea глючит, повисла намертво
Idea виснет от неработающего гитхаба?
Ну да, сделал pull - только перезагрузка спасла.
Это такой современный тренд - обмен по сети прямо в обработчиках UI. Причём блокирующий. В винде ещё считается признаком хорошего тона повесить системную очередь событий.
Не зря в андроид сделали NetworkOnMainThreadException. Правда, всегда можно в UI-треде крутить прогресс индикатор и ждать, пока фоновый закончится :-)
Наоборот, в современном мире принято засовывать не UI операции в отдельные потоки или даже процессы. Почему в Idea это не работает для данного случая — не знаю, надо разбираться.
Скажем так, софт JB не отличается хорошим техническим состоянием. Интерфейс да, вполне хороший. Но даже проект с шаблонами с всего 50cloc вешает clion только в путь.
Скажем так, софт JB не отличается хорошим техническим состоянием.
это недостоверная инфа. Раз так хаите - предлагайте альтернативу. На мой взгляд, среды от JetBrains - это на текущий момент лучшее, что есть на рынке. Разве что в vim сидеть....
VS Code весьма недурен
Может и неплохие, тут не может быть консенсуса. Но ведь ещё и тормозят, заразы. Разве нормально, например, если зажать любой символ на 5 секунд, рисоваться в редакторе он потом будет ещё секунды. И это с power save, т.е. с минимальным фоновым анализом. Неужели 8 десктопных ядер и 16 Гб памяти мало на такую простую операцию?
Можно искать причины, тестировать на каком размере файла и каком плагине эффект уменьшается, с какой jdk выходит меньше проблем, но с VS-то таких плясок не нужно, она "просто работает". Вот такой опыт.
Это скорей проблема в самих плюсах — сложно их хорошо обрабатывать в реально времени из-за обилия шаблонов.
Гипотеза легко опровергается простым примером: есть CLion, есть Neovim. Оба используют для анализа кода один и тот же clangd. При этом CLion безбожно тормозит, а Neovim летает.
Из этого можно сделать только один вывод: проблема именно в CLion, с анализом плюсового кода всё в порядке.
Вы отчасти правы - "проблема" в том, что CLion полноценно парсит и резолвит код, а редакторы вроде Neovim лишь частично. Поэтому они не могут делать, например, рефакторинги на всем проекте, просто не имеют для этого информации. А CLion собирает и обрабатывает больше информации, чтобы это все уметь.
При этом, C++ язык не простой - там для корректной покраски кода (спасибо перегруженным операторам и не только) надо полностью резолв кода запускать.
Мы в CLion постоянно оптимизируем наш парсинг, резолв, и все операции, чтобы отзывчивость редактора была вменяемой. Движок на основе Clangd у нас при этом сильно отличается от мастера LLVM репозитория - там множество наших оптимизаций и куча дополнительных возможностей, которые мы не апстримим.
CLion, пока к сожалению, и правда на многих примерах бывает тормозит еще - мы пока не везде извели старый языковой движок, который уже решено не поддерживать далее. На Clangd еще при этом не все работает. Но я надеюсь, что наша постоянная работа в этом направлении все же не остается совсем незамеченной)
А с конкретными "тормозами" лучше приходите в трекер или саппорт, посмотрим на конкретный CPU снэпшот и раскопаем конкретную проблему. Может, воркэраунд какой-то сразу подскажем.
Поэтому они не могут делать, например, рефакторинги на всем проекте, просто не имеют для этого информации.
Я использую плагин coc.nvim и у меня работают и переименование символа по всему проекту, и переход к определению/реализации, раскиданным по разным файлам.
Но вообще рад слышать, что работа ведётся. Хотя меня кроме тормозов останавливает ещё и вот этот (ссылка) 9-летний (!) мажорный (!) баг в vim плагине.
Про IDEA Vim - пинганула команду, у них, я так понимаю, какие-то варианты там есть, но четкого плана нет. Можно оставлять комментарии и пожелания в тикете, если еще не успели.
На плагин посмотрим при случае, спасибо.
Комплишен и часть навигации в CLion сейчас работает через Clangd и довольно неплохо. Rename в CLion контекстно-зависимый (то есть не зацепляет символы с такими же именами в других областях видимости), его мы пока делаем на старом движке.
У меня push прошёл, а в веб зайти уже не получилось.
Примечательно, что впервые за несколько лет, на гитхабе сменился SSH ключ сервера:
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU.
Мы в проектах nodejs юзаем Verdaccio, удобно и добавляет надёжности системе от таких вот ситуаций
ля все налетели на чужие проблемы , за своими проектами смотрите
Сейчас всё нормально, зайти могу
GitHub упал — и сайт, и сервер (upd: поднялось 2ч50м спустя)