Comments 29
Вот оно что. Я предположил, что они планово сбросили. А у них там юзеры получали доступ к аккаунтам. Еще одна фобия
Майкрософт ассоциируется у меня с кошмарной авторизацией. Ещё давно я перестал использовать Скайп, если подобные проблемы достанутся в наследство и гитхабу — придется переходить на гитлаб.
Фишка гитхаба не в функциях, а в том, что это социальная сеть. Хочешь, чтобы тебе присылали issues и PR — выкладывай код на гитхаб. Хочешь прислать кому-то issue или PR — иди на гитхаб. По фичам гитлаб не хуже, может где-то и лучше, но там никого нету.
если в один день люди не смогут нормально авторизоваться на сервисе и всюду появятся бесконечные лоадеры, и реклама как в Скайпе… то на гитхабе мало кто останется
Очень надеюсь что мои опасения напрасны и этого не случится, получилось же у них VS Code сделать.
получилось же у них VS Code сделать.
Между тем элементарно различать отступы (табуляция или пробелы) и выравнивание (исключительно пробелы) до сих пор не научились, и требуется расширение.
Для VS в комплекте Productivity Power Tools есть плагин, который предлагает сделать пробелы или табы, если видит кашу. Если я правильно понял о чем вы.
Ага, получилось…
https://github.com/Microsoft/vscode/issues/22900
Фишка гитхаба не в функциях
Не согласен. На гитхабе, например, очень фичастые GitHub Actions.
Так и на гитлабе CI/CD вполне себе неплохо работает.
ЕМНИМ, гитлаб добавил на общедоступный gitlab.com CI/CD первым, гитхаб уже за ним подтянулся. Хотя в платном гитхабе это наверняка уже давно было.
Проблемы, на которые я наступил в GitLab CI в первые два дня работы с ним:
https://gitlab.com/gitlab-org/gitlab/-/issues/23605 (брать поминутно деньги и не иметь fail-fast — это имхо какой-то полный зашквар)
https://gitlab.com/gitlab-org/gitlab/-/issues/18905
И подход с реюзабельными экшенами в виде отдельных репозиториев в GitLab Actions на порядок мощнее того что предлагают другие CI-системы.
Хочешь, чтобы тебе присылали issues и PR — выкладывай код на гитхаб. Хочешь прислать кому-то issue или PR — иди на гитхаб
Меня такое заявление прям оскорбляет, имейте уважение к разработчикам, не судите по себе, откройте например Gitlab GNOME, там 63000 Issues, таких примеров можно приводить очень много, если я обнаруживаю и/или исправляю баг или что-то улучшаю в ПО, то отправляю патч/сообщение о ошибке удобным для разработчиков способом, главное чтоб в документации к проекту способ был описан
По фичам гитлаб не хуже
Вы похоже его даже не использовали, а опять таки голословно утверждаете, иначе бы знали как минимум то, что там нет поиска по коду, как на GitHub
Ну если у вас проект уровня Gnome или Firefox, то люди пойдут регистрироваться в вашем Git<Something>. А если кто-то написал мелкополезную утилитку и хочет фидбека - или гитхаб, или ничего.
То же самое, что с соц. сетями: крупные порталы ещё могут как-то с ними конкурировать по популярности. Но если мелкий блоггер хочет аудиторию побольше - то они безальтернативны, потому что стендэлон блог посетят полтора землекопа, если его автор не Джоэл Спольски.
Про поиск по коду - ваша правда.
Между тем баг с неотключаемым автодобавлением перевода строки в конец файла (медвежья услуга) при его редактировании через веб-интерфейс исправлять отказались, заявив, что это не баг и труЪ-текстовый файл просто обязан завершаться переводом строки. %)
Тут вообще нужно понимать, что там ведь по сути трудится та же команда что и до поглощения. Microsoft выделила денег на то чтобы сделать новые классные бесплатные возможности, но она же не увольняла всю старую команду.
Даже в C++ завершающий перевод строки уже не требуется, но даже абстрагируясь от этого, проблема в том, что это неотключаемо и происходит с любыми текстовыми файлами — в том числе текстовыми файлами общего назначения с расширением txt, где наличие программного кода не предполагается.
В моём случае, например, это были файлы переводов (локализации) интерфейса с моим собственным форматом ключ = "значение". При этом для неподкованных пользователей прямое редактирование файлов через веб-интерфейс — наиболее простой способ изменения файла.
Но в голову приходит пример, когда это было бы неуместно. Например, на PHP после завершающего `?>` это выглядело бы неуместным, хоть перевод строки после `?>` и игнорируется, да и не принято писать завершающий `?>` уже больше 10 лет. Разработчики GitHub наверняка не пишут на PHP, но это можно было бы использовать как аргумент реализовать поддержку `.editorconfig` и брать соответствующую настройку из него.
Исторически, насколько я знаю, в C/C++ перевод строки требовался, чтобы предотвратить нарушение работоспособности кода из-за незапланированной конкатенации разных строк в результате обработки директив #include.
Вот, например, на эту тему на StackOverflow. Начиная с C++11 завершающий перевод строки стал необязательным.
Узнаю тебя, Microsoft!
GitHub разлогинил всех пользователей из-за опасений о безопасности