Comments 56
В git удручает, что это его исполнение выглядит как набор команд с неконсистентным синтаксисом и логикой работы, стройная модель в недружественной пользователю обёртке.
Поэтому я очень жалею, что меркуриал, который как по мне - лучше гита во всём - проиграл ему конкурентную борьбу. Там команды гораздо логичнее.
Ещё не вечер.
Полностью согласен. Использую hg для собственных проектов, это крайне удобно. Когда лет 10 назад встал вопрос перехода с svn, то выбор пал по результатам изучения (git vs hg) именно на Mercurial. И жаль, что bitBicket погасил поддержку Mercurial. Нормальные хостинги hg сейчас только платные. (Или приходится разворачивать свой, что в общем несложно).
И многие действительно недовольны git'ом, есть те, кто вполне серьёзно пилят got (game of trees).
Я тоже около 10 лет назад, посмотрел видео https://www.youtube.com/watch?v=idLyobOhtO4 и стал копать в сторону распределённых DVCS. Пробовал играться на не очень больших репозиториях (до 100'000 файлов) - git летал, mercurial тупил. Функционально на фоне всяких CVS/SVN/StarTeam/SourceSafe плюс/минус давали одно и то же.
есть те, кто вполне серьёзно пилят got (game of trees)
Я предлагаю всё же отделять мух от котлет. Одно дело как названы команды и флаги, другое дело как устроено собственно хранение истории. Git силён именно вторым. А взаимодействовать с ним можно хоть через UI в вашей-любимой-ide.
Ну и процитирую вашу ссылку:
Got uses Git repositories to store versioned data.
без extensions он довольно куцый, а консистентность у них уже не такая замечательная. Так что в целом, чтобы получить что-то типа того, что у Git из коробки, нужно было поднавключать кучу тех самых расширений, а потом ловить у них «набор команд/ключей с неконсистентным синтаксисом». Так что 🤷♂️
Fossil так еще лучше.
Fossil несколько специфичен. Но один небольшой экзешник и наличие из коробки интегрированных багтрекера и вики – это круть.
Идея круть, но реализация местами "чисто для себя". Багтрекеру (можно посмотреть на него в репозитории самого Fossil'а) далеко до гитхаба, гитлаба, багзиллы, первых версий багзиллы... и вот мы уже в 90-х, там и встроенный форум до эпохи форумов не дотягивает. Экспорта/импорта в другие багтрекеры (гитхаб/гитлаб) нет, пулл-реквестов нет.
Во всём, кроме скорости работы: он всегда тормозил
Ну в последних версиях вроде лучше стало. Появились всякие `git restore` например.
Интересно, спасибо, но вот последнюю цитату перевести с русского на понятный мне русский я так и не смог.
>Shoulda, coulda, woulda, my biggest regret is not money, it is that Git is such an awful excuse for an SCM. It drives me nuts that the model is a tarball server. Even Linus has admitted to me that it's a crappy design. It does what he wants, but what he wants is not what the world should want.
>Если бы да кабы... больше всего я жалею не о деньгах, а о том, что Git это просто жалкое подобие SCM. Меня сводит с ума факт, что в основе лежит сервер с файловыми архивами. Даже Линус признал, что это дерьмовый дизайн. Git работает так, как он, Линус, считает нужным, но это вовсе не значит, что весь мир должен считать так же.
А почему сервер с файловыми архивами - это дерьмовый дизайн и какой дизайн хороший?
Fossil?
Не засоряет все что можно скрытыми папками с данными, а спокойно держит все в отдельном файле SQLite.
Тут много найдётся специалистов, которые могут гитом без гит-хаба, гит-лаба пользоваться? Чтобы хотя бы в команде из 3-Х человек кодом обмениваться?
А что там сложного, если у каждого есть свой сервер? git remote update и понеслось. Без сервера - только по e-mail или аналогичному каналу - сложновато, да..
Рискну предположить что много. Достаточно создать bare репозиторий на сервере и всем троим клонировать его просто по ssh. Плюс если нужно что-то автоматизировать (например запуск тестов после каждой отправки в репозиторий) - можно вписать в этот репозиторий соответствующий хук (например post-receive).
Я так делал в небольших командах, и до сих пор делаю в личных проектах, чтобы не зависеть от сторонних сервисов, а то всё больше крупных компаний в последнее время любят отключать доступ к своим сервисам людям родившимся на территории РФ.
Ну вообще это довольно привычный сценарий. А кто до того нажрался cvs или, прости господи, source safe – вообще с удовольствием пользуются :-). Но не топ, скажем прямо.
Ну например, хотя бы отслеживающий переименования нормально? Git подобен FAT16, если сравнивать с файловыми системами - даже не с первыми юниксовыми. Линус сделал не простой дизайн, а примитивный, что вылилось в кучу сложности для пользователя - произошел перенос сложности наверх, в полторы сотни команд, не представляющих из себя стройную систему.
Потому что надо изменения отслеживать, а не снепшоты
Кому надо?
Рабиновичу.
Был вопрос «почему сервер с файловыми архивами дерьмовый дизайн [как считает автор]». Вот на него ответ. Почему — потому что в результате теряется информация (из изменения можно однозначно восстановить снепшот, а из снепшотна нельзя 100% однозначно восстановить изменения).
А я не уверен что это нужно.
Вот в SVN например можно в одном коммите удалить файл и на его же месте создать новый (можно даже с тем же самым содержимым). В результате у файла разорвётся история. Это как-то полезно?
Или люди иногда копируют отдалённо похожий на то что им нужно файл, а потом изменяют его до неузнаваемости. Есть ли какая-то польза от того что контроль версий запомнил откуда было выполнено копирование? Причём в зависимости от того был это svn cp или копирование руками, а потом svn add, история будет разной.
Или svn mv a b даёт отличную от cp a b && svn add b && svn rm a историю. И задним числом объяснить "глупая софтина, это же очевидно был ренейм" уже никак нельзя.
В общем много кейсов, когда явное запоминание изменений приводит к вредной / вводящей в заблуждение / ошибочной / утерянной информации.
Я могу только предполагать, что именно имел в виду автор цитируемого текста. Но, в принципе, альтернатива понятна: файл как базовая сущность + цепочка изменений каждого из них вместо снэпшотов файловой системы в гите.
Проблемы, обусловленные таким подходом в гите, известны: костыльная поддержка перемещения или переименования файлов, которой сначала и вовсе не было (появилась пару лет спустя), плюс невозможность полного и бесследного удаления однажды закоммиченного файла (да, есть git filter-branch, BFG cleaner, но в результате переписывается история и, по сути, получается новый репозиторий с новыми коммитами)
У автора цитаты (Larry McVoy = luckydude@HN = владелец BitKeeper) дальше было ещё два абзаца:
It says a lot that we have a bk fast-export and we can incrementally run that and get idempotent results. As in go from BK to Git on an ongoing basis, have two people do it in parallel and they both get bit for bit identical results. If you try and go the other way, Git -> BK, if you do it in parallel you get different results because Git doesn't store enough information, so BK has to make up the missing bits.
Git has no file create|delete|rename history, it just guesses. That's my biggest regret, I wish Linus had copied that part.
Вообще, на HN это место в статье тоже вызвало вопросы ("Why is this crappy? What would be better?"), но Ларри явился в комменты и ещё прошёлся по Git'у.
Здравствуйте. Спасибо за комментарий, поправили перевод
Концовка неверная, там же "не то, что должен хотеть мир", а не "не значит что".
Жаль fossil не взлетел. Один экзешник, один файл репозитория, селф-хостед веб-морда. Использовал для своих проектов.
Есть что то новое. Как Pijul based on a theory of patches но вроде тоже не взлетит.
Что придет ей на смену? Многие говорят, это будет что-то, связанное с искусственным интеллектом, но никто не может сказать наверняка. Что мы можем сказать точно: скорее всего, новый этап будет связан с рядом случайных событий и группой талантливых хакеров.
Нынешний успех Git'а связан с гитхабом, с авторитетом Линуса. Почему ситуацию должны изменить технические причины? Думаю, Git с нами до конца, он постепенно растворится в централизованных хостингах - будет всё менее важно, что у них под капотом - Git, что-то Git-совместимое или уже несовместимое, потому что хостинг будет всё дальше обрастать функцональностью и VCS будет лишь рядовой функцией среди прочих.
Жизненный пример, в википедии кто-то умудрился написать: "GitLab includes a distributed version control based on Git, including features such as access control, bug tracking...". Что включает в себя VCS, что децентрализовано, используется ли сам Git? Мы ответы знаем, но они не так уж и важны, это единая платформа. Буква D в DVCS теряет своё значение, гипотетические VCS будущего могут снова стать централизованными, It's Evolving, Just Backwards.
Принципиально новое можно внедрять в хостинг или прямо в Git, за деньги его получится развивать в нужном такой-то компании направлении (будет Git Foundation и Platinum Membership).
читал статью, постоянно спотыкаясь о топорный перевод:
"Когда они увидели, что их основной фреймворк использует GitHub, всё больше Ruby-разработчиков последовали их примеру."
я пойму, если вам нужно выполнять план по выпуску статьей. возможно поэтому очень сложно следить за хронологией. с вики:
The development of Git began on 3 April 2005
Torvalds announced the project on 6 April
The first merge of multiple branches took place on 18 April
Torvalds turned over maintenance on 26 July 2005 to Junio Hamano
1.0 release on 21 December 2005
После svn выглядит как свалка, как диск без subdirs
У меня возникли ассоциации, скорей, с микрософтовским IIS (уж не знаю, на чём для него делали такие сайты): все URL были GUIDами, и, зачастую, ещё и генерились динамически. То есть понять по URL, где ты находишься, было совершенно невозможно, и, соответственно, попасть назад по кнопке back тоже (чем-то напоминает изучение истории по git репозитарию с удалёнными брэнчами).
Тёплый ламповый svn, с последовательными номерами ревизий и классическим деревом с файлами на ветках, гораздо человечнее, что ли...
Хорошая история про попытки впаривание проприетарщины (bitkeeper), попытки подсаживания (вендор-лок) и нелепые ограничения для обычных юзеров ("нельзя использовать с другими аналогичными программами", ср. с "open source non-commercial project. Dear *******, please check it."), готовность к любым мерзостям ради этого и денег (поссорить Торвальдса и Трайджелла) и т.д., и т.п.
Радует, что всё разрешилось ко всеобщему благу появлением git'а.
Имею опыт использования меркуриала и гита
У гита поголовно интеграция с ide, в целом он проще и лучше себя чувствует когда проект линейный, с небольшим количеством ответвлений
У меркуриала централизованный адекватный гуй, который так и не смогли опакетить для линукса(хотя блин, здесь то в чём проблема?) и лучше работа с ветками
Но в данном случае это яркая победа опенсорс даже при условно более низком качестве
Да, что то может быть вроде как подобием, но комон, если есть всё нужное зачем убермегакрутое, которое будет сложнее в освоении? Называется принцип экономии мышления
Я начинал работать на проектах с CVS. Его стабильность была на особо высокой. После неё перешли на SVN и преклонил ошибок уже не было. Изначально, SVN мало чем отличался от CVS в плане команд и в плане хранения историй. Потом, в версии 1.7 (если не ошибаюсь) они перешли на SQLite формат. Плюсом этого подхода является то, что не занимаются лишние индексные дескрипторы на ФС. Из минусов - вся нагрузка ложится на движок SQLite. Мне не довелось особо протестировать его производительность. Через небольшой промежуток времени, перешли на GIT. Он сильно отличался от предшественников. Поначалу было сложно, но потом стал удобным инструментом.
Сколько продержится этот инструмент и что придёт на его замену покажет время и потребности, которые появятся в будущем.
Режет глаза, когда пытаются приделать падежи к словам на английском. Эти окончания через апостроф или кавычки выглядят скорее как попытка изобразить икоту. А что вы будете делать, если слово оканчивается на гласную букву?
В паре мест ещё зачем-то написали капсом, хотя это не аббревиатура.
Либо пишите слово без изменений, с заглавной буквы, сохраняя английскую орфографию. Либо пишите в русской транслитерации и там уже склоняйте как угодно. С гитом ничего не случится от этого.
Заглянем в книгу Правила русской орфографии и пунктуации. Полный академический справочник под редакцией В.В. Лопатина:
§ 115. Знак апостроф — надстрочная запятая — имеет в русском письме ограниченное применение (...) Апострофом отделяются русские окончания и суффиксы от предшествующей части слова, передаваемой латинскими буквами, напр.: Он инструментовал сочиненную летом c-moll’ную увертюру (Берб.)
Спасибо за пояснение! Почитал справочники, буду знать.
Однако, думаю, иностранные названия в русском тексте лучше передавать кириллицей, особенно если они графически уже освоены русским языком. Типичные такие слова: Твиттер, Фейсбук, Интернет...
Корректно писать: IT'шник, S'очка, но мы предпочитаем писать айтишник и эсочка, потому что первый вариант режет глаз. По этой же причине я против использования конструкций: Git’а, Git’ом. Не склонять слова на латинице тоже корректно и в обсуждаемой статье это местами имеется.
Для меня окончательный выбор за Git имел причиной не GitHub или другой хостинг, а 1) его модель накапливаемого "индекса" изменений и 2) философию версий коммитов, активно используемую в LKML. Никто из конкурентов, включая расхваленный многими Mercurial или оригинальный BitKeeper, не предлагал подобного и не понимал, похоже, ценность этих элементов в подходе. И, подозреваю, наиболее активные разработчики сложных проектов вроде того же Linux kernel считали это же критически важным преимуществом.
А вот использование Git 90+% нынешних разработчиков чего угодно полностью игнорирует эти возможности - они используют Git просто как ещё один centralized VCS на стероидах с возможностью временного локального хранения. Делаю такой вывод по опыту участия в корпоративных проектах. И, что хуже, основные публичные серверы вроде GitHub, Bitbucket тоже не стремятся использовать все плюсы продвинутых методов.
А вот что McVoy имел в виду под "сервером с тарболлами", я не понял. Даже с попытками разъяснений. Если кто может переформулировать другими словами, прошу таки сказать.
Никогда не понимал и до сих пор не понимаю суть этого «индекса». Это и не коммит, и в то же время что-то там отслеживает. То есть, вроде какая-то история, но на «полшишечки». В 100% случаев он только мешает и запутывает.
В 99% случаев он помогает. Например, совершенно обычная ситуация это когда у тебя в рабочей копии 100500 правок, из которых большинство это расширенная отладка, которая не должна идти в общие версии, а часть должна пойти в следующий коммит. В индекс выбирается то, что надо коммитить сейчас. Накопил порцию - наконец закоммитил, смотришь дальше.
Более сложные сценарии это, например, когда надо переносить часть кода из одного коммита в другой. Там тоже берёшь только часть изменений и добавляешь их к текущему коммиту.
Всё это помогает получать чистые коммиты с чётко определённым набором изменений в них, без ненужных изменений, и с разделением разных видов активности.
Но для 90% народа, который просто сваливает всё в одну кучу, если не заставить делать по-человечески - это всё, да, мало понятно. Увы, это типовая картина "на галерах".
Вы правда верите в то, что народ, который «просто сваливает всё в одну кучу» будет заморачиваться с тем, что сначала что-то там куда-то добавить по частям, а потом закоммитить? А остальным это только головной боли добавляет. Вместо того, чтобы просто во время коммита выбрать (как по-человечески сделано в Mercurial в его стандартном графическом клиенте), какие именно файлы/куски файла должны попасть в коммит, ты вынужден заниматься перекладыванием из пустого в порожнее. А если ещё и зафиксированный в индексе файл потом чуть-чуть поменять приходится, тут вообще всё в разнос идёт, что проще отменить все изменения индекса и сделать заново.
Вместо того, чтобы просто во время коммита выбрать (как по-человечески сделано в Mercurial в его стандартном графическом клиенте), какие именно файлы/куски файла должны попасть в коммит, ты вынужден заниматься перекладыванием из пустого в порожнее.
Графические клиенты для Git умеют то же самое и больше. Но у Git даже базовый консольный вариант умеет описанное мной - и больше - а у Mercurial на это надо фиксироваться на графическом клиенте.
А если ещё и зафиксированный в индексе файл потом чуть-чуть поменять приходится, тут вообще всё в разнос идёт
Не идёт оно в разнос. Покажите пример, что, по-вашему, "в разнос", или не верю.
Вы правда верите в то, что народ, который «просто сваливает всё в одну кучу» будет заморачиваться с тем, что сначала что-то там куда-то добавить по частям, а потом закоммитить?
С обучением и дрессировкой (кому обучения недостаточно) - да. 2-3 режекта PR/MR/как_назовёте на основании "грязь, лишнее" и начнут задумываться. Главное, чтобы это не было запорото требованием фич "на вчера".
Покажите пример, что, по-вашему, "в разнос", или не верю.
Абсолютная неясность того, что же идёт в коммит после таких действий. Очень часто я коммитил совсем не то, что по моим представлениям должно было закоммититься и нередко терял при этом все незафиксированные изменения при попытке отката. Так что я прекратил заниматься этой ерундой и просто коммичу кусками, а потом привожу всё в порядок через rebase — так предсказуемее и ничего не теряется. Так что примера не будет, увы.
Главное, чтобы это не было запорото требованием фич "на вчера".
Ну вы же сами отвечаете на свой вопрос, зачем меня ещё спрашивать?
бсолютная неясность того, что же идёт в коммит после таких действий. Очень часто я коммитил совсем не то, что по моим представлениям должно было закоммититься и нередко терял при этом все незафиксированные изменения при попытке отката.
Хм? status + diff + diff --cached - показывают всё в явном виде. Что можно было понять не так?
Ничего. Кроме того, что вы уже привели три команды, каждая из которых показывает что-то своё и ни одна не показывает то, что в итоге оказывается в коммите.
Всё это помогает получать чистые коммиты с чётко определённым набором изменений в них, без ненужных изменений, и с разделением разных видов активности.
Для получения чистых коммитов помогает rebase, а не вот это всё. И то в Git по сравнению с Mercurial он тоже сделан максимально ущербно. Единственное, в чём он лучше — в TortoiseGit есть удобное окно выбора, что делать с коммитами, в TortoiseHg, к сожалению, подобного не завезли, приходится файлик с командами редактировать.
Для получения чистых коммитов помогает rebase, а не вот это всё.
Это уже если накоммитили. Тогда, да, rebase остаётся как средство перегруппировки.
И то в Git по сравнению с Mercurial он тоже сделан максимально ущербно.
У меня противоположное впечатление. Все варианты, как я видел и испытывал возможности rebase в Mercurial, были просто неспособны ни на что серьёзное.
История Git: на этот раз не так весело