LINUX.ORG.RU

Там опять Go ругают

 , ,


4

9

сабж

Статья вызвала бурю эмоций на HN.

Сама статья мне очень понравилась. Очень красочно описывает моё отношение к Go.

This fake “simplicity” runs deep in the Go ecosystem. Rust has the opposite problem - things look scary at first, but it’s for a good reason. The problems tackled have inherent complexity, and it takes some effort to model them appropriately.

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

PS: Работа со строками в Go напомнила недавний холивар (C рулит и педалит.). @grem’у понравится. Путь к файлу содержит недопустимые символы? Та забей!

@WitcherGeralt

★★★★★

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

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

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

Если бы такой скрипт существовал, то его и без тебя написали бы. Но он существует только в твоей фантазии. И git тут совсем не при чём. Тебе нужна крёстная фея, которая будет магическим образом залазить в головы группы разрабов, потом к заказчику, и разрешат всё это и фиксить ошибки. Да – git такого не может, но он и не для этого. И Золушкой не нужно быть – я считаю, что это плюс

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

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

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

В консоль. А рефлог живет в репозитории. Ращница понятна?

А стэш у нас где живет? Не в репозитории? Или ты о том, что stash нельзя pull-нуть? Да, нельзя, только через commit можно передавать правки.

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

Но ты можешь применять стэш на неограниченное число ревизий.

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

Ну тут я согласен. Разговор изначально бы о «пукнул — закоммить».

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

В mercurial, емнип, по умолчанию пушит все ветки :(

Да, нужно делать «hg push -r .», если хочешь только текущую. Можно псевдоним под это дело создать.

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

У Mercurial неотрывно от ядра существуют как минимум команды «annotate bisect branch clone commit diff log merge pull push rename revert update», и даже «serve», которое запускает встроенный веб сервер.

...которые есть в Git, исключая веб-сервер. Хотя, быть может, и его уже завезли.

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

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

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

Это значит, что нет дополнительных итераций - человек переключается в мою ветку и работает вместо того, чтобы тянуть целый репозиторий хрен знает откуда. Твой rsync просто лишняя сущность, которая не несет в себе никакого смысла. Зачем он?

Каких еще два инструмента для одного действия?

VCS + rsync, чтобы хранить свои потенциально бесполезные исходники.

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

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

rsync - это средство для эффективной синхронизации между компьютерами. Там уже не важно, кто из этих компьютеров клиент, а кто - сервер. БД и документы должны лежать и на серверах, и на клиентах, потому что даже 100 Мб постоянно гонять по сети туда-сюда не есть прикольно

Это как раз важно, т.к. только сервер содержит в себе полную базу сорцов, документов, любых других данных. На клиенте копии обычно частичные, поэтому и бэкап на нем делать большого смысла нет. Ну подтянешь, если ШЕФ ВСЕ ПРОПАЛО, снова с сервера.

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

Ну насчет документации я частично даже согласен, но начинать изучение с reference manual - это плохая идея. Причем не только для Git.
С другой стороны, всегда можно использовать что-нибудь вроде https://rogerdudler.github.io/git-guide/index.ru.html.

VCS можно освоить за день, если это не Git. Это же написано и в сообщении, на которое ты отвечаешь.

Да в общем-то на практике осваивается. Я переводил наши репы с SVN на Git, провел лекцию для товарищей, с ним незнакомых, и пару дней спустя все уже спокойно работали. Главное - понимать базовые концепции.
Пример из жизни, кстати, не единичный. В институте, когда группой работали над проектом, особых проблем с освоением Git тоже не возникло.
Реальный опыт интереснее абстрактных страшилок, согласись?

Мы снова возвращаемся к вопросу «зачем вообще здесь нужен Git?». Если человек в твоем сценарии все равно пользуется только ограниченным набором команд, а при любых проблемах просто делает «git diff ... > ~/backup.patch; rm -rf; git clone» и идёт по второму кругу.

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

Да, всё становится ясно после прочтения исходных кодов Git и разбора внутренних структур.

https://www.youtube.com/watch?v=S770Fb2Jsxk

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

А это тогда что?

По-идее, в такой коллекции еще за компанию должен быть пак каких-нибудь мерж-драйверов, smudge/clean фильтров, полезных хуков и всех остальных способов расширения гтиа функциональностью :)

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

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

Собственно, почему бы и нет? Хотя я бы просто поправил конфликт.

cherry_boy
()
Ответ на: комментарий от kostyarin_

wget repo.tar
wget checksum
sha256 repo.tar
use eyes to compare the sums

Что это за дичь? Откуда здесь гарантия, что «wget checksum» не придет фальшивая вместе с repo.tar в результате MitM атаки? Если ты про докачанность архива, то обычно тарболы жмут, хотя бы минимальным gzip, который выдаст «unexpected end of file» при повреждении. В итоге это ограничивается чем-то вроде «wget -qO- URL | tar xvz - -C /target/directory».

У этой схемы есть настоящие проблемы, причем, весьма серьезные, но ты их почему-то не упомянул.

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

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

cherry_boy
()
Ответ на: комментарий от annulen

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

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

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

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

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

Но на эту простоту натягивают сложный распределенный механизм «каждый пердит под своё одеяло», а потом этот механизм «упрощается» при помощи Git.

Как показывает практика – подход git отлично работает.

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

Git не́ был стартапом, т.к. для того, чтобы он стал понятен кому-то кроме самого Линуса (а Линус его писал для себя и Ядра, т.к. система патчей и тарболов себя исчерпала), пришлось нанять специального японца, который полностью переработал UI. Боюсь, что это просто твоё нежелание осваивать новый инструмент (инертность).

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

А стэш у нас где живет? Не в репозитории?

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

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

Откуда здесь гарантия, что «wget checksum» не придет фальшивая вместе с repo.tar в результате MitM атаки?

Оттуда, что ты сравниваешь с Git, где репозиторий можно взять откуда угодно и по SHA1 сумме проверить его. И вообще всё это вшито. А в твоей схеме тарбол может отдавать только «доверенный центр». Ты сравнивай-то конкретно, а не фигню. Вообще-то хелловорды можно и на задворках вселенной харнить, а вот сорц ядра где-нибудь в Ширяево с иторией лучше выкачивать по GPRS с местной локалки, которой нет доверия, а не лезть в интернет. Ну и так далее. К тому же репу тебе может принести кент на флешке. Или ты не уверен в собственном хранилище. И так далее. Ты сравнивай. Сравнивай.

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

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

Примитивными считаю ЯП без нормальной стандартной либы, если это не обосновано (как в ANSI C, но только в ANSI). При любом раскладе на этапе написания стандартной либы все косяки выяснятся, конечно если она не крохотная как у Раста. И именно поэтому он так и останется альфа-альфа-роллинг-релиз-публичный-дом. Т.к. основные косяки отрабатываются уже сообществом, а не разработчиками ЯП. Что вносит энтропию. Стандартная либа – это одновременно и плацдарм для базовой отработки ЯП, так и определение реальных (а не эфемерных, мнимых) границ его применимости. Плюс к этому – code style и основные практики предложенные не каким-то васяном – всё это есть в стандартной либе. Так что пусть твой Раст головы не поднимает. Суслику он в подмётки не годится.

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

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

https://github.com/github/hub/tree/master/github - Go на регулярках
https://github.com/mislav/git-deploy/blob/master/lib/git_deploy/configuration.rb - Ruby на регулярках
https://github.com/aanand/git-up/blob/master/lib/git-up.rb - снова он же
https://github.com/k4rthik/git-cal/blob/master/git-cal - Perl... ну вы поняли
https://github.com/mhagger/git-imerge/blob/master/git-imerge - Питон

import re
import subprocess
from subprocess import CalledProcessError
from subprocess import check_call

Короче говоря, это костыли, которые парсят текстовый вывод команд Git. Можно оформить вызов и парсинг в отдельную либу для написания аддонов: https://gitpython.readthedocs.io/en/stable/ . Но в итоге вы все равно постепенно придете к тому, что правильный Git — это Mercurial.

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

Эм-м-м... вообще-то Git тянет целый репозиторий.

Твой rsync просто лишняя сущность, которая не несет в себе никакого смысла. Зачем он?

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

VCS + rsync, чтобы хранить свои потенциально бесполезные исходники.

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

Это как раз важно, т.к. только сервер содержит в себе полную базу сорцов, документов, любых других данных. На клиенте копии обычно частичные, поэтому и бэкап на нем делать большого смысла нет. Ну подтянешь, если ШЕФ ВСЕ ПРОПАЛО, снова с сервера

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

Ну насчет документации я частично даже согласен, но начинать изучение с reference manual - это плохая идея. Причем не только для Git.
С другой стороны, всегда можно использовать что-нибудь вроде https://rogerdudler.github.io/git-guide/index.ru.html

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

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

Реальный опыт интереснее абстрактных страшилок, согласись?

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

Да, свидетелем каких-то глобальных катастроф я не был, максимум — это кривой rebase, который для Git прошел успешно, только после него приложение перестало работать.

Мы снова возвращаемся к вопросу «зачем вообще здесь нужен Git?». Если человек в твоем сценарии все равно пользуется только ограниченным набором команд, а при любых проблемах просто делает «git diff ... > ~/backup.patch; rm -rf; git clone» и идёт по второму кругу.

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

Потому что, например, SVN позволяет выполнять типовые сценарии проще. Да, нетиповые будут сложнее, но и в Git они тоже непростые.

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

Чем это отличается от ситуации, когда ты слил работающий код в основную ветку, а он там не взлетел?

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

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

Как показывает практика – подход git отлично работает

Вот ты и спалился. Отлично работает где? Или в мире не бывает людей, которые не следуют твоим догмам? А как насчет гугла, который может запросто создать свой VCS, но предпочитает пользоваться Perforce? Они еретики?

Git не́ был стартапом

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

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

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

Stash отображается в «git reflog --all». В обоих случаях ref придется искать, по каким-то отличительным чертам или по предыдущей производимой операции.

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

Вот ты и спалился. Отлично работает где? Или в мире не бывает людей, которые не следуют твоим догмам? А как насчет гугла, который может запросто создать свой VCS, но предпочитает пользоваться Perforce? Они еретики?

У них там был SVN в код.гугл.ком. А внутри они использовали Перфорц. Хватит выдумывать, что они там что-то могут. Меня не интересуют твои фантазии.

Дальше. Да, просто оглянись. И под диваном тоже посмотри. То что говорил тот чувак выше – git – стандарт де-факто. Кто этого не понял будут существовать и дальше, но мне какое дело? Я тебе уже говорил, что если ты живёшь с людьми и работаешь с ними, то с ними и считайся. Другого варианта просто нет. Для тебя подходят тарболы или Ртуть? Ну и что с того – больше никому они не нужны. Всё – вопрос можно закрыть. Твоя внутренняя боль или что там у тебя – конечно очень интересна, но и ей пора бы уже поутихнуть.

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

Ну вот и славно. Ещё не в тему пиши, не стесняйся.

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

Stash отображается в «git reflog –all». В обоих случаях ref придется искать, по каким-то отличительным чертам или по предыдущей производимой операции.

Стэш не предназначен для чего-то связанного с деревом. Если тебе нужно что-то перенастроить для локального тестирования – то стэш отлично подходит. Но не больше.

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

Оттуда, что ты сравниваешь с Git, где репозиторий можно взять откуда угодно и по SHA1 сумме проверить его

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

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

И тем не менее за эти годы Git полностью вытеснил другие VCS, не смотря на то, что якобы у него плохой user interface. А это значит, что о user interface кричит только меньшенство, которое Git не сильно-то использует и знает. А для большинства важно performance, и поэтому Mercurial в жопе. На самом деле, Git user interface не так уж и плох, а документация по нему очень хорошая, так что тем, кому нужно разобраться, это не составляет труда.

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

В середину истории ты ничего не сможешь добавить - хэши разойдутся с другуми клонами, так что твой руткит будет лежать на самом видном месте)

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

И тем не менее за эти годы Git полностью вытеснил другие VCS, не смотря на то, что якобы у него плохой user interface. А это значит, что о user interface кричит только меньшенство, которое Git не сильно-то использует и знает. А для большинства важно performance, и поэтому Mercurial в жопе

Во-первых, Mercurial работает на базе сишных расширений, которые так же быстры, как сишный код Git.

Во-вторых, опрос показывает, что про интерфейс Git таки кричит большинство.

В-третьих, ты исходишь из ошибочного предположения о том, что популярность средства определяется его удобством/качеством/etc, хотя вся история IT показывает, что в этой индустрии выплывают на первые позиции куски дерьма на волнах хайпов. В этом море плавают хищники, которые сделали своим бизнесом развод (оказание услуг) тем, кто разводит стартапами инвесторов. Это то, что называется «консалтинг». Консалтеры мало чем рискуют, и когда один проект проваливается — они просто переходят на другой. Есть разные способы, чтобы нарисовать себе при этом привлекательный прортрет — а его в любых раскладах придется рисовать. Тот же Toptal по сути занимается дойкой стартапов — вот замечательный пример нарисованного портрета, пусть и в крупном масштабе.

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

По этой логике Git, как инструмент, который требует обучения и поддержки, является хорошим кандидатом для того, чтобы посоветовать его как идеальным инструмент. А если у вас ресурсов побольше, то вы можете создать свою VCS, с которой у заказчиков будет еще больше вечных проблем, как это сделали создатели Rational Synergy.

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

В середину истории ты ничего не сможешь добавить - хэши разойдутся с другуми клонами, так что твой руткит будет лежать на самом видном месте)

Можно же припорошить сотней-тысячей коммитов — никто их все просматривать не будет.

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

Короче говоря, это костыли, которые парсят текстовый вывод команд Git. Можно оформить вызов и парсинг в отдельную либу для написания аддонов: https://gitpython.readthedocs.io/en/stable/ . Но в итоге вы все равно постепенно придете к тому, что правильный Git — это Mercurial.

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

Эм-м-м... вообще-то Git тянет целый репозиторий.

А репозиторий уже есть, нужно только git pull сделать. В твоей же схеме нужно лезть куда-то, хрен пойми куда, и скачивать новый, который ты благоразумно (не очень) забэкапил.

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

Ты лучше коммить - не дай Б-г, Аннушка масло разольет а парни даже не в курсе, где последние правки по задаче лежат.

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

Как и rsync в схеме с VCS. Потому что дублируют друг друга.

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

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

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

Мне интересно, ты так говоришь не потому, что он (или любая другая VCS «старой школы») был твоим первым? Вот зашел я сейчас в доки Mercurial и не скажу, что мне так уж очевидна, например, эта команда:

bundle
create a bundle file:

hg bundle [-f] [-t BUNDLESPEC] [-a] [-r REV]... [--base REV]... FILE [DEST]
Generate a bundle file containing data to be added to a repository.

To create a bundle containing all changesets, use -a/--all (or --base null). Otherwise, hg assumes the destination will have all the nodes you specify with --base parameters. Otherwise, hg will assume the repository has all the nodes in destination, or default-push/default if no destination is specified.

You can change bundle format with the -t/--type option. See hg help bundlespec for documentation on this format. By default, the most appropriate format is used and compression defaults to bzip2.

The bundle file can then be transferred using conventional means and applied to another repository with the unbundle or pull command. This is useful when direct push and pull are not available or when exporting an entire repository is undesirable.

Applying bundles preserves all changeset contents including permissions, copy/rename information, and revision history.

Returns 0 on success, 1 if no changes found.

Options:

-f, --force	run even when the destination is unrelated
-r, --rev <REV[+]>
 	a changeset intended to be added to the destination
-b, --branch <BRANCH[+]>
 	a specific branch you would like to bundle
--base <REV[+]>
 	a base changeset assumed to be available at the destination
-a, --all	bundle all changesets in the repository
-t, --type <TYPE>
 	bundle compression type to use (default: bzip2)
-e, --ssh <CMD>
 	specify ssh command to use
--remotecmd <CMD>
 	specify hg command to run on the remote side
--insecure	do not verify server certificate (ignoring web.cacerts config)
[+] marked option can be specified multiple times
А комьюнити пишет гайды и для других VCS, потому что писать гайды - это одна из задач комьюнити.

В общем-то даже не сильно важно, понятен ли Git лично тебе, индустрия все равно постепенно переходит на него:
https://openjdk.java.net/jeps/357
https://www.python.org/dev/peps/pep-0512/
https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket
Да, это, безусловно, связано с тем, что Git использовался для сорцов ядра - +1000 к комьюнити, но так же связано и с тем, что он был гибким инструментом с эффективной и легковесной моделью веток, которую, к слову, впоследствии частично перенял и Mercurial, реализовав bookmarks, если я правильно понимаю их назначение.
Ты можешь мне возразить, что где-то до сих пор и SVN используют, но как тут говорили недавно: и на COBOL тоже где-то пишут. Исторически сложилось.
Суть басни в том, что «простота» инструмента - это не самый основной критерий.

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

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

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

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

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

Потому что, например, SVN позволяет выполнять типовые сценарии проще. Да, нетиповые будут сложнее, но и в Git они тоже непростые.

Дооооо, рассказывай мне: https://ibb.co/FmtdWnw.

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

Ну он в целом прав - работать с коммитами проще и безопаснее.

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

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

Ну если ты настолько отбытый, что берёшь хэш из недоверенного источника – то тебе ничего не поможет. Почитай про безопасность. Может посветлеет в твоём черепе. Это ты от SVN или от Mercurial так деграднул, вот интересно?

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

Во-первых, Mercurial работает на базе сишных расширений, которые так же быстры, как сишный код Git.

Mercurial намного тормознее Git. И Си ему не поможет. Си – это не решает архитектурных проблем. Тормозное говно и на Си будет тормозным говном.

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

А если у вас ресурсов побольше, то вы можете создать свою VCS, с которой у заказчиков будет еще больше вечных проблем, как это сделали создатели Rational Synergy.

Лишних ресурсов. Давай найди мне таких, кто хотел бы из-за нелепой прихоти выкидывать деньги. (Ответ никто).

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

Можно же припорошить сотней-тысячей коммитов — никто их все просматривать не будет.

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

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

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

Как ты думаешь, что будет с этими костылями, если в Git внезапно добавится дополнительный символ в выводе? А я тебе скажу: в Git не добавится дополнительный символ, интерфейс навсегда останется допотопным говном мамонта, а более удобные нужно будет вызывать через «git log --graph --oneline --decorate», который можно повесить на дополнительный костыль для удобства.

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

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

Эм-м-м... вообще-то Git тянет целый репозиторий.

А репозиторий уже есть, нужно только git pull сделать. В твоей же схеме нужно лезть куда-то, хрен пойми куда, и скачивать новый, который ты благоразумно (не очень) забэкапил

Ты имеешь в виду, что твои ручные усилия по созданию копии рабочих данных могут внезапно оказаться кому-то полезными, поскольку ты можешь сообщить имя ветки или хэш ref-а, и, без дополнительных действий с твоей стороны, человек может после fetch, которую он может быть уже сделал, забрать эту правку. В схеме с бэкапами мне нужно было бы вручную отправить мою версию на сервер и сообщить другому челу идентификатор для скачивания, либо аналогичную операцию сделать коммитом в VCS для этого конкретного случая. Лично на мой взгляд последний вариант кажется предпочтительнее, поскольку здесь VCS используется по прямому назначению — для командной работы с исходниками.

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

Как и rsync в схеме с VCS. Потому что дублируют друг друга

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

Я доводил это почти до абсурда, когда приводил пример с тарболом, который тоже требует не так уж и много времени — так зачем тогда нужен Git? «patch, diff, tar» — джентельменский набор разраба. И времени не так много требует, но отвлекает слишком много для своей функции, поскольку нужно не ошибиться, создать правильный патч с правильной версией, не перезаписать случайно старые нужные файлы.

Аналогичная картина с Git: он требует слишком много внимания для той незначительной задачи, которую выполняет. Когда мне нужно поделиться с другим разрабом — я делаю это, я переключаю внимание на эту задачу, я убеждаюсь, что другой разраб получил именно то, что я хотел. «Релиз» закончился — всё VCS мне не нужна.

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

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

Мне интересно, ты так говоришь не потому, что он (или любая другая VCS «старой школы») был твоим первым? Вот зашел я сейчас в доки Mercurial и не скажу, что мне так уж очевидна, например, эта команда

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

В общем-то даже не сильно важно, понятен ли Git лично тебе, индустрия все равно постепенно переходит на него:
https://openjdk.java.net/jeps/357

Интересные ссылки, спасибо. Сразу хочется ответить на «Size of version control system metadata» из этой ссылки:

jdk/jdk repository is approximately 300 MB with Git and the .hg directory is around 1.2 GB with Mercurial, depending on the Mercurial version being used

Они что-то накосячили, не бывает таких разбросов по размерам, максимум, что мне удалось находить — в два раза больше Mercurial, и было это десять лет назад. В других же случаях репа Mercurial была и поменьше Git. Я сейчас сконвертировал репу проекта с моего рабства Git->Mercurial, и у меня получилось 143->124 Мб. Еще конвертирую репу Emacs, позже доложу. Я бы еще попробовал сделать Mercurial->Git, но костыли под эту конвертацию не так-то просто запустить — буду рад, если кто-то проведет такой тест.

https://www.python.org/dev/peps/pep-0512/

Простые люди вообще не понимают, насколько всё печально в разработке питона — это test-driven implementation-defined система, примерно как в Oracle RDBMS, только поменьше масштабом, в которой тестов много и выполняются они долго. Им нужен был не Git, им нужна была система для принятия патчей и автоматического тестирования. Поскольку в GitHub нет Mercurial, то пришлось пользоваться Git. А учитывая то, что мне в 2019 году разраб отвечал спустя полмесяца (не принял патч, а просто написал первый ответ), я бы не сказал, что GitHub как-то фундаментально снял нагрузку с разрабов — их по прежнему мало и они очень заняты.

https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket

Это бизнес. Если люди покупают китайской дерьмо, то мы будем возить им китайское дерьмо.

Да, это, безусловно, связано с тем, что Git использовался для сорцов ядра - +1000 к комьюнити, но так же связано и с тем, что он был гибким инструментом с эффективной и легковесной моделью веток, которую, к слову, впоследствии частично перенял и Mercurial, реализовав bookmarks, если я правильно понимаю их назначение

Это вопрос определений. Принципы хранения репозитория у всех DVCS похожи. Ветки Mercurial и ветки Git — это разные вещи, названные одним словом, и ни одна из этих вещей не имеет однозначного соответствия в структуре хранимых данных. У Mercurial, как у SVN, branch - это вообще все коммиты, которые вышли из коммита с заданным именем ветки. bookmarks же в Mercurial — это конкретный коммит, обычно голова некоторой ветки, с которой ведется работа, и на который можно обновиться одной командой и при этом быть уверенным, что это именно моя ветка, а не вторая голова, которая была подтянута через pull.

Ты можешь мне возразить, что где-то до сих пор и SVN используют, но как тут говорили недавно: и на COBOL тоже где-то пишут. Исторически сложилось

При четко централизированной разработке пользоваться SVN проще, работает она быстрее, процессор и хранилище занимает только на сервере. К тому же, она умеет в доступы и блокировки, которых в Git вообще нету. То есть, Git в централизованной разработке вообще не является конкурентом SVN, и по сути выбор в 2020 году стоит между Perforce и SVN. Если есть большие и/или бинарные файлы — Git снова идет лесом. По этим причинам для многих закрытых коммерческих разработок Git является плохим выбором, но некоторые конторы берут Git, потому что «все используют Git», а в конторе никто в VCS не разбирается.

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

Это все, конечно, интересно, но мы вроде про порог вхождения разговаривали, а ты мне байки про продакшн травишь. Причем VCS там вообще не пришей рукав к одному месту...
Второй случай больше говорит о том, что у вас нет формализованного и описанного где-нибудь на вики flow + новым сотрудникам не выделяется ментор из числа опытных разработчиков, чтобы недельку-две поводить их за ручку по проекту и вообще рассказать, как устроен рабочий процесс.
Короче, если в бригаде глухонемой прораб и пьяные строители, то виноваты точно не кирпичи

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

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

Потому что, например, SVN позволяет выполнять типовые сценарии проще. Да, нетиповые будут сложнее, но и в Git они тоже непростые.

Дооооо, рассказывай мне: https://ibb.co/FmtdWnw

Это скрин ответа:
https://stackoverflow.com/questions/1554278/temporarily-put-away-uncommitted-...
и этот ответ неправильный. Причина, почему нельзя так создавать ветки, описана сразу под ответом: «this will result in a lot of trash on your subversion server». Да, я использовал разные папки для релиза и для разработки, но нужно понимать, что помимо сорцов там были еще и выходные модули, которые нельзя просто за две секунды взять из репы через checkout.

Автор вопроса почему-то выбрал неправильный ответ, но правильные ответ получили больше плюсиков:

«git stash» approximately becomes «svn diff > patch_name.patch; svn revert -R .»
«git stash apply» becomes «patch -p0 < patch_name.patch»

Это же под капотом делает «git rebase», «git stash», «hg diff; hg import» и расширение Rebase.

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

Я сейчас сконвертировал репу проекта с моего рабства Git->Mercurial, и у меня получилось 143->124 Мб. Еще конвертирую репу Emacs, позже доложу. Я бы еще попробовал сделать Mercurial->Git, но костыли под эту конвертацию не так-то просто запустить — буду рад, если кто-то проведет такой тест

Итак, репу Emacs клонировал через "--single-branch", то есть, брал только мастер, но судя по результатам похоже на то, что в итоге подтянулись почти все коммиты. 140 тысяч коммитов, 3 часа процессорного времени, 17 Гб оперативы в пике, 290 Гб прочитано, почти гигабайт записано. 342 Мб репа Mercurial, 301 Мб репа Git. Такие вот дела.

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

Они что-то накосячили, не бывает таких разбросов по размерам, максимум, что мне удалось находить — в два раза больше Mercurial, и было это десять лет назад.

Вот прямо сейчас:

https://github.com/mozilla/gecko-dev
$ du -sh .git
2.6G	.git

https://hg.mozilla.org/mozilla-unified
$ du -sh .hg
5.3G	.hg

Уф, еле дождался завершения выполнения последней команды. Не удивительно:

gecko-dev$ find .git | wc -l
56

mozilla-unified$ find .hg | wc -l
606825

При этом самих исходников:

gecko-dev$ find -path ./.git -prune -o -print | wc -l
309523

КПД mercurial по количеству файлов выглядит совсем печально.

На винчестере git pull --rebase занимает пару минут. hg pull -u где-то в 5 раз больше. Удручающе.

.hg directory is around 1.2 GB with Mercurial, depending on the Mercurial version being used

У mercurial есть что-то аналогичное git repack? Ведь с репозиторием работают годами с одной за другой версиями mercurial. Или нужно весь репозиторий «импортировать» с каждым новым релизом? А что если на mainline-сервере какой-нибудь oldstable?

Disclaimer: не являюсь фанатом git.

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

Чего не хватает в стандартной библиотеке раста?

Рандома, например. Другой вопрос, делает ли это раст говном, а го - крутым языком. Имхо нет.

provaton ★★★★★
()

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

Квадратно-гнездовой же!

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

Теперь мой результат, 4кБ размер блока на ФС:
https://hg.mozilla.org/mozilla-unified
.hg: 3308 МБ, на диске 4912 МБ; файлов: 565 736; папок: 41 638;
сорцы без .hg: 1784 МБ, на диске 2565 МБ, файлов: 291 216; папок: 18 861.

https://github.com/mozilla/gecko-dev
.git: 2922 МБ, на диске столько же; файлов: 24; папок: 15;
сорцы без .git: 1783, на диске 2565 МБ; файлов 291 269; папок 18 868.

Как видите, средний размер файла в репе — 6 килобайт. Соответственно, при блоке накопителя в 4 килобайт возникают веселые артефакты.

На винчестере git pull --rebase занимает пару минут. hg pull -u где-то в 5 раз больше. Удручающе

Полторы минуты «hg pull -u» у меня при наличии обновлений. Простой update на старую ревизию где-то 1:10-1:20. Сегодня почему-то очень мало правок на обоих репах, потому толком забенчить не получается пока.

У mercurial есть что-то аналогичное git repack? Ведь с репозиторием работают годами с одной за другой версиями mercurial. Или нужно весь репозиторий «импортировать» с каждым новым релизом? А что если на mainline-сервере какой-нибудь oldstable?

У нынешнего формата хранения Mercurial нет проблем, которые есть в Git и решаются при помощи «git repack». Зато есть другие проблемы, из-за чего нынче планируют сделать гибридное хранилище в Mercurial:
https://www.mercurial-scm.org/wiki/PackedRepoPlan

КПД mercurial по количеству файлов выглядит совсем печально

Этот параметр не имеет смысла.

Disclaimer: не являюсь фанатом git

Но почему-то избирательно видишь факты. Например, не в курсе опции «du --apparent-size».

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

Полторы минуты «hg pull -u» у меня при наличии обновлений. Простой update на старую ревизию где-то 1:10-1:20. Сегодня почему-то очень мало правок на обоих репах, потому толком забенчить не получается пока

Да, справедливости ради, нужно заметить, что Git всего лишь 25-30 секунд делал «git pull». Но все же это крайний случай, и я бы не советовал превращать проект на два гигабайта сорцов в помойку с сотней тысяч файлов. Сейчас достал релиз за 2011 года - средний размер файла был 7 кБ и файлов было в 6 раз меньше. То есть, ситуация прогрессирует.

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

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

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

Как видите, средний размер файла в репе — 6 килобайт. Соответственно, при блоке накопителя в 4 килобайт возникают веселые артефакты.

Но почему-то избирательно видишь факты. Например, не в курсе опции «du –apparent-size».

Я бенчил реальное использование, а не теоретическое. И даже во времена винтов с физическими секторам в 512 байт, размер кластера (блока) по-умолчанию уже давно был 4 КБ.

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

Полторы минуты «hg pull -u» у меня при наличии обновлений.

проводилось без предварительного echo 3 > /proc/sys/vm/drop_caches

По-моему, лучше не гадать, что другие знают или не знают.

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

Я бенчил реальное использование, а не теоретическое. И даже во времена винтов с физическими секторам в 512 байт, размер кластера (блока) по-умолчанию уже давно был 4 КБ

А ты в курсе, что есть разные файловые системы? ReiserFS сует несколько файлов в один блок, например. Ты измеряешь артефакты файловой системы по сути, а не влияние VCS, поскольку иначе кол-во хранимых данных у Git и Mercurial почти одинаковое.

Ведь и я тоже могу предположить, что

Полторы минуты «hg pull -u» у меня при наличии обновлений.

проводилось без предварительного echo 3 > /proc/sys/vm/drop_caches

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

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

Для системного языка - довольно большая.

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

… Ты измеряешь артефакты файловой системы по сути …

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

Это как, если бы десктопная программка для приемлемого отклика требовала 500 ГБ/с доступа к памяти. Но даже на свежих десктопах максимум где-то 50 ГБ/с. Вывод: программа не виновата, просто оборудование не подходящее, ведь сервера могут в 500. Но нет: программка десктопная, значит, нужно отталкиваться от типичных доступных ресурсов.

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

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