>>> Тогда git (да и hg тем более) - как раз отвертка валшебная.
>>>  Если надо тоньше - сделаем тоньше, если еще как-то удобнее
>>> сделать - будет.  Это в cvs насадка навсегда одна и
>>> еще стержень кривой.
>> Да можно, можно всё это в случае с Git, кто ж спорит.
>> Только вы же сами говорите — «если надо — сделаем».
> Да не надо ничего дорабатывать, максимум - выучиться командам.

Тогда вы сами себе противоречите словами «если надо — сделаем».

>[оверквотинг удален]
>> git ci ...
>> git push
> Нет, это делают не так (начиная с того, что git up -
> это какой-то ваш алиас, вероятно.
> Делают проще:
> emacs ...
> git commit ..
> git push ...
> Если git push заругался на наличие в основном репе изменений, отсутствующих локально
> - делаем git pull --rebase и уже потом push.

Править исходники, не обновив их, обычно плохая идея — сводить больше и больнее придётся.

>> Можно избавиться от отдельного «git up», поправив конфиг.
> Из коробки избавились:
> $ git up --help
> git: 'up' is not a git command. See 'git --help'.
> ...
> $ git update
> git: 'update' is not a git command. See 'git --help'.
> ...

(дублирую написанное Митрофанову насчёт git up)
Переклинило. git rebase там, конечно же. Писал, пользуясь в этот момент Mercurial и Subversion, вот оно и.

>> Но и то, и другое — дополнительные усилия, которые не требуются
>> в случае CVS.
> Дополнительные усилия называются: чтение документации на уровне туториала.  Git все-таки
> не является копией CVS (аллилуия!), потому команды и их аргументы - несколько
> другие.

Угу, угу. Все дураки, один Git умный. Одна только загадочная логика, когда с помощью branch можно сделать угодно, кроме собственно переключения веток, чего стоит. Учить надо, да, но в итоге всё равно регулярно путаешься (как я выше) — если, конечно, не пользоваться одним только Git.

> Ну и, еще раз напоминаю: реалии мира таковы, что люди скорее будут
> вынуждены выяснять
> что такое cvs update.

Всё может быть. Только это произойдёт в первую очередь из-за новых проектов. А не из-за миграции старых.

>>> Ну в самом деле, аналогичная cvs модель работы - никаких специальных усилий
>>> от мейнтейнера не требует.  Наверное, можно даже сказать что львиная
>>> доля пользователей пользуют именно ее.
>> Правильно, а почему они её используют? — патамушта Linux и GitHub.
> Ну как бы было время, когда гитхаба - не было.  Зато
> CVS был давно.  Это, наверное, масоны устроили так, чтобы он
> на гитхабы с линуксами не попал?)

Да я же писал, что не в претензии. Причины понятны. Но не гитхабом единым живы программисты.

>> И когда задачи в основном вида
>> «поправить вот эту мелочь» и «добавить вот такую фичу на двести
>> строчек», подойдёт любая VCS, вообще любая.
> Я надеюсь, описанный сценарий - не для OpenBSD.

Не понял, что вы имели в виду. Что в OpenBSD не должно быть маленьких правок? Или что?

>> При этом порог вхождения у CVS всё же чуточку меньше — да, в том числе из-за
>> отсутствия каких-то фич, типа git index.
> Знать такие вещи - как правило и не требуется для рядового пользователя.
>  Это как если б
> я попросил вас рассказать что может поломать cvs update, если вдруг свет
> вырубят.

Не соглашусь. Пока не сел и спокойно не разобрался с git index (и в целом с Git) в своё время, постоянно матерился на непонятное поведение при add и commit.

>> Я понимаю, что в глазах
>> многих людей сознательный отказ от фич выглядит, говоря литературным языком, ретроградством,
>> но за ним стоит кое-что большее, чем лень и нежелание учиться.  :)
> Кстати, а в OpenBSD как изменения тестируются?  Полазал по сайту, как-то
> там глубоко ссылки на ваш CI сервис закопаны.

Кто хочет сам прогнать тесты — идёт и делает make regress.

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