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

Ровно как в никсах принято хранить имена файлов тупо как последовательности байт

Последовательность байт - это и есть строка в какой-то кодировке. И если офтопик в силу исторически сложившихся обстоятельств использует «расширенный» (сиречь нестандартный) набор символов в своей кодировке, то с его строками не сможет полноценно работать ни одна стандартная юникодная кодировка: не то что UTF-8, но и любая UTF-16 и UTF-32. И если тот-же Питон работает только со стандартными юникодными кодировками, то он точно так-же не осилит все коды оффтопика.

Если либа умеет обрабатывать только печатные символы, то как ее называть?

Вот не надо ярлыков. Если оффтопик не придерживается юникодных стандартов - это не делает всё остальное ПО, которое соответствует этим стандартам, «редакторами».

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

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

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

Вообще-то в контексте имен файлов на ФС.

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

Спасибо, я в курсе методики принятия решений во многих конторах: ставится дедлайн «до конца недели», после дедлайна проходит два месяца - твоим решением до сих пор никто не пользуется. Вы ярмо себе повесили на годы, а всё потому, что кому-то показалось хорошей идеей за два дня принять решение при помощи людей, которые кроме Git и SVN ничего не знают.

Не драмазитируй, не в театре.
На Mercurial смотрели, но, так сказать, при прочих равных... С SVN переехали, т.к. там стали очевидными некоторые недостатки, которые для нас были критичными (в частности svn externals), а если сравнивать Git и Mercurial, то лично я не вижу, в чем бы последний превосходил. То, о чем ты говоришь - это больше вопрос привычных тебе команд, привычного workflow и личных предпочтений.

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

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

Смотри: https://ibb.co/mB8wTFR. Утрированный пример на коленке, но примерно так и обстоят дела - по крайней мере с теми ветками, которые имеют историческое значение.

Законченные промежуточные этапы я коммичу локально.

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

Хочу напомнить, что основная задача VCS - это хранение нескольких версий. В сценарии со squash/rebase Git не выполняет роль VCS, поскольку теряет версии исходников, и по этой причине его применение не оправдано. Я просто срезаю путь, и не пользуюсь Git в данном сценарии с самого начала, начиная пользоваться им там, где мне действительно нужны версии. Одной фразой мой процесс можно описать как «я просто пишу код».

Каким образом он их теряет-то?
Rebase просто закидывает твои правки на самый верх, объединяя их с правками других разработчиков. Ну, допустим, смержишь ты их без него - конечный результат тот же, только правки не наверху, а разбросаны по времени.
Допустим, мержишь ты без squash - конечный результат тот же, но правки опять же размазаны по дереву.
Если принципиально хочется сохранить оригинальный стейт, то заведи еще одну локальную ветку до rebase, хотя единственный смысл, который я вижу в подобном действии - это «в моей ветке все работает, в мастере нет, вы виноваты сами», «смотри, я закоммитил у себя раньше, поэтому исправлять должен ты» или «работали вместе, коммитил он, пусть он и отвечает». Пардон, но в нормальном, адекватном коллективе такого говна быть не должно.

В Git нет простых способов работать с грязным репозиторием. Игры с «git checkout» могут быстро закончиться потерей локальных изменений, потому интернет в один голос советует делать «git stash; git stash apply; git checkout». Что снова возвращает нас к убогости Git для простых задач.

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

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

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

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

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

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

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

Категорически не согласен. Если у коммита информативное описание, то есть высокая вероятность, что я еще на стадии его чтения пойму, заглядывать мне в этот коммит (т.е. разбираться в коде) или нет.

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

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

  1. в 10 раз меньшей скорости аллокации
  2. невозможностью заиспользовать даже 75% выделенной кучи (процесс тупо крешится) под нагрузкой
maloi ★★★★★
()
Ответ на: комментарий от maloi

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

Ну и про скорость аллокации - есть способы влияние этой проблемы уменьшить, например, sync.Pool.

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

если сравнивать Git и Mercurial, то лично я не вижу, в чем бы последний превосходил. То, о чем ты говоришь - это больше вопрос привычных тебе команд, привычного workflow и личных предпочтений.

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

Объективно Git требует больше команда для выполнения тех же действий и/или эти команды опаснее/неудобнее, чем в том же Mercurial; Git искажает рабочий цикл, требуя программиста подстраиваться под инструмент, а не инструмент подстраиваться под программиста.

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

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

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

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

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

Зачем вам VCS вообще? По твоим высказываниям у меня складывается ощущение, что вы используете его для компактирования резервных копий и релизных версий, типа чтобы не отдельными папками хранить, а экономить место, объединяя общие куски файлов. Я, например, использую историю версий, чтобы проанализировать как менялся код, чтобы в том же русле его дальше менять (в том числе свой), откуда возникла бага, на каких версиях она проявляется. Если в текущей версии проявилась трудноуловимая бага, а на прошлых версиях ее не было - почему ее не было? Если я сделал rebase, то сделать этого я уже не смогу - я потерял историю разработки, поскольку локальный прогресс разработки был в совершенно другой ветке.

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

git checkout c файлами в качестве аргументов работает так же, как в человеческих инструментах работает команда revert. И ничего оно не пишет, ни о чем не предупреждает - просто тихо затирает твои правки.

Я даже начинаю сомневаться, что ты всерьез использовал Git, а не начитался страшилок в Интернете

И Mercurial не пользовался, и Git — я просто дворником работаю, в курилке от прогеров баек наслушался.

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

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

Почему Rust не используют для микроконтроллеров и новых RTOS типа Zephyr?

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

Почему Rust не используют для микроконтроллеров и новых RTOS типа Zephyr?

вангую ответ типа «да кому оно нужно это говно! совать наш прекрасный (системный) ЯП во всякое непотребство? не для тебя цветочек цвел!»

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

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

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

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

В Mercurial есть shelve (тот же stash), есть прекрасные инструменты слияния локальных изменений со внешними изменениями, а правки принято комитить тогда, когда они действительно готовы и знаменуют какую-то логически законченную задачу.

С таким же успехом можно ее и не хранить вовсе, что я как бы неявно упомянул в абзаце про shelve/stash.

Shelve/stash не очень хорошо работает с ревью кода. Чтоб отправить код на ревью, мне нужно его закомитить в ветку. А после ревью обычно нужно вносить новые правки, т. е. новый коммит. И итераций ревью может быть больше чем одна.

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

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

provaton ★★★★★
()

Копипаста_про_Go_и_копченую_индусскую_обезьяну.jpg

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

Объективно Git требует больше команда для выполнения тех же действий и/или эти команды опаснее/неудобнее, чем в том же Mercurial; Git искажает рабочий цикл, требуя программиста подстраиваться под инструмент, а не инструмент подстраиваться под программиста.

Объективно там примерно тот же самый набор команд, но плюс дополнительные ключи/команды, которые никто не призывает использовать.

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

Возможно, в Mercurial так действительно делать не стоит, но при чем тут Git?

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

Замечательно. У нас уже есть рабочий инструмент для хранения кода с развернутым резервированием, но мы все равно будем каждые полчаса запускать rsync, закидывая сорцы на FTP, или сделаем каждой собаке по рейду.
По-моему, это у тебя нет нормального понимания, зачем тебе нужна VCS, раз ты выдумываешь костыли на рабочем месте, решая проблему, которая уже решена. Да и зачем тебе RAID? Вдруг написанный тобой код окажется бесполезным - сразу в топку его, сэкономишь итерации.

Зачем вам VCS вообще? По твоим высказываниям у меня складывается ощущение, что вы используете его для компактирования резервных копий и релизных версий, типа чтобы не отдельными папками хранить, а экономить место, объединяя общие куски файлов. Я, например, использую историю версий, чтобы проанализировать как менялся код, чтобы в том же русле его дальше менять (в том числе свой), откуда возникла бага, на каких версиях она проявляется. Если в текущей версии проявилась трудноуловимая бага, а на прошлых версиях ее не было - почему ее не было? Если я сделал rebase, то сделать этого я уже не смогу - я потерял историю разработки, поскольку локальный прогресс разработки был в совершенно другой ветке.

Собственно, для того же, для чего и тебе.
Вот буквально месяц назад у нас была трудноуловимая бага, которую можно было поймать на последнем релизе, но нельзя было вопроизвести три релиза назад. Я посмотрел разницу между двумя релизами, на что-то обратил внимание сразу (спасибо информативным описаниям коммитов), потом еще погонял бисект, нашел еще связанную проблему, исправил. Все то же самое.
Сейчас я наконец убедил команду развернуть Дженкинс и смогу в таком случае вообще использовать daily builds, т.к. , буду знать, откуда они собраны. А все почему? Потому что история в релизных ветках и вообще ветках, которые будут использоваться для сборок (e.g. master), история никогда не переписывается, и никто в здравом уме ее переписывать не станет.
Я вживую Mercurial не использовал, поэтому не в курсе, как там точно все устроено, но у меня есть подозрение, что твои переживания вызваны его особенностями и что там от rebase в сторонней ветке действительно вся репа поедет по одному месту. Тем не менее, это нюансы Mercurial, Git тут не при чем, повторюсь.

git checkout c файлами в качестве аргументов работает так же, как в человеческих инструментах работает команда revert. И ничего оно не пишет, ни о чем не предупреждает - просто тихо затирает твои правки.

Во-первых, это кейс, отличный от того, который мы обсуждали (уточнял в самом начале). Я понимаю, что ты все-таки решился прочитать документацию, но переобуваться не комильфо.
Во-вторых, нет, не revert. Эта команда приводит файл к состоянию на указанной ревизии, и только если ревизия не указана, то используется текущий HEAD. Довольно удобная вещь, кстати.
В-третьих, она делает ровно то, что написано в документации. Если в другой системе версий такая команда работает тоже по-другому, то это в общем-то ничего не значит, если только мы не начинаем рассматривать «в Mercurial иначе, а потому Git плохой» как аргумент. Но мы не станем.

И Mercurial не пользовался, и Git — я просто дворником работаю, в курилке от прогеров баек наслушался.

Без понятия, кем ты работаешь - может, и дворником, но ощущение, будто Git использовал постольку-поскольку и гуглишь сейчас статьи «git vs hg» или «why git is so bad». Знаешь,я могу еще аргументов подкинуть: ну, например, в Git-сообществе merge requests принято называть pull requests - вот ведь сволочи, делают все, чтобы запутать честного человека.

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

Ничего не бывает бесплатно

Спасибо, капитан.

есть способы влияние этой проблемы уменьшить, например, sync.Pool.

Они не работают в 90% случаев.

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

Объективно там примерно тот же самый набор команд, но плюс дополнительные ключи/команды, которые никто не призывает использовать

Да, объективно и у жигулей, и у лексуса четыре колеса и руль. Значит, машины по сути одинаковы.

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

Возможно, в Mercurial так действительно делать не стоит, но при чем тут Git?

Как ты думаешь, откуда на рынке труда столько индусов, специализирующихся на починке и администрировании Git-реп?

У нас уже есть рабочий инструмент для хранения кода с развернутым резервированием, но мы все равно будем каждые полчаса запускать rsync, закидывая сорцы на FTP, или сделаем каждой собаке по рейду

Какие преимущества Git дает над ручным резервным копированием? В чем разница между запуском «rsync -avz» и «git add; git commit; git push»? Как по мне — rsync попроще будет, и при этом тоже не требует полного копирования содержимого, а передает только разницу, хоть и менее эффективно, чем Git. Зато большие файлы удобнее через rsync бэкапить.

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

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

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

Я предпочитаю не читать документацию, в значительной степени повторяя историю персонажей упомянутого комикса: https://xkcd.com/1597/

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

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

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

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

В чем разница между запуском «rsync -avz» и «git add; git commit; git push»? Как по мне — rsync попроще будет, и при этом тоже не требует полного копирования содержимого, а передает только разницу, хоть и менее эффективно, чем Git. Зато большие файлы удобнее через rsync бэкапить.

У меня несколько раз в жизни случалось что приложение перезаписывало файл в 0 байт, потому нужен бекап с версиями и историей.

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

Это какое-то говно мамонта, новость 2014 года. Git от версии 1 к версии 2 не так уж сильно изменился. Сейчас уже 6 лет версия 2.x, и тоже никаких значительных изменений (я не говорю об улучшениях, их полно) не было в командах и т.д.

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

Это какое-то говно мамонта, новость 2014 года. Git от версии 1 к версии 2 не так уж сильно изменился. Сейчас уже 6 лет версия 2.x, и тоже никаких значительных изменений (я не говорю об улучшениях, их полно) не было в командах и т.д

Вот именно. Статья именно о том, что Git недостаточно изменился и содержит ссылки на то, чего в нем не хватает. Я понимаю, что на ЛОР-е есть традиция не ходить по ссылкам — я могу сам сделать это за вас, но статьи читать я за вас не смогу:

https://felipec.wordpress.com/2014/06/05/whats-missing-in-git-v2-0-0/
https://www.survs.com/results/QPESOB10/ME8UTHXM4M — Git User’s Survey
- user-interface: 3.25
- documentation: 3.22
- tools (e.g. GUI): 3.01
- more features: 2.41
- portability: 2.34
- performance: 2.28
- community (mailing list): 1.70
- localization (translation): 1.65
- community (IRC): 1.65

The fact of the matter is that in every release of Git, there is only one focus: performance. Despite the fact that it’s #6 in the list of concerns of users, Git developers work on this because that’s their area of expertise, because it’s fun for them, and because they get paid to do so. There are occasional new features, and a bit of portability now and then, but for the most part Windows support is neglected in Git, which is why the msysgit project was born.

The documentation will always remain cryptic, because for the developers, it’s not cryptic, it’s very clear. And the user-interface will never change, because the developers don’t like change.

If you don’t believe me look at the backwards-incompatible changes in Git v2.0.0, or in fact, try to think back to the last time Git changed anything. Personally other than the git-foo -> ‘git foo’ change in v1.6.0 (which was horribly handled), I can’t think of anything but minor changes.

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

Это какое-то притянутое за уши дерьмо. Удали пост и сам забанься.

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

Да, объективно и у жигулей, и у лексуса четыре колеса и руль. Значит, машины по сути одинаковы.

В такой аналогии у Mercurial нет ни колес, ни руля, ни прикуривателя - они ставятся отдельными расширениями.

Как ты думаешь, откуда на рынке труда столько индусов, специализирующихся на починке и администрировании Git-реп?

Без понятия, ни разу не пользовался их услугами. Что, таких чуваков много? Ну, наверное, коррелирует с популярностью Git - в конце концов, любую VCS надо разворачивать и мало-мальски в последствии администрировать. Я надеюсь, что и у вас кто-то следит за работоспособностью серверов с Mercurial, а то мало ли что.

Какие преимущества Git дает над ручным резервным копированием?

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

«git add; git commit; git push»?

В общем случае «git commit -a; git push». Можешь макрос сделать, будет совсем быстро и коротко.

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

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

Я предпочитаю не читать документацию, в значительной степени повторяя историю персонажей упомянутого комикса: https://xkcd.com/1597/

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

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

То VCS у тебя можно освоить за день, то это внезапно превратилось в неординарную задачу. Определись, что ли.
Хотя мне нравится, как ты подчеркиваешь это свое «действительно» - будто бы все всем уже объяснил и доказал.

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

Я тебе больше скажу, при повседневной работе с VCS большинство набирает в консоли только набор простых и часто используемых команд, и это множество функций в Git отличается от множества функций в Mercurial или SVN только парой-тройкой дополнительных опций. Остальное в документации Git - это advanced usage.
Я не вижу в этом никакой проблемы, т.к. любое ПО или средство для его написания обычно предоставляют больше функционала, чем тебе нужно для решения конкретной задачи, и куда хуже, когда какой-то возможности внезапно недостает, чем когда этих возможностей в избытке.

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

Просто нужно понимать, что checkout в Git - это не «сохранить» и не «уничтожить», а «привести к определенному состоянию». Меняется не назначение, а объект, с которым работает команда. Если понимаешь, то все встает на свои места.

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

В такой аналогии у Mercurial нет ни колес, ни руля, ни прикуривателя - они ставятся отдельными расширениями.

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

Плюс мой «бэкап» доступен сразу и всем посредством VCS

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

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

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

В общем случае «git commit -a; git push». Можешь макрос сделать, будет совсем быстро и коротко

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

В-третьх, документы и БД априори должны лежать на сервере, а не на локальном ПК. Собственно, ты сам сейчас говоришь про Perforce, и я не понимаю, при чем тут тогда RAID, rsync и прочая канитель на твоем компьютере

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

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

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

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

То VCS у тебя можно освоить за день, то это внезапно превратилось в неординарную задачу. Определись, что ли

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

Я тебе больше скажу, при повседневной работе с VCS большинство набирает в консоли только набор простых и часто используемых команд, и это множество функций в Git отличается от множества функций в Mercurial или SVN только парой-тройкой дополнительных опций. Остальное в документации Git - это advanced usage

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

Просто нужно понимать, что checkout в Git - это не «сохранить» и не «уничтожить», а «привести к определенному состоянию». Меняется не назначение, а объект, с которым работает команда. Если понимаешь, то все встает на свои места

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

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

Кстати, набрел на мнение одного человека в интернете, которое подозрительно похоже на мое впечатление:

https://www.reddit.com/r/programming/comments/2fn4r9/how_to_work_with_git_flo...

After 12 months I could administer an SVN repository with ease. At 2 years I could modify and rebuild a broken repository with panache. With CVS it took a little over a year before I could use VI to fix a broken repo. Let me repeat that: Hand editing the storage files to fix a busted repository. Successfully.

I've been using Git for almost 3 years now. At 2 years I was still afraid of my own shadow. I can help people debug a screwed up local branch, but I still can't fix much once it's pushed.

Most of us need something simpler. Even if that means fewer «features». Or perhaps that's precisely it: we need something less functional and therefore less confusing.

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

Чем тебя Git не устраивает? Лично твои проблемы так и останутся лично твоими. Пойми уже, что это средство обмена кодом (с другими людьми, если что), и какие-то дрочённые команды, которые нужны только тебе, не заставят всю команду, даже если она условна, переходить. Барьер у Git наименьший. Вот и всё.

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

Барьер чего?

Извини, имею ввиду т.н. порог вхождения.

Для простых смертных, которым как правило нужен только clone. Для смертных посложнее, которым нужен ещё и checkout, commit и push и может быть настроить (скопипастить) .gitconfig. И для «сложных» смертных, которым нужны ещё и merge, rebase и чери-пик.

Остальное – это уже для очень ограниченного числа людей. И при любом раскладе это имеет вид пирамиды – т.к. чем «сложнее» люди – тем их меньше. И значит считаться им нужно с бо́льшим кол-вом людей. Можно что-то изменить – но только так, чтобы «внизу» ничего не ухудшилось. Иначе просто не прокатит. Таков расклад. Для git есть очень много how to в том числе и на родных языках. И в целом он очень прост – именно для вот этих нескольки команд – commit, push (фаст-форвард).

Иначе это будет инструмент только для очень небольшого количества людей (т.е. его не будет существовать, что мы и наблюдаем).

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

Для простых смертных, которым как правило нужен только clone. Для смертных посложнее, которым нужен ещё и checkout, commit и push и может быть настроить (скопипастить) .gitconfig. И для «сложных» смертных, которым нужны ещё и merge, rebase и чери-пик

«Сложные» смертные — это все люди, которые изменяют содержимое Git-репозитория, а не просто делают «git clone» или «git reset --hard; git pull». Он внёс правки, внёс кто-то еще — вот и привет, их уже нужно как-то сливать. И в итоге получается, что минимальный набор команд уже оказывается весьма и весьма солидным — даже неприятно солидным для тех функций, которые с его помощью нужно выполнятиь.

Иначе это будет инструмент только для очень небольшого количества людей (т.е. его не будет существовать, что мы и наблюдаем)

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

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

«Сложные» смертные — это все люди, которые изменяют содержимое Git-репозитория

Ага, «git push – это сложно». А я и не заметил.

Он внёс правки, внёс кто-то еще — вот и привет, их уже нужно как-то сливать.

Обычно всё сливается автоматом. В иных случаях для этого есть GUI. И уж точно не нужен веб-сервер и bisect. Это проблема организации людей. Если устраивать котовасию, то разумеется её придётся разгребать. Только система контроля версий тут причём?

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

Это справедливо только если ты из прошлого века.

kostyarin_ ★★
()
Ответ на: комментарий от kostyarin_
 $ git push ../test
To ../test
 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to '../test'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Дальше что? Сделать «pull»? Окей:

$ git pull  ../test
remote: Enumerating objects: 8, done.
remote: Counting objects: 100% (8/8), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 6 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (6/6), done.
From ../test
 * branch            HEAD       -> FETCH_HEAD
Auto-merging Makefile
CONFLICT (content): Merge conflict in Makefile
Automatic merge failed; fix conflicts and then commit the result.

Дальше какие указания? Какие следующие простейшие команды я должен выполнять? Checkout, commit, или push?

Я подчеркиваю, что это обычно самая-присамая первая и частая проблема, с которой сталкивается любой человек, вносящий правки в Git. Да, я-то спустя полгода работы с Git научился, что нужно делать «git mergetool», а потом «git commit; git push».

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

Сразу второй тур запощу:

$ git push ../test
To ../test
 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to '../test'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushin
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Начало не предвещает беды.

$ git pull ../test
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From ../test
 * branch            HEAD       -> FETCH_HEAD
error: Your local changes to the following files would be overwritten by merge:
        Makefile
Please commit your changes or stash them before you merge.
Aborting

Что тут у нас? Но я не хочу вносить эти локальные правки из Makefile в общую репу. Мне можно, конечно, вручную сделать резервную копию моих файлов — однако, в таком случае я предпочту выкинуть Git и распространять исходники в тарболах, потому что трудоемкость примерно сравнимая. Но я все-таки предпочел использовать git — хорошо, будем через stash всё делать. Окей, гуглим руководства по использованию stash, которое снова не входит в золотой набор «checkout, commit, push».

$ git stash
Saved working directory and index state WIP on master: 4dbc60c Merge ../test

$ git pull ../test
From ../test
 * branch            HEAD       -> FETCH_HEAD
Merge made by the 'recursive' strategy.
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git stash pop
Auto-merging Makefile
CONFLICT (content): Merge conflict in Makefile
The stash entry is kept in case you need it again.

$ git mergetool
Merging:
Makefile

Normal merge conflict for 'Makefile':
  {local}: modified file
  {remote}: modified file
...

Здесь я смухлевал, потому что я использовал еще и «git status», иначе я бы запушил в репу черт пойми что:

$ git status
On branch master
Your branch is ahead of 'origin/master' by 9 commits.
  (use "git push" to publish your local commits)

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   Makefile

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        Makefile.orig

$ git reset Makefile
Unstaged changes after reset:
M       Makefile

Ой, я же забыл запушить:

$ git stash
Saved working directory and index state WIP on master: d2b176a Merge ../test

$ git push ../test
Enumerating objects: 17, done.
Counting objects: 100% (17/17), done.
Delta compression using up to 2 threads
Compressing objects: 100% (5/5), done.
Writing objects: 100% (9/9), 987 bytes | 493.00 KiB/s, done.
Total 9 (delta 1), reused 0 (delta 0)
remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: is denied, because it will make the index and work tree inconsistent
remote: with what you pushed, and will require 'git reset --hard' to match
remote: the work tree to HEAD.
remote:
remote: You can set the 'receive.denyCurrentBranch' configuration variable
remote: to 'ignore' or 'warn' in the remote repository to allow pushing into
remote: its current branch; however, this is not recommended unless you
remote: arranged to update its work tree to match what you pushed in some
remote: other way.
remote:
remote: To squelch this message and still keep the default behaviour, set
remote: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To ../test
 ! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to '../test'

Опача. Вот и приехали. А оба репозитория чисты, тем временем.

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

Дальше что? Сделать «pull»? Дальше какие указания?

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

git push ../test master:my-feature-x

Инструмент не виноват в том, что ты ждёшь от него неадекватного поведения. А что он там должен желать – перезаписывать незакомиченные файлы? Это может быть мой рабочий комп подлючённый к сети, куда все пушат. Или я правлю файл на сервере, например. Или это вообще --bare и такого там просто быть не может.

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

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

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

Инструмент не виноват в том, что ты ждёшь от него неадекватного поведения. А что он там должен желать – перезаписывать незакомиченные файлы? Это может быть мой рабочий комп подлючённый к сети, куда все пушат. Или я правлю файл на сервере, например. Или это вообще --bare и такого там просто быть не может

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

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

git stash push
git pull
git stash pop
<resolve conflicts if any>
git add ./
git commit
git push

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

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

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

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

«создаем отдельную ветку на каждый чих»

Ветка – это всего лишь файл сожержаший SHA1-хэш. Ничего сокрального в ветке нету. Создавай и сливай сколько хочешь. И всегда можно переключиться. Алиа́сь, если лень или скриптуй. Не проблема.

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

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

Ну так это ты хочешь всё усложнить. Вообще-то никто так не делает. В некоторых случаях проще вытолнкуть в stash. Вот тебе и пример. Всё логично.

P.S.: Как раз, если бы это делалось одной командой – это было бы сложно. Т.к. все шаги нужно было бы держать в голове. И в случай поломки думать на каком этапе всё отвалилось.

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

Ветка – это всего лишь файл сожержаший SHA1-хэш. Ничего сокрального в ветке нету. Создавай и сливай сколько хочешь. И всегда можно переключиться. Алиа́сь, если лень или скриптуй. Не проблема

Мне кажется, что ты забыл свои собственные слова:

И для «сложных» смертных, которым нужны ещё и merge, rebase и чери-пик.
Остальное – это уже для очень ограниченного числа людей. И при любом раскладе это имеет вид пирамиды – т.к. чем «сложнее» люди – тем их меньше

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

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

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

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

Mercurial? SVN? Perforce? Упомянутый выше Bitkeeper? Или какие альтернативы имелись в виду?

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

Они не работают в 90% случаев.

Очень смелое заявление. А у меня противоположные данные.

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

Не простой тул, но git это не только сам git, а еще и github, и gitlab, исходники всяких нужных проектов.

Всего N лет назад разные проекты использовании разные VCS, у одно это bazzar, другого svn, у третьего mercular, разве от этого было проще? Надо было знать CLI всех этих тулов, хотяб чтоб скачать исходники, найти изменения в истории, понять концепцию используемого бранчинга в конкретном VCS чтоб знать где искать.

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

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

Вообще всё делается через ветки.

git co -b my-feature-x
touch one.txt
git add ./
git cm "add one.txt"
git co master
git merge my-feature-x
git push
# [on conflict]
git pull
<resolve>
git push

И ветка у тебя только локально. И в приницпе co -b можно сделать всегда. Ну и так далее. И есть ещё git pull --rebase ну и так далее.

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

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

Ну так это ты хочешь всё усложнить. Вообще-то никто так не делает

Конечно не делает — на stackoverflow и в туториалах советуют придерживаться схемы с чистой репой и единственным сценарием коммитов; шаг в сторону — расстрел. Ну, то есть не расстрел, а «любись как хочешь — твои проблемы». Большинство даже не рискуют в итоге сходить с проторенной дорожки. В итоге, спустя время они привыкают и даже не задумываются над тем, что им на самом деле неудобно.

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

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

Вот мои:

br = branch
co = checkout
st = status -sb
l = log --graph --pretty=format:'%Cred%h%Creset %C(bold blue)<%an>%Creset%C(yellow)%d%Creset %s %Cgreen(%cr)' --abbrev-commit --date=relative 

P.S. Где как не в теме про Go это спросить? :)

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

Всего N лет назад разные проекты использовании разные VCS, у одно это bazzar, другого svn, у третьего mercular, разве от этого было проще? Надо было знать CLI всех этих тулов, хотяб чтоб скачать исходники, найти изменения в истории, понять концепцию используемого бранчинга в конкретном VCS чтоб знать где искать

К абсолютно любому из упомянутых инструментов привыкаешь очень быстро. У меня вообще никогда не возникало реакции «блин, тут свн используется. Как же я теперь с ним буду работать?». И только Git удалось создать реакцию «ЧТО ЭТО? ЧТО МНЕ ВООБЩЕ С ЭТИМ ДЕЛАТЬ?». Еще раз повторюсь: эта реакция коррелирует с опросом 4000 пользователей Git в 2014, которые тоже в большинстве считали, что интерфейс и доки у Git плохие.

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