Вот и с частыми коммитами в гите так же: это просто бэкап на случай ошибок рефакторинга. Но гит сам по себе их не требует.
Если я делаю какие-то крупномасштабные изменения, то, естественно, я сохраню старую версию, с Git или без Git, разговор ведь не об этом совсем, такие события происходят нечасто, чтобы под них прогибать всю модель разработки.
И да, я всё ещё не вижу связи между практикой частых сохранений и неприменением git chechout для подготовки коммита.
Не частых сохранений, а частых коммитов. checkout/update нужен для переноса правок на другую ревизию, эдакий аналог rebase, но для незакоммиченных правок. Другой более близкий аналог в самом Git -- это stash.
>То, для чего в SVN есть "svn update", а в Mercurial есть "hg update".
Вы по одному файлу обновляете в SVN и Mercurial, или всё-таки сразу всё дерево? Если первый вариант — то зачем? Если второй — то чем это от checkout отличается?
Я только после 30 лет, занимаясь музыкой, начал различать иностранную речь на слух
Эти два тезиса очевидно входят в противоречие. Навык устной речи никуда не атрофируется, а просто засыпает как ненужный. Письменный язык и устный язык -- это просто сильно разные штуки. Потому что письменный язык в массовых культурах составлен академическими мудаками, имевшими целью искуственное усложенния языка, фонетическая же запись ближе к устной речи и таких проблем не создает.
git checkout нужен на грязном рабочем каталоге для слияния локальных правок с последними правками в публичной репе. Примерно то, для чего делается "git pull --rebase --autostash", только для перехода к конкретной ревизии. То, для чего в SVN есть "svn update", а в Mercurial есть "hg update". Паталогичная же культура git заключается в том, что от разработчиков требуют держать все локальные правки в виде коммитов, из-за чего отпадает необходимость в "git checkout" на грязном рабочем каталоге, потому что рабочий каталог всегда чистый.
Но у чистого рабочего каталога есть своя цена -- теперь вместо того, чтобы применять локальные правки к какой угодно ревизии, я должен постоянно переписывать историю локальных веток, то есть, merge-rebase-squash-cherry pick, я должен упиваться кишками git вместо того, чтобы просто заниматься разработкой.
Ну да, если указать конкретный файл, он будет перезаписан. А что ещё должна делать команда checkout?
Вот именно, одна и та же команда используется в роли "уничтожить локальные правки" и в роли "сохранить локальные правки после синхронизации". Но по факту это настолько опасно и заморочено, что я (и не только я) использую стэш и автостэш вместо какого-нибудь `git checkout --merge` или `git rebase`. Всё, что я до сих пор пытался сказать -- это что git взял за фундамент патологичный рабочий процесс, и только с годами и тысячами простреленных ног к гиту наконец прикостылили и даже внедрили в ядро рабочий процесс здорового человека, например, `git pull --rebase --autostash`.
Ни разу не применял checkout для подготовки правок к коммиту. Мы какие-то разные гиты обсуждаем?
Вот это самое "ни разу не применял" -- это одно из проявлений паталогии, а именно -- избегание грязного рабочего каталога и коммиты каждые 5 минут. Что есть бессмысленно, потому что никого не волнуют эти незаконченные правки, они все равно будут сквошнуты и ребейзнуты -- именно последнее и есть настоящий рабочий процесс, а не плетение макаронного монстра в истории публичного репозитория.
Но это же вы придумали специально для гита задачу, которая в других СКВ не возникает, и жалуетесь что есть аж целых два способа её решить.
А Git научился в patch queue? Я понимаю, что сообщество уже напилило вокруг Git костылей под это дело, но можно было сделать сразу хорошо.
А почему создание ветки вы приравниваете к выстрелу в ногу?
Не создание ветки, а стирание изменение в рабочем каталоге, которое умеет делать checkout. Тот же checkout, который применяется для подготовки правок к коммиту в этом же рабочем каталоге.
Вы не ответили на второй вопрос. Как эта задача решается в других VCS?
Интересует именно что аналог git checkout origin/master -B master
Это провокационный вопрос плана "какая же у вас шморгалка" -- эта команда уже жёстко протекает внутренностями git, которых, ожидаемо, просто нет в других VCS. В том же Mercurial нет такой замороченной системы веток с трекингом, потому аналогичной команды просто не существует, а существует акцент на плоской истории через грязную рабочую копию, расширение strip, или расширение очередей патчей.
В Mercurial есть даже слизанное с гита расширение rebase, но по факту малопопулярное потому, что rebase решает правильную задачу неправильным образом -- мне, как правило, никогда не нужно условно необратимо переместить ветку с одного места в другое, да еще и потенциально переписывая историю коммитов на публичной репе. Вместо этого есть чёткое деление на рабочие правки и рабочие патчи, не принадлежащие истории, и саму история, которую публична и не подлежит изменению, которую я строго дописываю в конец на основе рабочих правок, и потому не выбью стул из-под ног человека, работающего с опубликованной веткой. Git по итогу пришел к тому же, но окольными путями и бессмысленными усложнениями операций с ветками.
git checkout применяется исключительно для обновления рабочей копии, все остальные применения — это побочные эффекты для удобства.
Удобства? Это как ковбои носили револьверы снятыми с предохранителя "для удобства", и стреляли себе в ногу? "Ну а что, вдруг кому-то понадобится срочно выстрелить себе в ногу?" -- так, что ли? Кажется, о чем-то таком думал Торвальдс, создавая изначальным прототип Git.
Но команды-то тривиальные и я бы не сказал что они какие-то заметно разные.
git checkout -- это как раз одна из самых безумных команд git, потому что одновременно применяется для подготовки незакоммиченных изменений в рабочем каталоге, для стирания изменений в рабочем каталоге, и для операций над ветками. Чтобы понять, как работает checkout, мне нужно понимать: что есть некий "индекс", который не коммит и не рабочий каталог, что есть "ветки", которые на самом деле не ветки, а головы ветки ( "достаточно знать что "ветка" в гите является просто именованным ярлыком для номера коммита ", да), потому что ветки не могут прыгать по всему репозиторию и не могут схлопываться в один коммит; понимать, что такое "оторванная башка" и почему она оторванная. Ты уже по крупицам из меня выгягиваешь статью. Прямыми провальными решениями при создании git был именно выбор такого понятия "ветки" и применение индекса вместо реализации удобного интерфейса формирования коммита без внесения третьей сущности в контроль версий. Косвенными провальными решениями была ориентация на интенсивное ветвление, что в том числе усложнило опции команд работы с ветками, при том, что по итогу от этих веток все равно отказываются либо в пользу патчсетов и ревью, либо в пользу прямого формирования плоской истории изменений через какой-нибудь `git pull --rebase --autostash` -- не так давно git получил эту фичу, которая в других VCS была из коробки изначально.
Например, тот факт, что две заметно разные и при этом совсем не тривиальные команды дают один и тот же результат. Это если коротко. Если длинно, то я могу накатать целую статью. Как правило, короткого ответа хватает всем, кто хотя бы пару месяцев поработал с альтернативными VCS и знает, что ими можно пользоваться почти не читая документацию. Потому что VCS служит мне, а не я служу VCS. Интерфейс командной строки Git написан так, что нужно либо детально знать внутреннюю архитектуру кода и структур данных, либо заучить запредельное число готовых команд (сильно больше, чем упомянуто в этой статье), чтобы достаточно комфортно с Git работать. Благо, VS Code лично меня спасает от большей части базовых команд, но в сложных случаях все равно приходится лезть в консольку.
Ждем статьи "300 команд, которые сделают вас мастером bash". Восьмидесятые прошли, но но для некоторых они остались в душе навсегда. Тулза. которая должна была быть незаметной, как калькулятор, стала идолом, к которому разработчики вынуждены обращать мольбы по нескольку раз в день. Согласитесь, что вы не найдете в интернете гайдов "как правильно передать параметры функции cos". Но как чекаутнуть произвольный коммит и, самое главное,как потом вернуть репозиторий в чистое состояние без необходимости удалять всю локальную копию и клонировать репу заново -- этим интернет завален. git branch -D master; git checkout --track origin/master -- о господи, это же так очевидно, почему я сразу не догадался?
Разве автор писал про "Паскаль не язык, а ты не программист" ? Хотя я сам паскалист, и я по факту вижу подобное мнение от индустрии. Разница между мной и автором в том, что я по итогу вышел в JS и C/C++ почти на сеньора, напиисал свой опенсорсный проект солидного размера, который я всегда могу показать сомневающимся, и забыл про паскаль. Ну что ж поделать, если паскаль последние лет 30 почти не развивается?
Я ничего не понял, за что минуса? Мне, как программисту с большим стажем, неприятно работать со многими вайтишниками, и я был бы очень рад, если бы подобные статьи отбивали желание у очередного вайтишника трепать нервы подобным мне разработчикам, любящим программировать и не испытывающим при этом трудности, даже с чужим лапшекодом.
Ну или да, почему нет такого варианта, что амазон тупо сделал синхронную репликацию таки и в метабазах S3, когда перешел на консистентность?
Не обратил внимание на "МЕТАданные". Да, по сути, подмножество метаданных обновляется синхронно -- именно об этом говорит конечная описанная мной модель S3. Правда, в число синхронных метаданных входит только расположение ключа, дата его помещения, и еще некоторые внутренние штуки, вроде индексов. Другое дело, что это в основном внутренние невидимые метаданные, а не те метаданные, которые клиент указал в PUT-запросе.
Про чтение с primary правда, но там это не мешает, т.к. шардируется в разрезе PG, а PG дофига и на каждом OSD размещается их 100 штук примерно обычно, и для части он оказывается primary. Поэтому там и смысла нет читать с реплик, и там все диски утилизируются.
У меня софтина с десятками миллионов пользователей. В софтине выявилась бага, ее нужно срочно пропатчить. Я публикую в Ceph обновления, которые автоматически подхватываются клиентами -- это генерирует сотни тысяч запросов в секунду к одному файлу. И это еще не самая большая нагрузка, крупные игроки могут иметь миллионы загрузок одного файла в секунду.
Метаданные реплицировать асинхронно т.к. это БД, чтобы не тормозить ее, те же листинги... а данные пишутся все равно относительно долго и там есть время сходить на другие реплики.
Вот именно: данные пишут долго, метаданные -- быстро. Да, по поводу списков можно спорить, но недолго -- проблема у индексов только с персистентностью, в памяти их можно изменять очень быстро.
Ну или да, почему нет такого варианта, что амазон тупо сделал синхронную репликацию таки и в метабазах S3, когда перешел на консистентность?
Остальные ограничения и неудобства S3 никуда не исчезли, а значит остальная реализация не менялась. Более того, у S3 весьма сложные замороченные уровни доступности-архивации, которые в том числе являются причиной для существования асинхронной репликации внутри региона. Тот же B2 вообще никуда не двигает файлы. он просто сохраняет их один раз на жесткие диски, и всё.
Ну просто иначе надо организовывать какую то очередь асинхронной репликации данных, кэши вот эти извратные и т.п., неудобно как-то.
Кэши и асинхронная репликация у них как раз были давно, они просто прикрутили к кэшам когерентность в пределах региона. Если делать PUT и GET на один сервер, то там read-after-write работал и так, проблема была актуальнадля GET с другого сервера в регионе и для любого LIST (списки тоже обновлялись асинхронно).
ну меня как-то это не убеждает. могут данные реплицироваться синхронно например (сразу писаться на несколько дисков), а метаданные в репликах БД доползать асинхронно
Зачем, если реплицировать метаданные проще, чем данные?
или например могли просто с переходом на консистентность просто поменять архитектуру, может там теперь цефоподобное нечто внутри?
У Ceph есть очень и очень серьезная проблема с масштабируемостью чтений, поскольку в норме он читает из единственной реплики, за счет чего и обеспечивается строгая согласованность, а на другие реплики запросы чтения перенаправляются только после отказов.
И это не просто какая-то хотелка авторов Ceph -- это физические непреодолимые трудности: либо доступность и производительность, либо согласованность. При всех недостатках, выбранный Амазоном подход в типичных для S3 сценариях приводит к линейному масштабированию скорости записей и чтений при росте числа хранилищ без шардирования. А Ceph может масштабироваться только шардированием. Правда, я не вижу каких-то принципиально непреодолимых препятствий для того, чтобы Ceph мог начать читать объекты со всех реплик, а S3 начал делать простую синхронную репликацию без необходимости в замороченных роутерах-свидетелях.
Вы уверены, что не путаете (вероятно синхронную) внутреннюю репликацию в рамках бакета для обеспечения избыточности и (явно асинхронную) репликацию между бакетами, видимо для обеспечения геораспределённости?)
Они обе асинхронные. Если бы репликация внутри региона была синхронная, как у B2, то проблемы read-after-write вообще бы не существовало. Проблема в том, что S3 изначально сохраняет объект из PUT-запроса не туда, где он будет хранится. То есть (тс-с-с, только между нами девочками) Amazon решает проблему, которую сам же себе и создал. Переусложненные задачи -- это вечная проблема энтерпрайза.
Ну а гарантии read-after-write и монотонных чтений-записей меж регионами и вовсе нет, так что при честном сравнении с ZooKeeper и Spanner, спроектированными для строгой согласованности по всему земному шарику, "строгая согласованность" у S3 существует только при взгляде под правильным углом и грамотном освещении, как то в новостях Амазона и блоге Вернера Вогельса (еще раз к слову о тому, почему я не считаю Вернера программистом-архитектором).
Если я делаю какие-то крупномасштабные изменения, то, естественно, я сохраню старую версию, с Git или без Git, разговор ведь не об этом совсем, такие события происходят нечасто, чтобы под них прогибать всю модель разработки.
Не частых сохранений, а частых коммитов. checkout/update нужен для переноса правок на другую ревизию, эдакий аналог rebase, но для незакоммиченных правок. Другой более близкий аналог в самом Git -- это stash.
Это и есть checkout, что я и пытался объяснить.
"Давайте оценивать бегунов по скорости ползания на руках, ведь иначе это будет нечестно по отношению к безногим".
Эти два тезиса очевидно входят в противоречие. Навык устной речи никуда не атрофируется, а просто засыпает как ненужный. Письменный язык и устный язык -- это просто сильно разные штуки. Потому что письменный язык в массовых культурах составлен академическими мудаками, имевшими целью искуственное усложенния языка, фонетическая же запись ближе к устной речи и таких проблем не создает.
git checkout нужен на грязном рабочем каталоге для слияния локальных правок с последними правками в публичной репе. Примерно то, для чего делается "git pull --rebase --autostash", только для перехода к конкретной ревизии. То, для чего в SVN есть "svn update", а в Mercurial есть "hg update". Паталогичная же культура git заключается в том, что от разработчиков требуют держать все локальные правки в виде коммитов, из-за чего отпадает необходимость в "git checkout" на грязном рабочем каталоге, потому что рабочий каталог всегда чистый.
Но у чистого рабочего каталога есть своя цена -- теперь вместо того, чтобы применять локальные правки к какой угодно ревизии, я должен постоянно переписывать историю локальных веток, то есть, merge-rebase-squash-cherry pick, я должен упиваться кишками git вместо того, чтобы просто заниматься разработкой.
Вот именно, одна и та же команда используется в роли "уничтожить локальные правки" и в роли "сохранить локальные правки после синхронизации". Но по факту это настолько опасно и заморочено, что я (и не только я) использую стэш и автостэш вместо какого-нибудь `git checkout --merge` или `git rebase`. Всё, что я до сих пор пытался сказать -- это что git взял за фундамент патологичный рабочий процесс, и только с годами и тысячами простреленных ног к гиту наконец прикостылили и даже внедрили в ядро рабочий процесс здорового человека, например, `git pull --rebase --autostash`.
Вот это самое "ни разу не применял" -- это одно из проявлений паталогии, а именно -- избегание грязного рабочего каталога и коммиты каждые 5 минут. Что есть бессмысленно, потому что никого не волнуют эти незаконченные правки, они все равно будут сквошнуты и ребейзнуты -- именно последнее и есть настоящий рабочий процесс, а не плетение макаронного монстра в истории публичного репозитория.
А Git научился в patch queue? Я понимаю, что сообщество уже напилило вокруг Git костылей под это дело, но можно было сделать сразу хорошо.
Не создание ветки, а стирание изменение в рабочем каталоге, которое умеет делать checkout. Тот же checkout, который применяется для подготовки правок к коммиту в этом же рабочем каталоге.
Это провокационный вопрос плана "какая же у вас шморгалка" -- эта команда уже жёстко протекает внутренностями git, которых, ожидаемо, просто нет в других VCS. В том же Mercurial нет такой замороченной системы веток с трекингом, потому аналогичной команды просто не существует, а существует акцент на плоской истории через грязную рабочую копию, расширение strip, или расширение очередей патчей.
В Mercurial есть даже слизанное с гита расширение rebase, но по факту малопопулярное потому, что rebase решает правильную задачу неправильным образом -- мне, как правило, никогда не нужно условно необратимо переместить ветку с одного места в другое, да еще и потенциально переписывая историю коммитов на публичной репе. Вместо этого есть чёткое деление на рабочие правки и рабочие патчи, не принадлежащие истории, и саму история, которую публична и не подлежит изменению, которую я строго дописываю в конец на основе рабочих правок, и потому не выбью стул из-под ног человека, работающего с опубликованной веткой. Git по итогу пришел к тому же, но окольными путями и бессмысленными усложнениями операций с ветками.
Удобства? Это как ковбои носили револьверы снятыми с предохранителя "для удобства", и стреляли себе в ногу? "Ну а что, вдруг кому-то понадобится срочно выстрелить себе в ногу?" -- так, что ли? Кажется, о чем-то таком думал Торвальдс, создавая изначальным прототип Git.
git checkout -- это как раз одна из самых безумных команд git, потому что одновременно применяется для подготовки незакоммиченных изменений в рабочем каталоге, для стирания изменений в рабочем каталоге, и для операций над ветками. Чтобы понять, как работает checkout, мне нужно понимать: что есть некий "индекс", который не коммит и не рабочий каталог, что есть "ветки", которые на самом деле не ветки, а головы ветки ( "достаточно знать что "ветка" в гите является просто именованным ярлыком для номера коммита ", да), потому что ветки не могут прыгать по всему репозиторию и не могут схлопываться в один коммит; понимать, что такое "оторванная башка" и почему она оторванная.
Ты уже по крупицам из меня выгягиваешь статью. Прямыми провальными решениями при создании git был именно выбор такого понятия "ветки" и применение индекса вместо реализации удобного интерфейса формирования коммита без внесения третьей сущности в контроль версий. Косвенными провальными решениями была ориентация на интенсивное ветвление, что в том числе усложнило опции команд работы с ветками, при том, что по итогу от этих веток все равно отказываются либо в пользу патчсетов и ревью, либо в пользу прямого формирования плоской истории изменений через какой-нибудь `git pull --rebase --autostash` -- не так давно git получил эту фичу, которая в других VCS была из коробки изначально.
Например, тот факт, что две заметно разные и при этом совсем не тривиальные команды дают один и тот же результат. Это если коротко. Если длинно, то я могу накатать целую статью. Как правило, короткого ответа хватает всем, кто хотя бы пару месяцев поработал с альтернативными VCS и знает, что ими можно пользоваться почти не читая документацию. Потому что VCS служит мне, а не я служу VCS. Интерфейс командной строки Git написан так, что нужно либо детально знать внутреннюю архитектуру кода и структур данных, либо заучить запредельное число готовых команд (сильно больше, чем упомянуто в этой статье), чтобы достаточно комфортно с Git работать. Благо, VS Code лично меня спасает от большей части базовых команд, но в сложных случаях все равно приходится лезть в консольку.
Что и требовалось доказать.
Ждем статьи "300 команд, которые сделают вас мастером bash". Восьмидесятые прошли, но но для некоторых они остались в душе навсегда. Тулза. которая должна была быть незаметной, как калькулятор, стала идолом, к которому разработчики вынуждены обращать мольбы по нескольку раз в день. Согласитесь, что вы не найдете в интернете гайдов "как правильно передать параметры функции cos". Но как чекаутнуть произвольный коммит и, самое главное, как потом вернуть репозиторий в чистое состояние без необходимости удалять всю локальную копию и клонировать репу заново -- этим интернет завален.
git branch -D master; git checkout --track origin/master-- о господи, это же так очевидно, почему я сразу не догадался?SVN
Пф-ф-ф, у AWS даже нет понятия "папки", не то что их перемещения. Есть только понятие "префикс ключа".
Разве автор писал про "Паскаль не язык, а ты не программист" ? Хотя я сам паскалист, и я по факту вижу подобное мнение от индустрии. Разница между мной и автором в том, что я по итогу вышел в JS и C/C++ почти на сеньора, напиисал свой опенсорсный проект солидного размера, который я всегда могу показать сомневающимся, и забыл про паскаль. Ну что ж поделать, если паскаль последние лет 30 почти не развивается?
Я ничего не понял, за что минуса? Мне, как программисту с большим стажем, неприятно работать со многими вайтишниками, и я был бы очень рад, если бы подобные статьи отбивали желание у очередного вайтишника трепать нервы подобным мне разработчикам, любящим программировать и не испытывающим при этом трудности, даже с чужим лапшекодом.
Хм-м-м, и то правда -- 5500 GET запросов в секунду на один префикс, а потом 503.
Не обратил внимание на "МЕТАданные". Да, по сути, подмножество метаданных обновляется синхронно -- именно об этом говорит конечная описанная мной модель S3. Правда, в число синхронных метаданных входит только расположение ключа, дата его помещения, и еще некоторые внутренние штуки, вроде индексов. Другое дело, что это в основном внутренние невидимые метаданные, а не те метаданные, которые клиент указал в PUT-запросе.
У меня софтина с десятками миллионов пользователей. В софтине выявилась бага, ее нужно срочно пропатчить. Я публикую в Ceph обновления, которые автоматически подхватываются клиентами -- это генерирует сотни тысяч запросов в секунду к одному файлу. И это еще не самая большая нагрузка, крупные игроки могут иметь миллионы загрузок одного файла в секунду.
Вот именно: данные пишут долго, метаданные -- быстро. Да, по поводу списков можно спорить, но недолго -- проблема у индексов только с персистентностью, в памяти их можно изменять очень быстро.
Остальные ограничения и неудобства S3 никуда не исчезли, а значит остальная реализация не менялась. Более того, у S3 весьма сложные замороченные уровни доступности-архивации, которые в том числе являются причиной для существования асинхронной репликации внутри региона. Тот же B2 вообще никуда не двигает файлы. он просто сохраняет их один раз на жесткие диски, и всё.
Кэши и асинхронная репликация у них как раз были давно, они просто прикрутили к кэшам когерентность в пределах региона. Если делать PUT и GET на один сервер, то там read-after-write работал и так, проблема была актуальнадля GET с другого сервера в регионе и для любого LIST (списки тоже обновлялись асинхронно).
Зачем, если реплицировать метаданные проще, чем данные?
У Ceph есть очень и очень серьезная проблема с масштабируемостью чтений, поскольку в норме он читает из единственной реплики, за счет чего и обеспечивается строгая согласованность, а на другие реплики запросы чтения перенаправляются только после отказов.
И это не просто какая-то хотелка авторов Ceph -- это физические непреодолимые трудности: либо доступность и производительность, либо согласованность. При всех недостатках, выбранный Амазоном подход в типичных для S3 сценариях приводит к линейному масштабированию скорости записей и чтений при росте числа хранилищ без шардирования. А Ceph может масштабироваться только шардированием. Правда, я не вижу каких-то принципиально непреодолимых препятствий для того, чтобы Ceph мог начать читать объекты со всех реплик, а S3 начал делать простую синхронную репликацию без необходимости в замороченных роутерах-свидетелях.
Они обе асинхронные. Если бы репликация внутри региона была синхронная, как у B2, то проблемы read-after-write вообще бы не существовало. Проблема в том, что S3 изначально сохраняет объект из PUT-запроса не туда, где он будет хранится. То есть (тс-с-с, только между нами девочками) Amazon решает проблему, которую сам же себе и создал. Переусложненные задачи -- это вечная проблема энтерпрайза.
Ну а гарантии read-after-write и монотонных чтений-записей меж регионами и вовсе нет, так что при честном сравнении с ZooKeeper и Spanner, спроектированными для строгой согласованности по всему земному шарику, "строгая согласованность" у S3 существует только при взгляде под правильным углом и грамотном освещении, как то в новостях Амазона и блоге Вернера Вогельса (еще раз к слову о тому, почему я не считаю Вернера программистом-архитектором).