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

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

«Если вы спроектируете систему из расчёта на идиотов, то только идиоты и будут ей пользоваться»

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

NOTABUG OUTOFSCOPE

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

Варианты, что ртуть просто меньше умеет, или что в Git более подробная справка, не рассматриваются?

С какой радости? man youtube-dl

Общедоступные видосы как угодно можно грузить. DRM-контент — только с зондом.

Для следующих поколений уже только визуальные языки с поддержкой мультитача.

• включить режим «безопасный код»? (да)
• включить режим «сниппеты по требованию»? (да)
• включить режим «интеллектуальное распознавание контекста использования ПО»? (да)
• включить режим «интерактивный помощник»? (да)
• включить режим «максимальный комфорт»? (да)

спасибо за ответы.

ожидаемое время сборки заказанного продукта составит 2 года 4 месяца 13 дней 14 часов 17 минут

ожидаемая минимально работоспособная конфигурация компьютера 1024 ядра, 2 птб RAM, 1000 птб UF SSD 23 поколения, дискретная карта 156 поколения с поддержкой RealityNow(тм) тактильных ощущений, Windows 256 Pro extended edition

спасибо за обращение, оставайтесь с нами.

А, там в оригинале было про фильмы? С чего ты тогда вообще взял YouTube.

Пол года назад искал работу, почти на всех собеседованиях: «микрсервисы, кафка, блокчейн, … »

Лол. Ты искал работу на помойке. Особенно блокчейн улыбнул.

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

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

Ну я немного про другое. Например, когда я хочу глянуть историю коммитов для конкретной директории bla-bla-bla, то делаю git log bla-bla-bla. Все хорошо. Однако если ее переименую в bla-bla, то git log покажет только один коммит «Rename bla-bla-bla to bla-bla». Для отдельного файла в папке я еще могу увидеть всю историю, но для папки целиком - no way, надо переносить особым образом, переписывая, да, дерево коммитов. Проблема в том, что гит отслеживает только изменения файлов, а на директории ему насрать - отсюда этот бессмысленный пердолинг.

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

Маловероятно, у каждого разработчика есть локальная копия репозитория + обязательно должны быть регулярные бэкапы + система вроде gitea или gitlab с разделением прав доступа для репозиториев и веток, где можно как запретить force push, требуемый для перезаписи истории, так и вообще ограничить список тех, кто может делать коммиты напрямую в ветку, минуя merge requests.

Перезапись истории - это фишка а-ля unsafe в Rust. Как бы можно, но как бы не надо. Лично меня в свое время она сильно выручила, когда я колдовал, реорганизовывая submodules в проекте.

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

Слушай, там 90% ключей нужны чуть менее, чем никогда, а некоторые можно в настройках репозитория выставить по дефолту. Например, чтобы pull всегда был с --rebase.

Варианты, что ртуть просто меньше умеет, или что в Git более подробная справка, не рассматриваются?

Нет, это исчерпывающий список опций «hg update». Остальные опции Git - это опасные ручные команды и просто плохо продуманные особенности работы. Например, режима «detached head» в Mercurial нет, однако, он не потерял от этого функционала по сравнению с Git:
https://www.mercurial-scm.org/wiki/GitConcepts#Branch_model

Последний вариант вызова, «git checkout (-p|--patch)», пришел на замену двум длинным предыдущим командам, и эквивалентен «hg update (-m|--merge)» — этот механизм намного проще и удобнее для человека, который не писал и не читал исходные коды Git.

А, там в оригинале было про фильмы? С чего ты тогда вообще взял YouTube

Пардон, я плохо вкинул инфу, да и контекст не заметил. Действительно, там было про фильмы, потому ютьюб пролетает мимо кассы.

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

Однако если ее переименую в bla-bla, то git log покажет только один коммит «Rename bla-bla-bla to bla-bla». Для отдельного файла в папке я еще могу увидеть всю историю, но для папки целиком - no way, надо переносить особым образом, переписывая, да, дерево коммитов. Проблема в том, что гит отслеживает только изменения файлов, а на директории ему насрать - отсюда этот бессмысленный пердолинг

В Mercurial проблема решается через «hg log --follow», например.

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

Ну ясен пень, что SCM распределенная, а значит у всех полная копия — однако, свои правки ты потеряешь.

Перезапись истории - это фишка а-ля unsafe в Rust. Как бы можно, но как бы не надо. Лично меня в свое время она сильно выручила, когда я колдовал, реорганизовывая submodules в проекте.

Ты фактически создаешь новый репозиторий с потерей истории. Если же происходит простое перемещение/переименование - я уже упомянул «hg log --follow».

Слушай, там 90% ключей нужны чуть менее, чем никогда, а некоторые можно в настройках репозитория выставить по дефолту. Например, чтобы pull всегда был с --rebase

А у вас за rebase руки еще не отрывают?

В Mercurial проблема решается через «hg log --follow», например.

Тут так же, но не для директорий. Это архитектурный просчет гита.

Ну ясен пень, что SCM распределенная, а значит у всех полная копия — однако, свои правки ты потеряешь.

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

Ты фактически создаешь новый репозиторий с потерей истории. Если же происходит простое перемещение/переименование - я уже упомянул «hg log --follow».

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

А у вас за rebase руки еще не отрывают?

А почему должны? Как по мне, только так и нужно. Все слияния в транк только сквошем и фастфорвардом, потом там аккуратная история, на которую приятно смотреть.

Варианты, что ртуть просто меньше умеет, или что в Git более подробная справка, не рассматриваются?

Нет, это исчерпывающий список опций «hg update»

Понятно, первый вариант.

Остальные опции Git - это опасные ручные команды и просто плохо продуманные особенности работы.

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

Ну, про опасность и идиотов я уже написал, а в чём заключается плохо продуманность?

Например, режима «detached head» в Mercurial нет

…зато есть механизм безымянных веток, только у них тоже могут быть имена, но это другие имена :D

И эти люди запрещают нам ковыряться в носу.

Последний вариант вызова, «git checkout (-p|–patch)», пришел на замену двум длинным предыдущим командам

С чего ты взял, что git checkout --patch пришёл на замену git checkout --ours|--theirs? Это две совершенно разных операции.

Например, режима «detached head» в Mercurial нет

…зато есть механизм безымянных веток, только у них тоже могут быть имена, но это другие имена

Я как раз и писал о том, что фичи по сути у ртути те же, но интерфейс к ним заметно удобнее.

С чего ты взял, что git checkout --patch пришёл на замену git checkout --ours|--theirs? Это две совершенно разных операции

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

фичи по сути у ртути те же

Нет, например, detached HEAD в Git нигде не запоминается. Ты можешь попрыгать по ревизиям миллион раз и это никак не повлияет на последующую производительность репозитория. Прямого эквивалента этой фиче у ртути нет — ты показал какие-то странные псевдо-непсевдо-ветки (смысл которых от меня ускользает, ну да ладно).

интерфейс к ним заметно удобнее.

Потому что ты так сказал?

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

Нет. Это разные операции, объединённые одним общим свойством — они вытаскивают какие-то данные из текущего состояния (индекса) в какие-то файлы в рабочем дереве.

От себя добавлю, что detached HEAD используется для git submodules.

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

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

Все слияния в транк только сквошем и фастфорвардом, потом там аккуратная история, на которую приятно смотреть

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

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

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

Нет, например, detached HEAD в Git нигде не запоминается. Ты можешь попрыгать по ревизиям миллион раз и это никак не повлияет на последующую производительность репозитория

То же самое в Mercurial происходит — прыгай сколько хочешь, комиты не меняются. Под капотом там тот же самый функционал, как я уже написал.

Это разные операции, объединённые одним общим свойством — они вытаскивают какие-то данные из текущего состояния (индекса) в какие-то файлы в рабочем дереве

Да, вытаскивают. Как ты собрался вытаскивать версии этих файлов, если у тебя есть локальные незакомиченные правки? Дай отгадаю - ты их закоммитишь, а потом сделаешь checkout. Так сделает любой человек с Post-Git Syndrome. Для всех остальных сделано git checkout -p, которое сольет правки и по необходимости запустит разрешение конфликтов.

Для всех остальных сделано git checkout -p, которое сольет правки и по необходимости запустит разрешение конфликтов.

Мне кажется, ты просто не знаешь, что делает git checkout -p %)

Мне кажется, ты просто не знаешь, что делает git checkout -p %)

Хорошо, где я ошибся в моем описании?

Собака лает, караван идет.

git checkout -p интерактивно (выборочно) применяет изменения из индекса к выбранным файлам. git checkout в этой форме вообще не меняет HEAD.

ничего

git checkout -p интерактивно (выборочно) применяет изменения из индекса к выбранным файлам. git checkout в этой форме вообще не меняет HEAD

«git checkout (-p|--patch) [<tree-ish>] [--] [<pathspec>…​] »
"...The chosen hunks are then applied in reverse to the working tree (and if a <tree-ish> was specified, the index)."

Конечно, если я правильно понял твоё «не меняет HEAD».

ты мне скажи: у всех лисперов так чсв завышено?

Нет, но у многих. Терминология у каждого своя причём, поэтому могут в лиспосрачах целыми днями пропадать. А слово рефлексия для них – это возможность поковырять метаданные лямбд.

Маргинальщина, чо.

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

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

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

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

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

Конечно, если я правильно понял твоё «не меняет HEAD».

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

Ты, кажется, не понимаешь что значит слово «синтаксис».

wc забыл дружочек.

Ненене, так

•       н
        a
        г
        л
        я
        д
        н
        е
        е
  

Терминология у каждого своя причём

метаданные лямбд

Спалился.

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

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

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

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

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

Тут вообще не нужно слияние веток - это простое применение патча.

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

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

Я дополню.

Потому что он нарушает историю правок. С таким же успехом можно ее и не хранить вовсе

Историю правок нарушать можно и нужно (разумеется, только пока она ещё не опубликована). Почему, вы спросите? По одной простой причине: настоящая история правок, в которой написано, как ты два дня ковырялся в носу и 10 раз переписывал одну и ту же строчку и потом ещё три дня отлаживал тесты методом морского боя и научного тыка (поправил-запушил-получил от CI по щам-снова поправил), абсолютно никого не интересует. Ни-ко-го.

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

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

Конечно, если я правильно понял твоё «не меняет HEAD».

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

«git checkout» без указания коммита или ветки не изменяет указатель HEAD. Это относится ко всем трем версиям команды:

git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <pathspec>…​
git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] --pathspec-from-file=<file> [--pathspec-file-nul]
git checkout (-p|--patch) [<tree-ish>] [--] [<pathspec>…​]

Потому я не вижу, где я ошибся.

Вот здесь:

Для всех остальных сделано git checkout -p, которое сольет правки и по необходимости запустит разрешение конфликтов.

git checkout -p не сливает никакие правки и не запускает разрешение конфликтов. Равно как и два предыдущих по списку варианта — они вообще для другого, они для ручного разрешения конфликтов при мерже на уровне отдельных файлов.

Историю правок нарушать можно и нужно (разумеется, только пока она ещё не опубликована). Почему, вы спросите? По одной простой причине: настоящая история правок... абсолютно никого не интересует

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

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

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

И ты берёшь и делаешь интерактивный ребейз

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

Все аргументы против Go в этой статье сводятся к тому, что он плохо поддерживает windows. Но в windows и так не особо нужны программы без графического интерфейса. Поэтому Go просто используется на unix и все работает.

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

Ну это типичная методика, да, я для твоего понимания описываю, а не потому, что изобрел ноу-хау.
Если тебе интересно, почему именно git - опыт его использования (в отличие от hg) у членов команды, опыт его использования у кандидатов. Ни один чувак, который приходил на интервью, не сказал, что использовал Mercurial - обычно git, иногда svn.

Mercurial и Perforce тоже позволяют создать локальные ветки, а потом отдельно их пушить. А также, все три инструмента позволяют забивать болт, вообще не трогая SCM и не создавая веток, пока сам работаешь со своими правками.

Ну и отлично. Видишь, гит не хуже.

Тут вообще не нужно слияние веток - это простое применение патча.

Но патчей у меня на ветке много (маленьких), а я хочу, чтобы он в итоге был один (большой). Не знаю, как там в Mercurial, а в Git можно по-разному мержить. Можно так, чтобы в дереве были видны маленькие коммиты, можно так, чтобы не были - кому как по душе.

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

Как уже верно заметили, история на локальной ветке («fix indent», «fix typo», «zarabotay uje gadina»), о которой ты так печешься, не интересна никому, кроме меня.
Rebase же в конечном счете позволяет получить в транке линейную историю цельных коммитов с красивым, внятным описанием.

git checkout -p не сливает никакие правки и не запускает разрешение конфликтов. Равно как и два предыдущих по списку варианта — они вообще для другого, они для ручного разрешения конфликтов при мерже на уровне отдельных файлов

Всё, я понял. То есть, толковых аналогов фич слияния с незакоммиченными правками, как в Mercurial, Perforce, и даже Svn, в Git просто нету, и пользователи этого замечательного инструмента вынуждены ходить раком, во веки-веков, аминь. Закапывайте.

То есть, либо куцый встроенный консольный инструмент, который неудобен и не совсем слияние делает, либо по старинке — коммитим что попало, а потом уже сливаем по-человечески через «mergetool».

Теперь я хочу услышать истории о том, что Git - лучшее решение в нынешнее время.

Ты лучше скажи, что ты хочешь сделать и зачем тебе понадобился checkout -p.

К написанному lovesan добавлю, что еще, например, в Active Oberon был атрибут процедуры REALTIME, запрещающий сборку мусора во время исполнения этой процедуры.

Про GC в Go подробно: https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e

Но нет, там тупой Stop The World

Since go1.5 the GC has been largely concurrent but with short stw pauses at certain points in the algorithm. in 1.6,1.7 and coming up in 1.8 there have been successive improvements to improve the worst case stw times. Upper bound in 1.8 is ~100 microseconds.

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

А если приложуха на Го занимает 48 гиг оперативки? Как тогда поведет себя гошный сборщик мусора?

Не такой уж и тупой,

Но тупее чем в Яве(в которой несколько алгоритмов GC реализованно) и в Mono.

на больших проектах на Python и Go с читабельностью всё плохо

В точку. Я как-то решил посмотреть один проект всем известной конторы на Python. Так там без такой-то матери ни черта не понятно.

Варианты, что ртуть просто меньше умеет, или что в Git более подробная справка, не рассматриваются?

Git напоминает велосипед, к которому сбоку приделали ракетные двигатели, вал и винты АПЛ, вместо седла установили томограф, а руль заменили игрушкой из секс-шопа.

sss, залогинься

Я — лиспер… Однако, я за свою жизнь не написал и пяти строк на лиспе.

Ох ё. Я-мы-шарли-эбдо.

По такой логике меня можно считать матерым растоманом.

Обычно смотрю на kinogo.by или seasonvar.ru