Почему взлетел GitHub?

Ты съезжаешь с темы. Изначальная тема - почему на проекте ХХХ интересно тусоваться (и почему он взлетает). А ты какую-то бизнес-аналитику пытаешься гнать, которая с изначальной темой связана чуть менее чем никак

Твоя аналитика все еще не отвечает на вопрос «почему на проекте XXX тусуется больше народа, чем на проекте YYY». Твое объяснение я раскрыл — потому что на проекте (фейсбуке) раздают халяву. На гитхабе тоже раздают халяву, но гитхаб — не единственный пункт раздачи халявы.

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

Вот, уже лучше, уже интереснее.

Абсолютно неожиданно я узнал интересный факт:

https://web.archive.org/web/20131007020110/https://github.com/facebook

Ты как-то странно оцениваешь понятие «удобство». Привернуть какую-то вебню к DVCS не достаточно

Что еще нужно? Багтрекер?

Каждый Git репозиторий - это, по сути, отдельный форк проекта. Нужно ли их синхронизировать или нет, а если да, то как - личное дело каждого владельца своего локального репозитория

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

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

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

Ну то есть да, я хочу сказать, что распределенная модель разработки неудобна. Да, ты можешь сделать локальную ветку, но по итогу выкинешь ее и ребейзнешь изменения на HEAD, чтобы потом была читаемая история изменений. Да, удобно хранить локально ветки с удаленного сервера, но на этом удобства DVCS заканчиваются. Людям просто нужен был SVN с возможностью локально кэшировать историю и подготавливать серии патчей (в том числе при помощи локальной истории) до их отправки на сервер.

Если этот GVFS бежит локально (на компьютере разработчика или на сервере офиса) и общается с внешним миром через Git, то почему это online-only вариант? На сколько я знаю Git поддерживает частичное клонирование репозитория, чтобы не скачивать всю историю всех 100500 файлов. https://git-scm.com/docs/partial-clone

Это и есть модификации Git для реализации GVFS. Как-то вот так оно по итогу работает:

https://docs.microsoft.com/ru-ru/previous-versions/azure/devops/git/gvfs-arch...

2017 год — это примерно время релиза первых реализаций GVFS:
https://github.com/microsoft/VFSForGit/commits/master/License.md

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

Линуса нет, зато Microsoft Corporation есть

Ну дык Microsoft — это нынче опора опенсорса (то есть GitHub-а). А ты не знал?

Что еще нужно? Багтрекер?

• Социалочка нужна. В первую очередь. (багтрекер плюс комментарии к коду)
• Юзабельность интерфейса, чтобы хомячки поперли (вебня). Бложик гитхаба почитай.
• Халявное машинное время (для CI).

Покажи кто это еще раздает одновременно, и в какой момент у них эти фичи сложились.

Ты конечно еще учти, что в успехе здоровую часть составляет везение. А везет обычно тем кто первый в нише и фанатеет за дело не ради денег. Грубо говоря, рецепта чтобы зареюзать, тебе некто не даст, т.к. каждый случай [везения] уникальный. Это я тебе говорю как человек, у которого взлетело несколько сайтов и репов.

Пора заводить персональный тег для тредов с разоблачениями несправедливостей этого мира.

И для одиночного кодинга самое то, потому что приватные репы.

Бесплатные приватные репы давным давно имеются на GitHub’е.

Социалочка нужна. В первую очередь. (багтрекер плюс комментарии к коду)

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

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

Аналогично. Ссылка на archive.org показывает, что интерфейс Fossil почти один в один копировал фичи и интерфейс GitHub примерно 2010 года. Но взлетел именно GitHub.

Халявное машинное время (для CI)

CI/CD на GitHub появился чудовищно поздно:
https://github.blog/2019-08-08-github-actions-now-supports-ci-cd/

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

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

Аналитики ЦРУ с тобой не согласятся. Собственно, в наше время аналогичную разведку может позволить себе крупная компания за большие деньги. Да, очень важно быть первым, но GitLab с тобой не согласится. Да, доход не главное — главное раскидать деньги и завлекать кинувшуюся собирать их толпу. Да, даже если все факторы просчитаны и учтены, все равно остается место случаю. Но всё же случайные факторы не составляют 100% успеха.

Пора заводить персональный тег для тредов с разоблачениями несправедливостей этого мира

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

Как минимум багтрекер и вика у Fossil тусят в том же репозитории.

Да, bugtracker внутри (лучше рядом) с репозиторием на рельсах Git выглядит неплохим преимуществом. А вот wiki/документация на GitHub в отдельном репозитории и так уже рядом с проектом. Это просто дело вкуса. Интересно, имеются ли системы Bug Tracking’а, которые под капотом работают на Git? То есть Issue и обсуждение PR’ов превращается в коммиты и т. д. По любому кто-то должен был такое сделать.

«Корпорации» сделали ставку на Mercurial, как ни странно. Но взлетел Git. И этот парадокс мне не до конца ясен.

Просто вес голоса тех кто сделал ставку на Git (Google, Microsoft, RedHat и др.) впоследствии перевесил тех, кто поставил на Mercurial.

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

Для этого был создан https://git-lfs.github.com/, например. Нахождение жирных бинарников в репе всегда считалось моветоном, если эта репа не была посвящена лишь только подобным бинарникам.

И я напоминаю, что в Git адекватной поддержки подпроектов нету

А где она есть? С подпроектами всегда и везде будут какие-то странности, непонятки и компромиссы, просто потому что вещи начинают усложнятся. Git Submodules имеют недостатки, но зато вполне себе обеспечивают хорошую гибкость, позволяющую выбрать наиболее удобное их применение: супермодуль ли это, или просто репозиторий с кодом, в котором имеются зависимости от другого кода.

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

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

Ты так пишешь, будто нет альтернатив: https://github.com/scm-manager/scm-manager

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

Просто вес голоса тех кто сделал ставку на Git (Google, Microsoft, RedHat и др.) впоследствии перевесил тех, кто поставил на Mercurial

Facebook еще забыл. Я уверен, что в сообществе найдется много тех, кто скажет «пользуюсь Git потому, что его использует гугл для андроида». И пофигу, что там еще пришлось городить костыли, потому что андроид Git уже не может вывезти.

Для этого был создан https://git-lfs.github.com/, например. Нахождение жирных бинарников в репе всегда считалось моветоном, если эта репа не была посвящена лишь только подобным бинарникам

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

И я напоминаю, что в Git адекватной поддержки подпроектов нету

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

Подпроекты — это костыль под немасштабируемостью Git. Я не уверен, но по-моему BitKeeper неплохо вывозит большие проекты и бинарники.

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

Проблема в том, что нет автоматических инструментов, которые бы безошибочно делали такие атомарные правки.

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

Даже не слышал про такое. И все через веб, и с комментариями к любой строчке кода, помимо текетов? Где можно посмотреть?

CI/CD на GitHub появился чудовищно поздно

Ты точно гитхабом пользуешься? В 2019 CI стал родным. А до этого травис сто лет был. И всякие канбаны можно было при желании. Все за счет интеграции сторонних сервисов.

Но всё же случайные факторы не составляют 100% успеха.

Кто говорил про 100%? Много != всё. Про удачу тебе лучше всего расскажут инвесторы стартапов (сколько прогорает и сколько выстреливает).

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

интерфейс BitBucket так же уныл

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

rebase требует force push. Это ломает код ревью.

Не знаю где там у тебя ребасе чтото ломает.

Даже не слышал про такое. И все через веб, и с комментариями к любой строчке кода, помимо текетов? Где можно посмотреть?

Например, тут:

https://fossil-scm.org/home/dir?ci=trunk

Комментировать что попало там нельзя.

Ты точно гитхабом пользуешься? В 2019 CI стал родным. А до этого травис сто лет был. И всякие канбаны можно было при желании. Все за счет интеграции сторонних сервисов

Не деплоил никогда ничего через GitHub, сорян. Блин, ну через внешние сервисы и Fossil умеет деплоиться.

Про удачу тебе лучше всего расскажут инвесторы стартапов (сколько прогорает и сколько выстреливает)

Куча стартапов создается как 100% разводилово аля «пирамида Понти». Инвестор инвестору рознь, и шансы успеха резко возрастает, если инвестор реально понимает, куда вкладывается, а не так, что пришел в опенспейс офис, посмотрел «о, ребята работают, я не зря отдал им деньги» — спасибо за денежки, лошара.

Комментировать что попало там нельзя.

Ну вот то что для одних важно, для тебя «что попало». А степень социальности падает.

Интерфейс там какой-то sourceforge напоминает, на первый взгляд.

Блин, ну через внешние сервисы и Fossil умеет деплоиться.

Где? Я тебе конкретные примеры привожу, почему людям удобно, а ты «ну это сделать не проблема». Ты определись, тебе надо информацию узнать, или со мной поспорить. Спорить мне не интересно. А если по информации - поддерживай градус конструктива, приводи конкретные примеры.

Инвестор инвестору рознь

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

rebase требует force push. Это ломает код ревью

1. Не ломает в gitlab.
2. Если разработчик не мудак, то он выполняет просьбы ревьюера СРАЗУ
3. Нормальный ревьюер всегда должен проверять выполнились ли его просьбы

BTW даже при merge вместо rebase, код ревью в гитхабе иногда теряется, хахаха

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

Юзабельность интерфейса, чтобы хомячки поперли (вебня).

дело не только в вебне, например GitLab она не очень то помогает.
В чём дело?
Дело в том что мало кнопочек, можно даже сказать так, что кнопочки сами по себе второстепенны.

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

И тут окажется что у GitHub всё намного лучше чем у GitLab.
Ну а что до кнопочек, то я как загрузил на Github ключ для ssh стал с ним общаться преимущественно через git, а через вебню стал заходить всё реже.

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

Как они вообще рассчитывают на то, что я захочу ими пользоваться?!!

Теперь заходим на Гитхаб, там на главной тоже маркетологическая хренатень, НО!!! чётко выделена строка поиска, набираю в ней слово Linux и нажимаю enter:
меня перебрасывет на нормальную страницу с сылками на репозитарии, первая же ссылка это torvalds/linux, то что скорее всего новичок искать и будет.
И да, они уже обеспечили этим то, что человек хочет у них остаться и причина тут простая: мне сразу дали то, что мне нужно.

И к стати тоже6 самое касается и сайта Debian, ссылки на скачивание найти так трудно, что просто хочется уйти скачать чтони будь другое, за место их поиска в маркетологической хренотени.
Да, если там нажать на кнопку Download то меня перебросит на страницу с хренотенью(извините, но сточки зрения того, кто ищет нужный исошник на той странице хренотень) и придложат скачать netinstall который не факт что мне нужен.
Можно просто без подсовывания чего либо просто перебросить на страницу с сылками на все имеющиеся актуальные образы, а там уж я сам кликну на то, что мне надо скачать.

rebase требует force push. Это ломает код ревью.

Постоянно делаю rebase, ничего не ломается.

it makes incrementally reviewing changes difficult

Понятно. Просто не надо огромные изменения PR-ить. Разбей на меньшие, и необходимость в «incrementally reviewing» пропадёт.

Добавлю, что ещё во время review можно спокойно мёржить master в свой бранч. А после ревью, делать один большой rebase.

Из-за гитхаба и пиара Линусом в итоге умирает mercurial(даже битбакет дропнул поддержку). А раньше под ним жила куча открытых проектов - mozilla, solaris, etc.

Не из-за гитхаба, а из-за того, что mercurial никому не нужен.

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

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

Из-за гитхаба и пиара Линусом в итоге умирает mercurial

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

Да, Mercurial намного грамотнее спроектировано. Помянем.

Потому что говно всегда всплывает.

У gitlab на редкость отвратительная мобильная версия сайта. Стоит перейти внутри проекта в подкаталог, таблица с отображением файлов сразу едет и помещается только 5 символов от имени.

О том насколько тормозной сам сайт, я …. не собираюсь молчать.

Мозилла и сейчас под ним живёт.

О том насколько тормозной сам сайт, я …. не собираюсь молчать

Руби не тормозит — руби просто никуда не спешит.

Не совсем. Просто bitbucket сам по себе не очень популярным был и не таким удобным для проектов сообществ. Поэтому новые проекты на нём редко кто заводил.

Я на гитхабе первоначально зарегистрировался, чтобы фичу запросить у одного проекта. А уж потом так вышло, что генту с cvs на git переехало и официальное зеркало разместили на гитхаб. Пользовались бы mercurial - пользовался б им чаще.

Сейчас для открытых проектов использующих mercurial есть heptapod (на основе кода gitlab) и ряд других площадок, либо появившихся после «смерти» bitbucket, либо работавших до этого.

А таблицы то чего кривые?

А не, сегодня норм

с технической стороны GitHub посасывает у Fossil

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

Ты не обучаем. UX это не твоё, займись в ИТ чем-нибудь другим.

Bitbucket, а точнее Atlassian форсал свою жиру, а функционалу bitbucket-а уделял не очень много внимания. Поэтому они сразу отстали от Github-а по популярности, даже если они (Bitbucket) и поддерживали Mercurial. Замечу, что это всё происходило в году так 2012-м, года Github выиграл всё свои главные сражения с конкурентами. Mercurial, кстати, тогда тормозил неподецки (Git тоже, но не так сильно, потому что его уже активно переписывали на C). Потом Mercurial, конечно, улучшили, но всем было уже пофиг. А когда самый большой проект (CPython) перешёл на Git, то кирдык уже пришёл окончательный.