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)
Ответ на: комментарий от xaizek

Упрощают, делая его удобнее. Ты просто придрался именно к тому, что они не упрощают

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

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

git log | grep

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

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

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

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

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

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

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

Модульность там делается максимум за человеконеделю

Её нет до сих пор, а первый релиз состоялся ещё в 2006 году.

но она не бесплатна — это усложнение поддержки, а проект разрабатывает всего два человека

Ибо он нужен только им. Ибо гит банально устраивает остальных.

Правильно, потому что про меркуриал никто не знает — что и требовалось доказать

Где ж не знает? Сколько он стоял у openjdk, до сих пор мозилла его использует.

Правильно, потому что про меркуриал никто не знает

Идут, и ищут, и делают репозитории своих проектов на Mercurial, и даже пишут в интернетах, почему Mercurial лучше Git.

Но этих людей просто очень мало тех, кто знаком с Git

То есть они используют меркуриал, ибо не знакомы с другой СКВ. Просто прекрасно.

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

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

Как это нельзя? Нажал кнопочку Blame в своей IDE/GitHub’е или набрал git blame <file> в консольке и получил то что хотел.

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

Так было не всегда. Крупные проекты тоже выбирали Mercurial раньше: OpenJDK, SDL, например. Но удобство Git+GitHub и доступ к огромной базе разработчиков победил: SDL2 переезжает на GitHub

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

Сколько он стоял у openjdk, до сих пор мозилла его использует.

А ещё Nginx. Но думаю что Firefox и Nginx в конце-концов уйдут на Git, учитывая что Mercurial в последнее время совсем уже плохо.

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

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

Это лишь значит, что разработчикам Fossil не понадобилась эта фича. Почему — спрашивай у них. Они не стартап и не планируют коммерческую разработку Fossil.

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

Я уже ответил в удаленном треде, что MS переориентируется на облако. Если в облаке люди работают на маках, то MS будет ориентироваться на маки. Им не нужны никсы, им нужно Software as a Service.

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

Разве что Microsoft SQL Server

Я ставил постгрес и мускуль. Как ни странно, проблемы у меня возникли только с ораклом, но с ним везде проблемы.

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

А ты не забыл, что Win NT с самого начала было POSIX-совместимым? Там даже форк всегда был, но он был бесполезен в среде win32, его применяли только для создания отладочного снимка процесса. Собственно, MS никогда и не сокращал эту поддержку совместимости, хотя и не развивал до недавних пор. Но, как я уже написал, им нужны не никсы — им нужны клиенты облаков, а точнее — их денежки.

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

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

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

Криптоинтерфейс не у GitHub, а конкретно у Git. Если бы у Git был хороший фейс, то любой человек мог бы создать свой собственный сервер и GitHub не пользовался бы такой популярностью. То есть, в не последнюю очередь GitHub взлетел из-за плохого UI Git.

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

Это здесь к чему? Сравнение GH с GH? Сравнение же со списками рассылки, в которых это всё делается не проще.

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

Так там же раньше была только ртуть, не?

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

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

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

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

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

Всё что угодно удобнее дефолтной морды Git

Нет. tig намного удобнее для просмотра истории коммитов чем в гитхабе или в гитлабе.

Консоль все еще осталась удобнее во многих случаях чем встроенный способ управления Git в IDE

Сложные манипуляции вообще осуществимы только консолью.

А вот ребейза одной кнопкой не хватает, да.

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

Постепенно накапливал критическую массу пользователей пока они сами не станут двигателем популяризации гитхаба

Да, на гитлабе

Ну да, а потом бац - твоего репозитория нет по каким-то причинам.

И зачем им гит? Риторический вопрос.

Это не риторический вопрос. Это вопрос доверия и сохранности. Держишь у себя - оно у тебя под контролем. Держишь на гитхабе - доверяешь ему. И его левой пятке тоже.

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

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

https://github.com/libgit2/libgit2

А раньше через пайпы Git гонял, было это медленно и глючно.

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

Модульность там делается максимум за человеконеделю

Её нет до сих пор, а первый релиз состоялся ещё в 2006 году

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

но она не бесплатна — это усложнение поддержки, а проект разрабатывает всего два человека

Ибо он нужен только им. Ибо гит банально устраивает остальных.

Вообще-то, не совсем только им:

https://chiselapp.com/repositories/

Но да, разрабов, желающих развивать Fossil, очень мало.

Где ж не знает? Сколько он стоял у openjdk, до сих пор мозилла его использует

Ну и какая это доля из всех разработчиков?

Но этих людей просто очень мало тех, кто знаком с Git

То есть они используют меркуриал, ибо не знакомы с другой СКВ. Просто прекрасно

Очевидно, фраза построена криво, потому что я опечатался. «Но этих людей просто очень мало, как и тех, кто знаком с Git» — то есть, очень мало людей по-настоящему знакомы с Git, еще меньше тех, кто знаком с Mercurial. По факту, большинство знакомы только с GitHub/GitLab, Git им не нужен и не интересен.

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

А я тебе отвечаю, что без «модульности» разрабатывать софтину малым числом людей проще и быстрее

Пятнадцать лет. Это о многом говорит.

https://chiselapp.com/repositories/

Прикольно, а разработчиков всё ещё 2. Правда, это сравнительно ничто.

Ну и какая это доля из всех разработчиков?

Для написания статей? Значительная.

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

Нажал кнопочку Blame в своей IDE/GitHub’е или набрал git blame <file> в консольке и получил то что хотел

69964f0a4f (panda 2021-08-09 08:52:47 +0300  2)                                        
69964f0a4f (panda 2021-08-09 08:52:47 +0300  3) /**                                     

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

Но удобство Git+GitHub и доступ к огромной базе разработчиков победил: SDL2 переезжает на GitHub

Это случилось сильно позже событий, решивших судьбу индустрии в плане VCS.

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

Это здесь к чему? Сравнение GH с GH? Сравнение же со списками рассылки, в которых это всё делается не проще

Я сразу ответил:
Почему взлетел GitHub? (комментарий)

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

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

Консоль все еще осталась удобнее во многих случаях чем встроенный способ управления Git в IDE
Сложные манипуляции вообще осуществимы только консолью

Вот именно — Git НЕРАСШИРЯЕМ, и потому разрабы IDE сильно стеснены в своих возможностях взаимодействать с ним. В Mercurial за счет расширяемости можно было делать, например, shallow clone, который из коробки не поддерживался, как и целая куча других фич, оформленных в расширения, часть которых шла в стандартной поставке.

tig намного удобнее для просмотра истории коммитов чем в гитхабе или в гитлабе

Да, просмотр истории на гитхабе/лабе отвратителен.

Ну да, а потом бац - твоего репозитория нет по каким-то причинам

Ну на своем сервере же гитлаб.

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

буквально через пару лет ввели Git

Осознали ошибку, но было уже поздно

Не осознали — интерфейс BitBucket так же уныл, хотя GitLab успешно взлетел.

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

А я тебе отвечаю, что без «модульности» разрабатывать софтину малым числом людей проще и быстрее

Пятнадцать лет. Это о многом говорит

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

Прикольно, а разработчиков всё ещё 2. Правда, это сравнительно ничто

Посмотри, сколько репозиториев на гите (сотни миллионов), и сколько из этих людей участвует в разработке Git.

Для написания статей? Значительная

Ну я тебе линканул статью «почему гит говно и мы создали собственную VCS» — что тебе еще нужно? Том-сборник таких статей?

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

Это лишь значит, что разработчикам Fossil не понадобилась эта фича. Почему — спрашивай у них. Они не стартап и не планируют коммерческую разработку Fossil.

Просто Fossil откровенно слабый пример, если его сравнивать с GitHub. Что-то на уровне GNU Savannah, а может быть даже и ниже.

Я уже ответил в удаленном треде, что MS переориентируется на облако. Если в облаке люди работают на маках, то MS будет ориентироваться на маки. Им не нужны никсы, им нужно Software as a Service.

Так вот как такое получилось, что в облаках и мобилках про которые ты говорил выше, UNIX-like сидят и UNIX-like’ами погоняют, а Microsoft должен под них подстраиваться? У них есть неплохой NT Kernel, но в Windows они вынуждены вкорячивать Linux. У них есть Azure, но большая часть виртуальных хостов там – Linux и т. д., а разработчики Azure в Microsoft клали на дотнеты и используют MacBook’и с Java.

Я ставил постгрес и мускуль (на Windows)…

Продолжение истории: а потом в PostgreSQL и MySQL/MariaDB нашли дырки. Те, у которых эти БД были в Linux как обычно обновились на минорную версию пакетным менеджером, а те у которых они были в Windows установленные через EXE, как всегда забыли про обновление, базы остались дырявыми и утекли сотрудникам безопасности СберБанка.

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

А раз клиенты облаков выбирают никсы, Microsoft’у нужны никсы. Иначе WSL/WSL2 бы просто не существовал.

А с геморром можно и на SVN всё это делать.

Недостатки и проблемы SVN с её потерей истории гораздо существеннее «ой, в Git это как-то не очень гладко».

то любой человек мог бы создать свой собственный сервер

Там по дефолту есть же аскетичный CGit, на котором тоже много проектов сидит, кто не хочет тяжёлую инфру вроде GitLab’а поднимать.

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

Посмотри, сколько репозиториев на гите (сотни миллионов), и сколько из этих людей участвует в разработке Git.

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

Том-сборник таких статей?

Ещё и одного тома не хватит. То что, кому-то не нравится гит я понимаю, но это частный случай.

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

Что я должен дальше с этой блевотиной делать?

А что ты, собственно, ожидал от TUI? В любой IDE с поддержкой Git этот Blame выглядит красивенько и интерактивненько. В т. ч. и в GitHub.

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

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

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

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

Сто раз тыкали носом в треде, это все до первого коммита. В svn ты или делаешь что-то на сервере, или не сохраняешь вообще никаких изменений. Можно, конечно, как деды, копировать папочку с чекаутом :) Это всё не серьёзно.

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

Давай назовём это «плохой UX» :) Хотя бы само существование merucial_keyring как сущности, отдельной от mercurial.

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

Просто Fossil откровенно слабый пример, если его сравнивать с GitHub. Что-то на уровне GNU Savannah, а может быть даже и ниже

Так я не спорю, Я спорю с тем, что GitHub нужен как инструмент DVCS. Fossil намного больше DVCS, чем GitHub.

Так вот как такое получилось, что в облаках и мобилках про которые ты говорил выше, UNIX-like сидят и UNIX-like’ами погоняют, а Microsoft должен под них подстраиваться?

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

У них есть неплохой NT Kernel, но в Windows они вынуждены вкорячивать Linux

Эм-м-м, а ты, значит, не в курсе, что Win32 — это надстройка над Win NT? У самого NT совершенно иные интерфейсы. WSL повесили над Win NT точно так же, как и Win32.

Те, у которых эти БД были в Linux как обычно обновились на минорную версию пакетным менеджером, а те у которых они были в Windows установленные через EXE

Обновление версии СУБД на работающем сервере — это очень щекотливая тема. Как правило, СУБД считается дырявой по умолчанию (каковой она и является) и доступ к ней по максимум режут.

Недостатки и проблемы SVN с её потерей истории гораздо существенне «ой, в Git это как-то не очень гладко»

«Не всё гладко» плавно перетекает в «этим невозможно пользоваться» по мере укрупнения проекта. У SVN сильно меньше проблем из-за масштаба проекта.

Там по дефолту есть же аскетичный, на котором тоже много проектов сидит, кто не хочет тяжёлую инфру вроде GitLab’а поднимать

Да, но на дефолтном почти ничего нет. «Тяжелая инфра» и прочие костыли нужны потому, что дефолт безумно уныл.

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

Давай назовём это «плохой UX» :) Хотя бы само существование merucial_keyring как сущности, отдельной от mercurial

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

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

Что я только что прочитал? Я скажу как делаются нормальные проекты. Тебя просят подправить твои коммиты. И чтобы не лепить коммиты с правками к коммитами на каждое замечание, ты делаешь rebase. Чтобы сместить свои коммиты вверх и проверить, что в текущем состоянии они не конфликтуют с четкой, в которую их закинут - делаешь rebase.

Нет, merge вообще делать не нужно!

Ну желательно, чтобы этот мердж прошёл как fast-forward. Вот ты и изобрёл ребейз.

если следовать такому правилу, то будет тонна ненужных коммитов в истории

хахаха, ссылка на сайт микрософт, вот уж топовый источник инфы по тому как «надо делать проекты»

@Reset , @kilokolyan , @reprimand , @grem

Можете посмотреть и поискать мусорную историю: https://github.com/microsoft/STL

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

Как минимум нормальные проекты делаются по-разному.

Rebasing a PR would require a force push, which is undesirable after reviewing has begun (because it makes incrementally reviewing changes difficult). It can be necessary in extreme circumstances but should generally be avoided. A plain merge from main to your PR branch is fine and doesn’t interfere with incremental reviewing. As long as the PR currently displays no merge conflicts, it is generally unnecessary to merge main, but it can be a good idea sometimes - notably for toolset updates, which could break your PR’s code without any textual merge conflicts.

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

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

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

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

Не ломает, так как в forse исправленные замечания. Сами замечания не исчезают ни из рассылки, ни из github

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

На git ситуация не сильно проще и такая практика просто запрещается

А мужики-то не знали, лол!

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

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

Не ломает

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

Так я не спорю, Я спорю с тем, что GitHub нужен как инструмент DVCS. Fossil намного больше DVCS, чем GitHub.

GitHub нужен как инструмент DVCS. Опыт работы с SVN, в котором нужно было интернет-соединение на каждый чих и в которым терялась история показывает, что модель DVCS применяемая на GitHub успешна. А что в твоём понятии «намного больше DVCS»? Какие там у Fossil есть киллер-фичи по части DVCS, которых нет в Git?

Позже выяснилось, что на облако такая ОС очень плохо налазит, сейчас её обрезают по максимуму и есть довольно компактные версии десятки, и не исключено, что в каком-то будущем винда станет довольно популярной облачной осью — но не сегодня, сегодня MS прощелкало клювом.

Как показывает практика, на Raspberry Pi и прочих IoT десятка (уже одинашка) что-то не особо взлетает. А значит и до облаков винду так скоро не допилят, точно не в ближайшем будущем. Или допилят, но будет как с Mercurial, когда весьма неплохая DVSC оказалась никому не нужна, потому что сегмент уже был занят и корпорации ставку на него сделали.

Эм-м-м, а ты, значит, не в курсе, что Win32 — это надстройка над Win NT? У самого NT совершенно иные интерфейсы. WSL повесили над Win NT точно так же, как и Win32.

Да какая разница, как там всё на низком уровне? Я тебе про факт: дисяточка «для программистов» идёт с Linux-ядром и Ubuntu-окружением в комплекте, потому что стандартные виндовые тулзы для этого дела как ты выразился, Microsoft прощёлкал клювом. И да, если WSL и был поверх NT Kernel, то WSL2 теперь чисто Linux в виртуалке.

«Не всё гладко» плавно перетекает в «этим невозможно пользоваться» по мере укрупнения проекта. У SVN сильно меньше проблем из-за масштаба проекта.

Я искренне не понимаю, зачем и для каких целей ты пытаешься натягивать какие-то совсем экстремальные кейсы на Git вроде: «в индекс Git’а добавили весь исходный код Windows из 5 млн. файлов и он теперь тормозит. Ха-ха! А я вам говорил, вон оно, качество прыщеподелки!».

По мере укрупнения проекта в компании здорового человека он должен разбиваться на отдельные модули и репозитории. А релиз должен готовиться через какой-нибудь супермодуль, содержащий только подмодули (ссылки на стабильные коммиты других реп). Вот, например, как это красиво сделано в Qt: https://code.qt.io/cgit/ и они вообще не знают проблем со своей огромной кодовой базой сравнимой по количеству строк с Linux. Бонусом подобный подход обеспечивает должный уровень декомпозиции и абстрагирования.

Навалить весь код в один репозиторий-кучу (прямо подход Fossil) и заявить: «Вот оно! РЕПОЗИТАРИЙ! СМОТРИ КАКОЙ БОЛЬШОЙ!» – очень глупо.

Да, но на дефолтном почти ничего нет. «Тяжелая инфра» и прочие костыли нужны потому, что дефолт безумно уныл.

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

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

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

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

Ну так делай это в другой ветке, не из которой будешь делать пул реквест

grem ★★★★★
()

почему и когда GitHub всех сожрал?

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

никому на самом деле не нужен Git

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

в глазах почтенной публики это скорее консольный клиент для GitHub и его клона GitLab

Нужно определиться, какая аудитория имеется ввиду. Есть кодеры одиночки, есть опенсурс / клоседсурс команды, есть школоло говнокодеры. И что вообще имеется ввиду - неумение пользоваться инструментом?

В коммерческой разработке частенько используют локальные инстансы. Также есть свободные аналоги: gitea, onedev, Kallithea, GitBucket и прочие. Из проприетарщины больше популярен BitBucket, из-за его сервисов. И для одиночного кодинга самое то, потому что приватные репы. Но веб интерфейс тормозит, как мразь.

Кто сколько какуль куда залил - это не показатель отрасли. Крупные проекты переедут, если что.

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

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

В Fossil вероятность этого гораздо выше, поскольку функционала для атаки банально больше и всё это находится в одном процессе.

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

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

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

Bitbucket

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

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

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

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

А типа у нас социального кодинга до GitHub небыло почти, что ли?

Вообще не было. Если не считать помойный sourceforge, который с годами стал только хуже.

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

Дело в том, что для поддержания согласованности сорцов нужен единый центр принятия решений. Как в распределенных СУБД.

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

Централизированный репозиторий — это очень хорошо, не подумайте, что я его виню в чем-то. Мои претензии относятся только к Git, который используют в роли SVN с локальным кэшированием истории.

Ну а как иначе обмениваться изменениями из множества распределённых репозиториев? Теоретически можно пушить во все сразу, но для этого нужно по крайней мере знать об их наличии и иметь к ним доступ. В случае Linux все дороги (PR-ы) ведут к Линусу (ну или к Грегу) и по настоящему форкать ядро никто не хочет. Та же модель используется и в большенстве других проектов. Ты это воспринимаешь как центральный сервер, но он не центральный, а консолидирующий.

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

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

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

А что в твоём понятии «намного больше DVCS»? Какие там у Fossil есть киллер-фичи по части DVCS, которых нет в Git?

Как минимум багтрекер и вика у Fossil тусят в том же репозитории. CI/CD подключается через автопуш в Git-репу.

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

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

Я искренне не понимаю, зачем и для каких целей ты пытаешься натягивать какие-то совсем экстремальные кейсы на Git вроде: «в индекс Git’а добавили весь исходный код Windows из 5 млн. файлов и он теперь тормозит. Ха-ха! А я вам говорил, вон оно, качество прыщеподелки!»

Проблемы начинаются сильно раньше, в случае сорцов винды ситуация находится уже на уровне «абсолютно неприемлимо». Даже банальное закидывание достаточно жирных бинарников в репу со временем создает большие трудности. Ядро Linux уже имело бы серьезные проблемы с Git, если бы в сорцах ядра были тесты — их спасает именно то, что там нет тестов.

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

И я напоминаю, что в Git адекватной поддержки подпроектов нету — поэтому все городят собственные костыли. В том числе гугл для своего андроида.

https://code.qt.io/cgit/

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

Если ты читал по линку новость про SDL2 и почему они ушли с Mercurial, то одним из их аргументов как раз был унылый дефолт местного аналога CGit

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

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

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

В Git есть stash. Почему-то в остальных VCS позаботились о процессе разработки и незакоммиченные изменения в них сохраняются без лишних телодвижений.

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

Нужно определиться, какая аудитория имеется ввиду. Есть кодеры одиночки, есть опенсурс / клоседсурс команды, есть школоло говнокодеры. И что вообще имеется ввиду - неумение пользоваться инструментом?

Имеется в виду большинство аудитории, то есть, 95%, которые и определяют популярность. Пользоваться Git очень сложно, потому максимум, что делают эти 95% — копипастят команды из Stackoverflow. Собственно, я сам это делаю, потому что это единственный способ быстро решить проблему, не тратя пары месяцев на изучение принципов работы Git.

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

В Fossil вероятность этого гораздо выше, поскольку функционала для атаки банально больше и всё это находится в одном процессе

Я ж не спорю. Еще она выше, потому что интенсивность поддержки и тестирования ниже.

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