LINUX.ORG.RU
ФорумTalks

Microsoft покупает GitHub

 ,


1

4

По сведениям издания Business Insider, полученным из неофициальных источников, Microsoft и GitHub обсуждают возможность продажи сервиса. Отмечается, что последние годы представители Microsoft и GitHub уже безуспешно общались по вопросам продажи, но несколько недель назад начались более серьёзные переговоры. В качестве ориентировочной стоимости упоминается сумма в 5 миллиардов долларов (в 2015 году GitHub оценивался в 2 миллиарда) и пока не ясно, согласится ли на такую цену Microsoft.

https://www.opennet.ru/opennews/art.shtml?num=48696

Ответ на: комментарий от Harald

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

bread
()
Последнее исправление: bread (всего исправлений: 1)
Ответ на: комментарий от bytecode


Во-первых, валить рано. Во-вторых, даже если случится, само по себе - не повод валить. В-третьих, в-четвертых[, ...] куда угодно, только не на гитлаб. Можно успеть сходить на обед, пока он откликнется на очередной клик в веб-морде.



Из твоего сообщения складывается впечатление, что у гитлаба тормозит весь интерфейс. Видимо речь про gitlab.com

Но это не соответствует действительности.

blackst0ne ★★★★★
()
Ответ на: комментарий от KennyMinigun

Если вдруг какие фичи/баги, пингуй меня. Или тут, или на гитлабе.

blackst0ne ★★★★★
()
Ответ на: комментарий от grem


ещё такой вопрос: gitlab и bitbacket тоже поддерживают подключение автоматизированных тестов и ботов?



Боты - это что-то типа Codecov Report в виде отдельного сообщения в пулреквесте?

blackst0ne ★★★★★
()
Ответ на: комментарий от blackst0ne

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

grem ★★★★★
()
Ответ на: комментарий от grem

1. Автозакрытие и кросс-ссылки в гитлабе из коробки.
2. Прикреплять - это про assignee? Если да, то есть из коробки.
3. Интеграция с внешними сервисами из коробки.

blackst0ne ★★★★★
()
Ответ на: комментарий от blackst0ne

тогда это хорошо!

p.s. как выяснилось, если на sourceforge переносятся коммиты и там аккаунт имеет тот же ник и почту, то они ассоциируются с этим же аккаунтом-ником.

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

grem ★★★★★
()
Ответ на: комментарий от kirk_johnson

Куда валить-то?

На локалхост, вестимо. Возможно, у меня специфический опыт, но я считаю безумием зависимость ежеминутной работы от внешних сервисов. А import «github.com/blabla», по-моему, вообще подрасстрельный проступок.

tailgunner ★★★★★
()
Ответ на: комментарий от Siado

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от blackst0ne

Из твоего сообщения складывается впечатление, что у гитлаба тормозит весь интерфейс. Видимо речь про gitlab.com

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

Iron_Bug ★★★★★
()

подождём, посмотрим. может, это вообще провокация гитлаба :)

ну а так, ежеличо - локалхост. собсна, кроме локалхоста нет надёжных средств хранения данных.

Iron_Bug ★★★★★
()
Ответ на: комментарий от tailgunner

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

Ну это понятно, что внутри конторы должен быть свой Git. А для частных проектов? Прелесть гейхаба в issue tracker'е + DVCS + Travis + Coverity нахаляву.

А import «github.com/blabla», по-моему, вообще подрасстрельный проступок.

Ну такое себе, да :)

kirk_johnson ★☆
()
Ответ на: комментарий от kirk_johnson

А для частных проектов?

Да что угодно. Можно и на гитхабе остаться - главное, чтобы были локальные клоны всего.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

главное, чтобы были локальные клоны всего

в этом и есть прелесть распределённых систем, таких как git и mercurial, разве нет?

grem ★★★★★
()
Ответ на: комментарий от tailgunner

Ну тормоза по разным причинам могут быть. Возможно с 10х наплывом юзеров у них тупо сервера вспотели. Лично я селф-хостед пока не тыкал и не знаю тормозит ли он сам по себе.

entefeed ☆☆☆
()
Ответ на: комментарий от tailgunner

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

grem ★★★★★
()
Ответ на: комментарий от kirk_johnson

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

но если есть ненужное бабло - можешь у себя локально рейды поднимать. никаких проблем с этим нет.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 2)
Ответ на: комментарий от grem

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

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

Другие носители тоже харды? И тоже без рейда?

kirk_johnson ★☆
()
Ответ на: комментарий от Iron_Bug

конечному юзеру не нужна вся история проекта локально на компе. он качает срез

git clone --depth=1 <remote_repo_url>
grem ★★★★★
()
Ответ на: комментарий от kirk_johnson

И тоже без рейда?

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

grem ★★★★★
()
Ответ на: комментарий от grem

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

Ну, если есть рейд на бекапе, то иметь рейд на рабочей машине уже избыточно.

kirk_johnson ★☆
()
Ответ на: комментарий от Iron_Bug

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

Ну а как еще сделать такие продукты децентрализованными и не зависящими от желания их владельцев?

Siado ★★★★★
()
Ответ на: комментарий от Iron_Bug


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



Это всё общие слова на уровне «танк тормозит и жрёт топливо как не в себя».
Но если пересчитать вес танка на запас хода, то окажется, что жрёт он вполне себе адекватно.

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

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

blackst0ne ★★★★★
()
Ответ на: комментарий от entefeed

Это не отменяет того, что на Gogs и Gitea могут быть (и есть) публичные хостинги. Не столь популярные, как GitLab, но все же.

xdimquax ★★★★
()
Ответ на: комментарий от xdimquax

Да, я их посмотрел. Не особо внушают доверие пока, ну разве что notabug.org может быть. Пока склоняюсь к гитлабу.

entefeed ☆☆☆
()

А можно сделать так, чтобы изменения репозитория на гитлабе и его зеркала на гитхабе (или наоборот) синхронизировались в обе стороны?

xdimquax ★★★★
()
Последнее исправление: xdimquax (всего исправлений: 1)

По данным портала по сбору статистики Grafana, за выходные на GitLab были импортированы тысячи проектов, и, как ожидается, их число только будет расти.


Забежала лиса в курятник.
https://www.securitylab.ru/news/493730.php

Deleted
()
Последнее исправление: Deleted (всего исправлений: 3)
Ответ на: комментарий от entefeed

Ого, целых 500 человек аж на самом ченджорге кнопочку нажали. Вот теперь-то некрософт с позором отступит !

Deleted
()
Ответ на: комментарий от kirk_johnson

На gitlab.com у меня / открывается почти молниеносно.

А вот глобальный поиск не работает почти никогда. На гитхабе всё работает замечательно, а на гитлабе - раз через пять. :(

blackst0ne ★★★★★
()
Ответ на: комментарий от Siado

по сути, никак. просто нужно чтобы была конкуренция и были альтернативы.

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

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

Iron_Bug ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.