LINUX.ORG.RU
ФорумTalks

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

 , , , ,


0

1

Выделил в отдельный тред обсуждение консольного клиента GitHub:

www.linux.org.ru/forum/talks/16499288?cid=16499698

Пацаны, кто по понятиям живет, а расскажите все-таки, почему и когда GitHub всех сожрал? Мне не устраивают сказки про «DVCS намного лучше централизированной репы», потому что большинство пользователей Git/GitHub используют его как централизированный репозиторий и сам GitHub развивался именно как централизированный хостинг.

Более того, никому на самом деле не нужен Git — в глазах почтенной публики это скорее консольный клиент для GitHub и его клона GitLab. Причем, именно в таком ключе продолжает развивать эту инициативу Microsoft, ныне владеющий GitHub: дополнительные инструменты в виде виртуальной файловой системы для online-only работы с центральным сервером, при этом сохранение совместимости с консольными клиентом GitHub-а.

★★★★

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

Куда? Ой, сейчас слоупоками окажутся пользователи svn.

Я написла куда. P.S. Да, они слоупоки.

Вот здесь подробнее. Чего не будет в копии проекта?

Внезапно, истории: https://stackoverflow.com/a/2347196

Я с несколькими нужными мне SVN-репозиториями попал в такую ситуацию, чего бы не произошло если бы изначально использовался DVCS, такой как Git или Mercurial (Hg).

EXL ★★★★★
()

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

Альтернатив не было. Как gitlab появился - он тоже взлетел. На гитхабе activities появились только после продажи божественному майкрософту, лидеру опенсорса.

Vit ★★★★★
()

Да тут все просто, svn и SF были довольно всратыми, а в github vs bitbucket победил наверное более удобный интерфейс и нетворкинг эффект.

Хотя даже если сейчас сравнивать git и hg, меркуриал кажется более абразивным, а профит от него сомнительный. ЕМНИП там даже до сих пор нет поддержки кейченов из коробки. Зачем так жить?

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

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

Я написла куда. P.S. Да, они слоупоки.

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

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

Хрень какая-то.

Да, svn действительно хрень какая-то. Потому люди и ушли с него на DVCS, а он помер.

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

Иногда к моим советам прислушиваются. Вот, например, автор Cool Reader переехал на GitHub, потому что лично мне было неудобно использовать SourceForge.

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

потому что майкрософт его купил, когда у них кодеплекс не взлетел, очевидно же :)

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

LFS — совсем несмешной костыль

Какой ужас. С другой стороны, использовать гит вместо гуглодиска не стоит

Тащить бинари с проектом рано или поздно становится необходимо. Причем. даже на гитхабе примеров таких проектов валом — хотя бы для документации. Кто-то даже ZIP архивы в репу сует.

А какая доля из них умеет писать? А знает про интернет? Где большое количество статей типа «гит — дерьмо»? Да и если человеку что-то не нравится, он старается исправить положение. Не нравится гит — ищешь альтернативы. Просто потом оказывается, что альтернативы гораздо хуже

Fossil написали, Mercurial написали, Bazaar написали. Так что аргумент — инвалид. Весь интернет не завален статьями про плохо git потому, что не так много людей вообще программирует, а еще меньше людей разбирается в VCS. А еще меньше людей разбираются в UX — это прямо-таки вообще невостребованная профессия в 2021.

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

Fossil написали

  1. Зашёл в исходники Fossil.
  2. Увидел сваленные в одну кучу исходники на JavaScript, CSS и C.
  3. Больше вопросов о том, почему он не взлетел у меня не возникло.

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

Ах да, где банальная подсветка кода?!

https://fossil-scm.org/home/file?name=src/fossil.fetch.js&ci=trunk
https://fossil-scm.org/home/file?name=src/markdown.c&ci=trunk

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

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

В svn почти ни одна команда не работает без доступа к серверу. Убедиться в этом очень легко, отключи тырнет и сделай свой diff между ревизиями ещё раз.

В целом svn та ещё перепрелая какаха. Из-за того что всё удалённо, переключаться между ревизиями или ветками в одной папке в процессе разработки - гемор (долго себя отучал держать несколько папок с чекаутами после переезда на git), конфликты решаются сложней, сделать ветку на основе другой ветки - это все равно что отстрелить себе ногу. Вообще понятие веток там - домысел, вся эта неприкрытая работа с папками - доп. пространство для ошибок, на практике периодически кто-нибудь пропишет по ошибке не тот путь при svn copy

Не знаю ни одного человека который скучает по этой фигне.

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

Тащить бинари с проектом рано или поздно становится необходимо

В СКВ? Бинарники должны лежать где-то в другом месте.

Fossil написали, Mercurial написали, Bazaar написали. Так что аргумент — инвалид

Никогда не слышали про NIH?

Fossil, Mercurial, Bazaar

Все возникли примерно в один небольшой промежуток времени. Это не ответ на «ужасный гит».

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

Не надо выдумывать. Гит крайне популярен, интернет не завален статьями только из-за того, что людей он устраивает.

А еще меньше людей разбираются в UX — это прямо-таки вообще невостребованная профессия в 2021

И что? Мне, чтобы понять, удобно ли мне использовать инструмент Н, не надо разбираться в UX.

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

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

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

Увидел сваленные в одну кучу исходники на JavaScript, CSS и C
Больше вопросов о том, почему он не взлетел у меня не возникло

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

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

Другое дело, что ядро самого VCS можно было бы вынести отдельно от остальных SCM-фич. Это конкретно недоработка makeheaders, которая не умеет в подпроекты — эта претензия засчитывается.

Ах да, где банальная подсветка кода?

Банальная она, когда у твоего проекта есть сообщество и финансирование. А когда проект делается в две пары рук, то даже такой уровень можно называть «обоссали git по техничности реализации».

byko3y ★★★★
() автор топика

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

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

Проверил, действительно не кэширует. tortoisesvn умел вроде кэш делать, но это надстройка.

Ну как git clone –depth=1.

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

сделать ветку на основе другой ветки - это все равно что отстрелить себе ногу

На git ситуация не сильно проще и такая практика просто запрещается. Возможно != удобно и безопасно. Претензии к SVN вполне оправданы, но по этой причине в корпорациях просто использовали Perforce или, как в MS, производную от него Source Depot. В реальной жизни никому полная история всех правок не нужна, а в крупных проектах не нужна полная копия всего дерева. То есть, истина лежит где-то между SVN и Git, но нет ее ни в одном из крайних решений.

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

На git ситуация не сильно проще и такая практика просто запрещается. Возможно != удобно и безопасно.

На git это нетривиально, но относительно осуществимо, и тем более безопасно. Ведь можно работать с локальной копией, не трогая ничего в основном репозитории, и можно в любой момент отменить свои изменения.

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

Не знаю как там в реальной жизни, а мне вот ща очень удобно что я могу работать без круглосуточного подключения к рабочему vpn, потому что ветки, история, все пр. работает и так :)

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

Fossil написали, Mercurial написали, Bazaar написали. Так что аргумент — инвалид

Никогда не слышали про NIH?

Я слышал про «git — кусок дерьма, потому мы сделаем решение, которое нам подойдет». А это нерасширяемость (API), крипто-UI, и немасштабируемость. Автор Fossil целую статью написал о том, почему ему не подошел Git.

Fossil, Mercurial, Bazaar

Все возникли примерно в один небольшой промежуток времени. Это не ответ на «ужасный гит»

Это ответ на проприетарный BitKeeper. Там еще были arch и darcs. Все они нужны были для одной цели — организация распределенной опенсорсной разработки, где каждый сам себе сервер и клиент, потому что в опенсорсе трудно полагаться на единственный сервер SVN. Для многих организаций это не было проблемой, потому никто из коммерсов не спешил создавать решения для опенсорса. Но то, как Git используется сейчас, в большинстве случаев не имеет отношения к распределенной разработке — люди просто не хотят платить за Perforce.

Гит крайне популярен, интернет не завален статьями только из-за того, что людей он устраивает

Интернет точно так же не завален статьями «почему Git лучше чем Mercurial». Он «устраивает» людей только потому, что они знают ровно ноль альтернатив (SVN не в счет).

И что? Мне, чтобы понять, удобно ли мне использовать инструмент Н, не надо разбираться в UX

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

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

Чтобы код не потерять на следующий день

Я никогда не терял свой незакоммиченный код. Я не знаю, как это получается, но я никогда не коммичу мусор в репозиторий. ЧЯДНТ?

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

Тот, благодаря которому огромное количество Developers! Developers! Developers! в последнее десятилетие стало покупать всякие MacBook’и и использовать Unix-like операционные системы вроде дистрибутивов Linux’а и macOS вместо Windows и Visual Studio

А почему ты не хочешь в этой ситуации винить именно смартфоны? Если бы не смартфоны, то винда с x86 еще бы 50 лет доминировала на рынке. А так получилось, что нужна кроссплатформа, а там уже и x86 не нужен — и пошло поехало. При всем моем неуважении к винде — для одной платформы писать намного удобнее, чем для абстрактного железа.

Даже плюсовикам и сишникам удобнее использовать GCC или Clang из-под UNIX-like

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

Web-программисты выбирали то, где легко разворачивается LAMP, LEMP

Под винду не было LAMP-окружений с быстрым развертыванием? Вон, в треде уже упомянули денвер. СУБД прекрасно и быстро ставятся на винду.

устанавливаются через пакетный менеджер одной строкой, а не EXE-инсталятором, и потом красиво обновляются

Обновляется — так вообще красиво, LOR завален уже отличными историями про обновления. Весь докер создан потому, что никсовый зоопарк окружений никуда не годится — коммерсам нужен гарантировано рабочий софт фиксированных версий, а не «давайте попробуем перекомпилировать вот с этой версией».

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

А если создано два похожих пул-реквеста — тоже в одном месте комментарии?

В двух, как и в почте. Если там писать в одном письме, то можно и в одном комментарии писать.

А обсуждение смежных патчей тоже в одном месте?

Рядом. В почте оно не ближе

Что и требовалось доказать — пул-реквесты не упрощают процесс.

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

GitHub-like интерфейс стал по сути стандартом для хостингов исходного кода. Не только GitLab’ы, но и всякие Gitea и прочие Perl’овые и Scala’овые поделия (натыкался на них пару раз) копируют его

Со всеми недостатками. Да, согласен, у меня тоже большие претензии к BitBucket, но и GitHub ни разу не сахар.

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

В том, что на клиенте у тебя будет не полная копия проекта

Зачем мне полная версия на клиенте? Для Hello World — да, может быть, а зачем мне полная история ядра Linux? Или Firefox?

Лишь BitBucket с неудобным интерфейсом и изначальным дефолтом на малопопулярный уже тогда Mercurial (Hg)

«Уже тогда» сам Git еще был малопопулярен, особенно учитывая множество альтернатив, и тот факт, что его интерфейс был еще более криптовым на то время.

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

это нерасширяемость (API)

Ибо он вмещает практически всё, что нужно. Остальное — расширения.

крипто-UI

Это вы про хеши?

немасштабируемость

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

Автор Fossil целую статью написал о том, почему ему не подошел Git.

Спасибо @EXL, я обратил внимание на исходники фоссила, это ад(какого чёрта всё лежит в одной куче? где модульность? что из этого сама скв?). Учитывать его нет смысла.

Это ответ на проприетарный BitKeeper

Вот именно.

Интернет точно так же не завален статьями «почему Git лучше чем Mercurial».

Потому что меркуриал никому не нужен?

Он «устраивает» людей только потому, что они знают ровно ноль альтернатив (SVN не в счет).

А знают ноль альтернатив ибо устраивает. Ещё раз: если бы людей так доставали «недостатки» гита, они бы пошли в гугл и начали искать аналоги.

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

«пожалуйста подождите 10 секунд и посмотрите рекламу» как на какой-нибудь помойной и древней RapidShare или DepositFiles

Я помню рапидшару, это была дичь: ждать 45 секунд, «извините, превышено число соединений», докачки нету. На SourceForge еще по-божески это реализовал.

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

В реальной жизни никому полная история всех правок не нужна

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

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

Форк проекта и потом pull request

Только потому, что кривой гит иначе не позволяет этого делать, у него нет расширений для работы с патчами, как у Mercurial. Собственно, по итогу даже разрабы Linux какие-то костыли с patch queue под это дело навыдумывали.

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

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

Ты забываешь тот факт, что разработка — это не только репозиторий сорцов. Поверх них докидываются еще багтрекер, вика, пул-реквесты, CI/CD — и это дело потом нельзя отковырять от проекта. И потому по факту если гитхаб ляжет, то восстанавливать работу над проектом будут месяц. Был даже скандал с GitLab, когда DBA по ошибке снес базу и пришлось восстанавливать инфу из бэкапа 6-часовой тухлости. А теперь прикинь, что случилось бы, если бы GitLab вообще забил на это дело и восстанавливал базы месяц?

byko3y ★★★★
() автор топика
Ответ на: комментарий от no-such-file

Github был реально в разы удобнее и проще чем SF или googlecode. Даже странно сравнивать, все эти SF-ы на фоне github-а были как из каменного века

Согласен, SF был неудобен. Но был не сильно хуже BitBucket.

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

Только потому, что кривой гит иначе не позволяет этого делать

Это не его задача. Гит — простая СКВ, хотите большего — используйте расширения.

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

И тут аналогично — origin исчез, на его роль можно назначит другой сервер. Другое дело, что обычно кроме origin почти всегда ничего другого нет. Может быть дело в повсеместном IPv4+NAT или в том, что такая распределённость просто не нужна

Дело в том, что для поддержания согласованности сорцов нужен единый центр принятия решений. Как в распределенных СУБД. Централизированный репозиторий — это очень хорошо, не подумайте, что я его виню в чем-то. Мои претензии относятся только к Git, который используют в роли SVN с локальным кэшированием истории. Ну то есть локальное кэширование истории в SVN было бы намного лучше, чем Git, потому Git ни разу не идеально решение, потому Microsoft в итоге и сделала ту самую клиент-серверную поделку GVFS, которая хранит на локалхосте только непосредственно используемые файлы и историю — это уже околоидеальный вариант, но к модели разработки Git он почти никакого отношения не имеет, это уже не DVCS, а чисто центарилизованный online-only вариант.

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

Может ли этот комбайн быть потенциально более опасным, чем Git + Github? Ведь внутри Fossil есть свой вебсервер и вебдвижок. Что если завтра меня сломают, прислав специальным образом сформатированный багрепорт или комментарий к нему?

Обязательно сломают. Как и сломают через Git, если будешь кому попало давать право пуша.

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

Банальная она, когда у твоего проекта есть сообщество и финансирование. А когда проект делается в две пары рук, то даже такой уровень можно называть «обоссали git по техничности реализации».

У GitHub’а она была изначально, как и у BitBucket. Как может Fossil быть кому-то удобным, когда там нет таких вот элементарных вещей?!

А почему ты не хочешь в этой ситуации винить именно смартфоны?

Я не хочу никого винить и разбираться, почему вышло всё именно так. Всё что я вижу, это то, что практически для всех разработчиков окружение и подход к разработке UNIX-style со всеми его недостатками и преимуществами – победил, а Windows-style с его Visual Studio, проиграл.

Именно это и сподвигло Microsoft вкорячивать в Windows ядро Linux и переходить на Git. Иначе бы они проиграли и всё больше и больше разработчиков покупало себе MacBook’и или уходило на Linux. Что уж говорить, если даже внутри самого Microsoft, несмотря на всё его активное продвижение C# и .NET, внезапно следующая ситуация:

Microsoft и Azul портируют OpenJDK на новый процессор Apple Silicon M1

P.S. Когда в комментариях спросили, зачем это Microsoft, то ответили, что в Microsoft большая Java-команда, которая использует активно MacBook’и и планируют их обновить до последних версий: https://twitter.com/brunoborges/status/1327004243308339201

Под винду не было LAMP-окружений с быстрым развертыванием? Вон, в треде уже упомянули денвер.

Видимо нормально работающего ничего не было, раз сегодня превалирующее число разрабов не используют костыли вроде Denver’а. Он проиграл.

СУБД прекрасно и быстро ставятся на винду.

Разве что Microsoft SQL Server.

Обновляется — так вообще красиво, LOR завален уже отличными историями про обновления. Весь докер создан потому, что никсовый зоопарк окружений никуда не годится — коммерсам нужен гарантировано рабочий софт фиксированных версий, а не «давайте попробуем перекомпилировать вот с этой версией».

И этот docker, заметь, Microsoft страсть как хочет чтобы работал нативненько в Windows.

Зачем мне полная версия на клиенте? Для Hello World — да, может быть, а зачем мне полная история ядра Linux? Или Firefox?

Так Git мне позволяет самому решать (git clone --depth=X -b master), полную версию я хочу на своём клиенте или нет. А решения вроде SVN – не позволяют.

«Уже тогда» сам Git еще был малопопулярен, особенно учитывая множество альтернатив, и тот факт, что его интерфейс был еще более криптовым на то время.

Со всеми недостатками. Да, согласен, у меня тоже большие претензии к BitBucket, но и GitHub ни разу не сахар.

Не был никогда интерфейс в GitHub’е криптовым. А вот что BitBucket, что SourceForge проиграли именно из-за своего неудобного интерфейса.

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

А что ты на лоре делаешь, а не в спортивках под падиком семечки щёлкаешь?

На китайских смартфонах школьников в глубинке не особо заработаешь — кодинг выгоднее и безопаснее. www.linux.org.ru/people/ananas/profile — вот он тоже как подрос, женился, так ушел в кодинг и больше под падиком семки не шелкает, а щелкает их дома за компом.

Потому что они первые додумались сделать УДОБНУЮ морду для Git

Всё что угодно удобнее дефолтной морды Git. Однако же, подходов к этому снаряду было сделано много, не только гитхабом.

и когда

С времён основания github

Очень спорно. Все-таки гитхаб не сразу всех сожрал.

Большинство контор которые хоть как-то уважают собственную безопасность, сохранность данных, приватность - содержат собственные репозитории на сервере

Да, на гитлабе. И зачем им гит? Риторический вопрос.

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

Так это ты уговорил openoffice переехать на git?

Нет, OpenOffice как и многие другие проекты вроде GCC или FreeBSD переехать на Git уговорила фактическая смерть SVN.

А сегодня проекты мигрируют с Mercurial (Hg) тоже на Git схожим образом. У ртути были проблемы с переходом на Python 3, именно они наверное и добили эту DVCS.

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

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

Фейсбук нужен был для того, чтобы собирать информацию о пользователях. Это их основной источник дохода. Ты никогда не задумывался, почему на таких сайтах почти нет рекламы и вообще никаких платных услуг? Всё бесплатно, всё работает, никаких ограничений по объему хранимой личной информации — а кто же платит за банкет?

Альтернатив не было. Как gitlab появился - он тоже взлетел

Bitbucket.

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

На главной странице баннер висит и иногда под новостями.

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

Хотя даже если сейчас сравнивать git и hg, меркуриал кажется более абразивным

Интересное свойство софтины «абразивность». Это что такое?

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

Не видел. Оно лучше гитхаба?

Gerrit предназначен в первую очередь для ревью кода, выглядит так:

https://codereview.qt-project.org/c/qt/qtbase/+/306771
https://review.haiku-os.org/c/haiku/+/4369

Это более специализированный инструмент.

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

На git это нетривиально, но относительно осуществимо, и тем более безопасно. Ведь можно работать с локальной копией, не трогая ничего в основном репозитории, и можно в любой момент отменить свои изменения

Внезапно, SVN позволяет работать с локальной копией и отменять изменения без соединения с сервером.

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

Gerrit предназначен в первую очередь для ревью кода, выглядит так

Ревью кода, сливание правок, подготовка релизных веток — это 95% всей работы с репозиторием.

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

Ибо он вмещает практически всё, что нужно. Остальное — расширения

Если бы он вмещал почти всё, что нужно, то GitHub бы не существовало. Напоминаю, что на своем старте у GitHub не было многих фич, которые там сейчас есть, но даже это было намного лучше штатной поставки Git.

Опять же, гит достаточно масштабируем для проектов типа ядра линукс

Спорно. Например, в репе ядра нет тестов. Ядро линукса уже сейчас находится близко к пределу возможностей Git, то есть, работает медленно, но пока терпимо.

Спасибо @EXL, я обратил внимание на исходники фоссила, это ад(какого чёрта всё лежит в одной куче? где модульность? что из этого сама скв?). Учитывать его нет смысла

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

Интернет точно так же не завален статьями «почему Git лучше чем Mercurial»

Потому что меркуриал никому не нужен?

Правильно, потому что про меркуриал никто не знает — что и требовалось доказать. Так про какие преимущества и недостатки можно говорить, если вопрос стоит только «какой Git мне лучше выбрать?».

Ещё раз: если бы людей так доставали «недостатки» гита, они бы пошли в гугл и начали искать аналоги

Идут, и ищут, и делают репозитории своих проектов на Mercurial, и даже пишут в интернетах, почему Mercurial лучше Git. Но этих людей просто очень мало тех, кто знаком с Git. Не «поставил себе на комп», а реально знаком с Git.

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

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

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

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