Команды git-а: worktree, subtree

https://blog.meain.io/2020/bunch-of-git-stuff/
Показаны примеры применения относительно новых команд worktree/subtree.
Первую я на практике использовал несколько раз -- есть случаи когда
реально полезно и удобно с ней. Но запросто у человека может и не
возникнуть надобности в ней. subtree не использовал, и вот с ходу пока
даже не могу представить когда бы понадобилась лично мне (так то в
статье есть примеры).

Вообще если бы я не знал git, то судя по статьям/рассылкам/блогам вряд
ли бы к нему подступался, ибо только ленивый не говорит что он дико
сложный и не понятный. Это также подтверждалось постоянно и на работах,
где люди с трудом въезжают в него. Да и если объективно прикинуть, то
достаточно посмотреть на git reset: что делает эта команда? Чего только
не делает! git checkout? Аналогично! Ну или я (до сих пор), как минимум,
не в состоянии коротко и ясно сказать для чего они. Они много для чего и
это увеличивает порог входа.

В ivi из-за плохих пониманий git-а (точнее применимости и допустимости
некоторых практик) некоторым командам запрещалось делать git cherry-pick
или rebase-ы, особенно интерактивные. git -- мощный инструмент, но
который в "плохих" руках может и вредить. Защиты от дурака в нём не много.

У меня никогда не возникало проблем с git-ом. Во-первых, мне никто
никогда с ним не помогал -- весь путь его "познания" проходил сам (с
коллегами). Во-вторых, мне кажется я использовал его фичи только после
их познания/узнавания и у меня не возникало потребностей в том что не
знал. Возможно просто везло, а не как новичкам приходящим в команду и
которых сразу бросают в пучины git rebase. Плюс мне кажется что на меня
снизошло какое-то озарение после прочтения:
http://www.ftp.newartisans.com/pub/git.from.bottom.up.pdf
после которого git выглядит чрезвычайно простой штукой.

git в целом и есть простая нехитрая и незатейливая штука. В нём немного
примитивов и действий как таковых. Просто десятки команд это помощники
для разных ситуаций. Это сплошной сахар. Одно и то же действие в git
можно выполнить, зачастую, тьмой разных способов (наборов команд). У
людей даже разные привычки как и что выполнять, хотя результат будет
один. А возможно и не один, но в одном случае будет какой-нибудь
конфликт в файлах, а в другом уже нет. И всё это создаёт сложности
(видимость), но на самом деле никакой магии нет.

Я не использовал ни Mercurial (только hg pull/clone), ни Bazaar, ни Arch
(на который вроде как и забили), ни Darcs. Читал про них. Mercurial
выглядит чище и проще, не является нагромождением всего и вся
раскиданным и пересекающимся в разных командах. Но про него от очень
опытных пользователей, которые и хорошо умеют git, наслышан про его
негибкость и сложности делать относительно сложные вещи. Для новичков
Mercurial, насколько понимаю, хорош, но для людей которые чётко понимают
что хотят сотворить с историей коммитов -- он будет занозой. Просто
наслышан о таком мнении от самых разных опытных людей, которые в итоге
переходят на git.

А ещё отдельная боль с git-ом это Github. Точнее проблема с людьми,
упорото считающих что git и Github это синонимы. Github закрывает
репозитории? А, нам всем конец, всё пропало, как жить дальше!? Только
ленивый не напоминает в комментариях всяких ресурсов что git как бы
децентрализованная система.

В общем, git штука с большим порогом входа, в том числе из-за неряшливых
команд, но очень мощный инструмент. И из-за своей мощности (возможностей
тасовки и вообще работы с коммитами) он стоит изучения/использования.
Можно не знать и 90% всех его имеющихся команд и их опций и отлично жить
с ним.

комментарий 0:

From: Алексей
Date: 2020-11-07 19:20:50Z

> Github закрывает репозитории? А, нам всем конец, всё пропало, как жить дальше!? Только ленивый не напоминает в комментариях всяких ресурсов что git как бы децентрализованная система.

Так в том-то как раз и проблема, что это децентрализованная система. И потому повторить на своём собственном сервере привычную модель Github, когда все обращаются к центральному репу, да ещё и с разными правами доступа, не так-то просто. Git на подобное попросту не рассчитан.
Тут даже поднять Git-сервер на несколько пользователей с разными правами доступа можно только через разного рода костыли типа gitolite.
А уж сделать так, чтоб pull'ить могли все желающие, а push'ить только те, у кого ключи - это вообще что-то настолько нетривиальное, что я даже с ходу не соображу, как такое на сервере можно настроить.

комментарий 1:

From: Sergey Matveev
Date: 2020-11-07 19:39:08Z

*** Алексей [2020-11-07 22:20]:
> И потому повторить на своём собственном сервере привычную модель Github[...]

Значит проблема в том, что кто-то к ней привык :-)

>когда все обращаются к центральному репу, да ещё и с разными правами доступа, не так-то просто. Git на подобное попросту не рассчитан.

Согласен. Но оно и не нужно. Если хочешь чтобы у тебя кто-то забрал
изменения: предоставь в своём репозитории, который будет чьим-то
remote-ом. Я вообще преобладающее кол-во изменений в сторонние проекты
вносил через git-format-patch+git-send-email.

>Тут даже поднять Git-сервер на несколько пользователей с разными правами доступа можно только через разного рода костыли типа gitolite.
>А уж сделать так, чтоб pull'ить могли все желающие, а push'ить только те, у кого ключи - это вообще что-то настолько нетривиальное

Или я что-то недопонял в задаче или это же всё просто: репозиторий для
чтения для всех отдаём по git/https. Запись разрешена определённому
пользователю/группе доступ к которому через SSH и соответствующие ключи.
Если что-то нужно делать не публичным, то ещё один пользователь/группа
которая имеет права на чтение директорий/файлов нужных, но не имеет
права на запись. Насколько понимаю, как правило анонимных reader-ов
много, а коммитеров очень мало -- это без проблем делается обычными
пользователями/группами Unix-овыми. Разве нет? Я, по крайней мере,
именно так делал.