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

В статье автор ругается на то, что по факту в Go везде считается, что в string-ах «ну наверное UTF-8, а может и нет», а больше никаких гарантий ни язык, ни API не предоставляют.

Смотри комментарий выше про системы типов.

Давайте тогда вообще все данные хранить в int-ах

ты не поверишь!

ты не поверишь!

Во, а то придумали какие-то глупые люди идрисы, хаскели, расты, которые за них всё проверяют. На ассемблере надо писать!

Кстати код, который пишете для предприятия также в обменниках сохраняете?

Зависит от предприятия. На всех есть частные репозитории, на BitBucket даже на бесплатном тарифе. Или же предприятие вполне может держать свой инстанс gitlab/bitbucket/you-name-it.

И вносить коррективы в работающий образ программы.

string-ах «ну наверное UTF-8, а может и нет», а больше никаких гарантий ни язык, ни API не предоставляют.

Кто сказал, что там должен обязательно быть utf? А что если в строку считают текст изначально закодированный в cp866 или ещё какой другой кодировке, то в строке utf8 должен сказочным образом оказаться?

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

Ты мне лучше расскажи как в таком случае в rust вывести валидные части utf8 строк, если тут привозносится, то, что при чтении в их строку он в такой ситуации её вообще не создаст.

Попробуй меньше хамить и выборочно цитировать.

Если ты не понимаешь, что такое «системы типов» и почему пихать всё в string есть плохая затея, — твои проблемы.

Зависит от предприятия. На всех есть частные репозитории, на BitBucket даже на бесплатном тарифе. Или же предприятие вполне может держать свой инстанс gitlab/bitbucket/you-name-it

Каким донным должен быть коммерс, чтобы не позволить себе поставить какое-то дешманское корыто под сервер. Блин, даже роутер на OpenWrt с флешкой справится с задачей, пусть и с некоторой необходимостью ставить костыль вроде gitolite.

Попробуй меньше хамить и выборочно цитировать

ну извини, что напомнил. неловко вышло

такое «системы типов»

в этом нет ничего сложного, даже для меня

почему пихать всё в string есть плохая затея

то есть ты один из предлагающих забить на другие кодировки, так бы сразу и сказал

Или каждый раз перед тем, как внести изменения, делать очередной тарбол?

Инкрементальный бэкап с ревизиями файлов, используя написанный на go restic.

ну вот человек «удивился» (на самом деле он это и так знал, но было 29 февраля и можно всё, даже немножко пошалить), что строка - на самом деле это последовательность байт и что эта последовательность не зависит от кодировок - она считается всё в ту же последовательность байт

в этом нет ничего сложного, даже для меня

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

то есть ты один из предлагающих забить на другие кодировки

Нет.

ты продолжаешь усиленно включать дурака

ты вообще его в последнее время не выключаешь

будто ничего не произошло

а что произошло?

Каким донным должен быть коммерс, чтобы не позволить себе поставить какое-то дешманское корыто под сервер

Так GitHub/BitBucket/etc as a service лучше чем «дешманское корыто». Плюс не надо его администрировать. Т.е. вопрос не в «донности» комерса, а в деньгах.

Блин, даже роутер на OpenWrt с флешкой

Ну для GitLab требуется 8GB RAM (https://docs.gitlab.com/ee/install/requirements.html), это чуть по более, чем роутер.

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

Ты упускаешь тот момент, что система контроля версий - это не только синтаксис командной строки, но и определенная идея работы с ней, ее возможности, инфраструктура - ну там разные инструменты, которые используются в связке. Git подходит требованиям, и с ним знакомы в команде? Отлично. Это на форуме можно бесконечно письками меряться, а на работе стоят конкретные задачи c конкретными сроками - за N дней перевести репозитории с SVN на что-то более подходящее, развернуть то и это, настроить, рассказать, показать, начать трудиться.

По этой причине спрашивать о владении SCM примерно подобно тому, как спрашивать «какими текстовыми редакторами вы владеете?

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

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

Так же вчера был SVN, завтра Git — люди вообще не парятся, какая там тулза у них держит сорцы.

См. выше. Ну и ты сам себе противоречишь:

Да, ты упомянул SVN, но у неё есть своя специфика, которая не всем подойдет.

Git не дает способов просто сделать checkout в грязной репе

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

порождает пагубную моду «коммит на каждый чих»

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

Так GitHub/BitBucket/etc as a service лучше чем «дешманское корыто». Плюс не надо его администрировать.

...и можно там же проинтегрироваться с Jira и Confluence, которые тоже не придется администрировать.

К слову, забыл об этом.

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

Я люблю информативные описания, да, чтобы без просмотра правок было хотя бы в общих чертах понятно, для чего правки были внесены, что и как в них сделали. Что-нибудь вроде:

sfc: fix timestamp reconstruction at 16-bit rollover points

We can't just use the top bits of the last sync event as they could be
off-by-one every 65,536 seconds, giving an error in reconstruction of
65,536 seconds.

This patch uses the difference in the bottom 16 bits (mod 2^16) to
calculate an offset that needs to be applied to the last sync event to
get to the current time.

Какая разница, дает ли он линейную или нелинейную историю?

Да ориентироваться в линейной потом проще, вот и все.

Накопали порцию wtf и начали обмазываться
От чего там автор оргазмирует от Rust? Ну да у него то нет проблем ))

Так GitHub/BitBucket/etc as a service лучше чем «дешманское корыто». Плюс не надо его администрировать. Т.е. вопрос не в «донности» комерса, а в деньгах

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

Ну для GitLab требуется 8GB RAM (https://docs.gitlab.com/ee/install/requirements.html), это чуть по более, чем роутер

У меня роутер с 64 Мб оперативы, 16 Мб загрузочная флешка. На нем сейчас просто веб морда и SSH, занято половину флешки. Gitolite весит еще 120 Кб. Чо там? «Our Memory Team is actively working to reduce the memory requirement»? Пусть работают, я пока подожду.

У меня роутер с 64 Мб оперативы, 16 Мб загрузочная флешка. На нем сейчас просто веб морда и SSH, занято половину флешки.

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

Это на форуме можно бесконечно письками меряться, а на работе стоят конкретные задачи c конкретными сроками

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

https://xkcd.com/1597/

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

Да, я страдал из-за сложностей с поддержкой локальных правок в SVN. Но рак с переписыванием истории родом исключительно из Git - его нет больше нигде. Если так работать с Mercurial, то рано или поздно ты получишь вот это:
https://lostechies.com/content/jimmybogard/uploads/2011/03/image_thumb_4EE6AA...
Да, в Perforce и Mercurial возможно подражать такой работе в Git с получением аккуратной истории, но это вполне целенаправлено порицается, поскольку разрушает саму суть VCS.

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

Так же вчера был SVN, завтра Git — люди вообще не парятся, какая там тулза у них держит сорцы.

См. выше. Ну и ты сам себе противоречишь:

Да, ты упомянул SVN, но у неё есть своя специфика, которая не всем подойдет.

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

Git спокойно дает сделать checkout, если измененные файлы одинаковы в обеих ревизиях (в дереве коммитов, я имею в виду). Вот если файл изменялся, то выбросит ахтунг

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

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

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

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

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

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

и можно там же проинтегрироваться с Jira и Confluence, которые тоже не придется администрировать

Жира интегрируется даже с голым Git по SSH/HTTPS/локальная сеть. Ровно как и с Mercurial и Perforce.

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

sfc: fix timestamp reconstruction at 16-bit rollover points

We can't just use the top bits of the last sync event as they could be
off-by-one every 65,536 seconds, giving an error in reconstruction of
65,536 seconds.

This patch uses the difference in the bottom 16 bits (mod 2^16) to
calculate an offset that needs to be applied to the last sync event to
get to the current time

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

Какая разница, дает ли он линейную или нелинейную историю?

Да ориентироваться в линейной потом проще, вот и все

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

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

Бэкапы на другой машине никто не запрещал. К тому же, Git естественным образом бэкапится.

Да и вообще, роутер не такое уж и днище - это вполне себе достойный компьютер уровня 2004-2005 года, если не считать слишком уже малого кол-ва оперативной памяти DDR2-800. Что-то плана Deus Ex на подобном железе уже в 60 фпс шло (со внешней видеокартой, естественно).

Я Mercurial не знаю, но бесполезные коммиты? Этож как быстрое сохранение

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

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

Как нет? Ты разве используешь не исключительно последнюю версию сорцов?

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

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

А с тобой ничего не случается один хрен приходишь на работу с утра… :D

на случай если завтра с тобой что-то случиться :)

Они там слова «Централизованные бэкапы» не слышали походу

что по сравнению с Го тут куда более продуманный и гибкий.

Раст-то? Это поделие, которое вначале задумывалось с грин-тредами и GC и в котором убогие костыли для обработки ошибок? Как раз это поделие и оставляет ощущение полной непродуманности. А Го как раз продуман. Правда, старпёрами, поэтому такая обработка ошибок вместо унион-тайпов со спец-конструкцией для нештатных ситуаций

file := os.Open(filename) or err {
     return errors.Wrap(err, "open destination file")
}

А как ты организуешь централизованные бэкапы на компах девелоперов где каждый волен выбирать дистрибутив?

рак с переписыванием истории родом исключительно из Git - его нет больше нигде.

В mercurial переписывается запросто, до отправки на сервер. Да и там при желании можно разрешить. Как и в git определяется настройками сервера.

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

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

Так не занимайся такими играми, закоммить в локальную коп что успел - внесённые изменения точно не пропадут, - потом вернёшься к работе и сделаешь commit –amend.

В сценарии со squash/rebase Git не выполняет роль VCS, поскольку теряет версии исходников, и по этой причине его применение не оправдано.

Глупость какая. Не всем нужны ненужные исходники. Не говоря о том, что reflog где хранится всё что было закоммичено, если уж совсем приспичит.

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

А для кого мусорная корзина? Мне казалось, что все используют любые VCS для фиксации внесённых изменений в процессе работы. Если в твоём окружении их используют для хранения как некоторые корзину на рабочем столе, то это не проблема VCS.

Однако, Git не дает простых путей работаты с грязной репой

Так не работай с ней. Зачем самому себе проблемы создавать?

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

Не делай бесполезных коммитов и не превращай репозиторий в мусорник. PROFIT.

Мне вообще пофиг что использовать hg или git - в чём конкретный проект ведётся, в том и делаю. Разве что hg у меня всегда был в связке с tortoisehg workbench.

Кто сказал, что там должен обязательно быть utf?

Как думаешь, вот этот https://golang.org/pkg/path/filepath/ пакет написан с рассчетом на какую кодировку путей?

А что если в строку считают текст изначально закодированный в cp866 или ещё какой другой кодировке, то в строке utf8 должен сказочным образом оказаться?

Вот именно это и предполагается по все стандартной библиотек go - никаких других кодировок кроме utf8 не бывает.

написан с рассчетом на какую кодировку путей?

Package filepath implements utility routines for manipulating filename paths in a way compatible with the target operating system-defined file paths.

по все стандартной библиотек go - никаких других кодировок кроме utf8 не бывает.

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

Эта возня с path в rust началась из-за бага (и подобных ему): https://github.com/rust-lang/rust/issues/12056 , когда выяснилось, что их старая реализация переменной path не умеет работать с такими путями.

Насчёт golang тут 2 (более менее) варианта:

1. существует проблема, что появившаяся в рамках работы с путями переменной типа строка последовательность байт не предоставляет возможности дальше работать с таким файлом (чтение, запись, копирование, удаление, переименование) и на это существуют жалобы (и демонстрация проблемы) или лучше багрепорт;
2. никакой проблемы нет и такие файлы прекрасно обрабатываются несмотря на то, что отобразить пользователю имя мы не можем (напомню, что и в случае rust с переменной типа path путь тоже невозможно правильно отобразить).

Раст-то? Это поделие, которое вначале задумывалось с грин-тредами и GC и в котором убогие костыли для обработки ошибок? Как раз это поделие и оставляет ощущение полной непродуманности.

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

На мой скромный взгляд, Rust - самый продуманный концептуально язык среди всех широко известных системных языков программирования. Их список весьма маленький: Ada, C, C++, Rust.

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

Package filepath implements utility routines for manipulating filename paths in a way compatible with the target operating system-defined file paths

По факту это относится только к разделителям в пути и никак не учитывает кодировки. Так что мимо.

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

Типичное заблуждение сишников и гоферов, но нет, нельзя.

На мой скромный взгляд, Rust - самый продуманный концептуально язык

Ну так он еще только на начале своего пути, в отличие от других языков. И не стоит забывать, что каждый новый релиз его усложняет. А если он действительно станет популярным, то в него активно начнут добавлять всякие удобности и современные (в будущем) фичи. Может и ООП добавят (не обязательно такое как в С++, но удобнее чем то, что сейчас есть). И получится монстр похлеще С++ со своим грузом легаси.

При работе с байтами ничего нужно ничего знать о кодировке.

Типичное заблуждение сишников и гоферов, но нет, нельзя.

Мдя…ну и считай дальше иначе.

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

stw займет около 10 мс

В mercurial переписывается запросто, до отправки на сервер. Да и там при желании можно разрешить. Как и в git определяется настройками сервера

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

Переписывание истории нужно для того, чтобы в том же пулреквесте в мастер после ревью уходили аккуратные атомарные коммиты, из каждого из которых было понятно что и как менялось, а не одна правка раскиданная по 10коммитам с разрывами после просьб внести изменения

Для этого сделано MQ, которое базируется на https://en.wikipedia.org/wiki/Quilt_(software) .

Так не занимайся такими играми, закоммить в локальную коп что успел - внесённые изменения точно не пропадут, - потом вернёшься к работе и сделаешь commit –amend

Одна из частых потребностей: выделить из сделанной за некоторый период работы часть правок, протестировать работоспособность проекта с этими правками, и релизнуть эту версию. Я очень хотел бы увидеть, как методика частых коммитов помогает упростить эту задачу. Сразу подчеркну, что в истории изменений не существует такой ревизии, которую я мог бы просто релизнуть, потому что я занимался несколькими задачами параллельно - и нет, создание 10 веток (на каждую мелкую фичу) за два месяца с последующим развлечением в их слиянии в разных комбинациях абсолютно неприемлимо. Также замечу, что я в основном корректирую именно правки, которые я сделал, то есть, вывод «git diff master...».

То есть, в случае Git я должен из моих локальных коммитов создать новую ветку, стереть в ней ненужные правки, отображаемые в «git diff master...», и дальше делать merge/rebase со squash/без. Поскольку squash+rebase является самым частым вариантом здесь, то я бы заметил, что по результату работы оно не отличается от применения патча, особенно учитывая, что автоматически собрать комментарии не получится и писать их придется ручками заново.

Теперь претензия, которую я предъявлял здесь уже несколько раз: зачем я тогда вообще создавал ветку и коммитил в нее свои правки? «hg update -m» по сути делает squash+rebase, получая тот же результат. При этом, я с тем же успехом могу дальше прыгнуть на другую ветку, потом на третью, а потом прыгнуть обратно на исходную ветку. В результате, вся операция делается за «hg update -m; hg shelve -k; правки; hg commit» либо «hg shelve -k; правки; hg update -m; hg commit» — я подчеркиваю, что здесь имеет место нулевая предварительная подготовка репозитория, я трогаю VCS только когда мне нужно.

Вторая упомянутая ранее претензия: да, Git теоретически позволяет проводить аналогичный сценарий, но в Git, как правило, это делать опасно и неудобно, и по этой причине пользующиеся Git люди вынуждены изучать наиболее простые и удобные пути работы с Git, которые как раз и сводятся к частым коммитам, rebase+squash, stash+pop и другим. Самые важные свойства VCS, на мой взгляд, — это не мешать и не терять пользовательcкие данные, и в этом плане Git весьма заметно проигрывает как Mercurial, так и Perforce. Git был создан, когда не было Mercurial и когда Perforce был платным, но в 2020 году нет ни одной причины пользоваться неудобным и опасным инструментом, когда есть более удобный и безопасный.

Не говоря о том, что reflog где хранится всё что было закоммичено, если уж совсем приспичит

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

Однако, Git не дает простых путей работаты с грязной репой

Так не работай с ней. Зачем самому себе проблемы создавать?

Потому что, внезапно, в SVN, Perforce, и Mercurial это делается очень просто и требует минимального взаимодействия с VCS. Чем-то напоминает: «мы раком ходим - и ты ходи. Ты что, дурак, прямо ходить? Так же упасть и лоб расшибить можно».

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

stw займет около 10 мс

Сказочники!

И меня интересует не среднее, не персентиль, а самое худшее значение, потому что оно может вылезти в самый неподходящий момент. Например, если больше половины оперативной памяти пришлось только что обновить, скажем, 32 гига пришлось заменить новыми данными вот прямо только что? И если обновлять состояние нужно эпизодически? Большой поток изменений? Если поколения долго не живут, но живут достаточно, чтобы пройти всю лестницу изменений?

Не верю! (c)

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

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

Изначальная претензия была о том, что UTF-8 не позволяет хранить все символы 2-байтного юникода, который широко применяется на форточках. Для этой цели и придумали кодировку WTF-8.

Например, открытие файла в стандартной либе Go сделано через

func Open(path string, mode int, perm uint32) (fd Handle, err error) {
	pathp, err := UTF16PtrFromString(path)
	...
	h, e := CreateFile(pathp, access, sharemode, sa, createmode, attrs, 0)
	return h, e
}

Это проблемы нет на никсах, где все системные кодировки представимы в виде последовательности байт, но двухбайтовый юникод сам по себе не является последовательностью байт, поскольку есть как минимум два способа превращения (LE и BE).

Я так и не увидел никакого конструктивного ответа, кроме «пусть виндузятники горят в аду».

методика частых коммитов п

Хз что это такое, но отдельные коммиты переносятся в другие ветки либо создание патчей, либо chery-pick. Может ещё проще можно, у меня в git достаточно простой набор используемых команд.

Раз всё не так - не пользуйся, делов то. Что тебя так рвёт то?

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

И меня интересует не среднее, не персентиль

The new version of Go reduces our 95-percentile garbage collector from 279 milliseconds down to just 10 ms. link

Это было про релиз Go 1.5. С тех пор были еще доработки по GC.

Nearly all STW pauses in Go are really sub-millisecond ones. If you look more real-life test case (see e.g. this file), you’ll notice that 16GB static set on a ~ regular 16-core server implies your longest pause = 50ms (vs 5s for .NET), and 99.99% of pauses are shorter than 7ms (92ms for .NET)! link

Эта статья от сентября 2018, так что тоже данные не самые свежие. Но там есть ссылка на гитхаб с бенчмарком - ты всегда можешь перепроверить.

Изначальная претензия была о том, что UTF-8 не позволяет хранить все символы 2-байтного юникода…

И ты можешиь привести код юникодного символа (codepoint), который можно выразить в utf-16 (пох le или be), но нельзя в utf-8?

Это проблемы нет на никсах, где все системные кодировки представимы в виде последовательности байт, но двухбайтовый юникод сам по себе не является последовательностью байт, поскольку есть как минимум два способа превращения (LE и BE).

Каждое слово в отдельности понимаю, даже некоторые словосочетания, всю фразу распарсить не могу…

Хз что это такое, но отдельные коммиты переносятся в другие ветки либо создание патчей, либо chery-pick. Может ещё проще можно, у меня в git достаточно простой набор используемых команд

cherry-pick всей ветки = rebase

Однако, переносить мне нужно не цельные коммиты, а их куски.

Раз всё не так - не пользуйся, делов то. Что тебя так рвёт то?

Напоминаю:

Повторишь это, когда наберешь написанную на Си команду гита, чтобы запушить новые строчки на Расте

Гит - редкостный кусок дерьма, слепленный на коленке по мотивам проприетарного софта. Лично я предпочитаю Hg

Более того, в самом сообществе понимают необходимость переделки Git, но проблема в том, что сделать ее с сохранением обратной совместимости не получится. Потому я и пишу, что Git — это пример плохого софта. Не то, чтобы автор потирая ручки сидел и думал «какую бы гадость сообществу сделать? А напишу-ка я инструмент для контроля ревизий, которым будут все пользоваться для разработки софта и страдать при этом». Нет, ему просто было всё равно, его больше волновало, что халяву с Perforce закрыли — вот он сел и написал, тупо для себя.

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

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

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

cherry-pick всей ветки = rebase

ветка ж отдельная и специально создана для экспериментов, не всё ли равно?

Однако, переносить мне нужно не цельные коммиты, а их куски.

Я в таких случаях стараюсь делать коммиты более атомарными. Но тут всё от личных привычек зависит.

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

Я как-то сделал резет ветки, забыв переключиться на ветку которую хотел сбросить, и у меня слетело 7 только что сделанных, но ещё не отправленных коммита %) Вот тут reflog очень помог. Всё что закоммичено сложно, но при желании можно потерять.

И ты можешиь привести код юникодного символа (codepoint), который можно выразить в utf-16 (пох le или be), но нельзя в utf-8?

Речь идет не про юникодные символы, речь идет про имя файла в двухбайтной кодировке. Элементарный пример: 0xD800 0x1000 — это нельзя превратить в UTF-8 и этому не соответствует никакой codepoint в юникоде, но это возможное значение в двухбайтовой строке. Соответственно, системный инструмент отличается от текстового редактора тем, что способен обрабатывать и такие случаи. И в данном случае стандартный Go делать этого не способен, потому отправляется в категорию текстовых редакторов.

Я в таких случаях стараюсь делать коммиты более атомарными. Но тут всё от личных привычек зависит

Знал бы прикуп — жил бы в Сочи. Я никогда не могу заранее угадать, что выйдет из моих правок. Аккуратные ветки с разделенными правками и безупречными коммитами бывают только в книжках — там же, где и замечательные иерархии классов с безупречной расширяемостью. В реальном мире разработка регулярно приходит к «что у нас есть, и что можно с этим сделать?». Порой возникновение ветки можно предугадать, а порой — нет. Порой во время коммита можно разделить изменения на логические сущности, а порой оказывается, что это разделение было неправильным, и теперь ветки нужно перекраивать. Мой подход очень простой: не рыпаться без нужды на то; не принимать решения, когда не имеешь ориентиров; отсутствие архитектуры лучше ошибочной архитектуры.

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

Элементарный пример: 0xD800 0x1000 — это нельзя превратить в UTF-8 и этому не соответствует никакой codepoint в юникоде

Ну и кто кому доктор, если кто-то использует неюникодные коды?

С таким успехом ты все реализации языков с внутренним представлением строки, отличным от «системного», относишь к редакторам…

Ну и кто кому доктор, если кто-то использует неюникодные коды?

Ровно как в никсах принято хранить имена файлов тупо как последовательности байт, так и в шинде принято хранить имена файлов как последовательность двухбайтовых символов, независимо от их смысла. По этой причине и другим причинам, например, питон умеет хранить строки в 1, 2, и 4 байтовых строках, а также в UTF-8.

С таким успехом ты все реализации языков с внутренним представлением строки, отличным от «системного», относишь к редакторам

Блин, ну есть еще и протоколы ведь разные, не только файловые операции. Если либа умеет обрабатывать только печатные символы, то как ее называть?