Хм. Нельзя ли тупо юзать hg-git?

Это делают. Это весьма ресурсоемко, а если внесение правок ведется с обоих сторон, то получается беда.

Однако, попытка найти клиента под эту либу пока что успехом не увенчалась.

У geany есть как минимум два плагина, использующие libgit2: git-changebar и workbench. У gedit есть плагин для git. Графический клиент gitg (git repository viewer). IDE gnome-builder в зависимостях libgit2. Растовский cargo её использует. Через python-pygit2: pagure и gitless (git с (более) человеческим интерфейсом командной строки).

Так у тебя же оффтопик. Там-то какая разница, какое количество зондов у тебя в заду? А зонд MS Visual Studio Community гораздо более приятный, чем зонд Windows 10

Принципиально не пользуюсь десяткой.

Если в инструменте плохо реализована поддержка самой популярной VCS, то это наверное довольно плохой инструмент

Ну-ну. Готов назвать вторую IDE, которая поддерживает git не через парсинг текста из консоли? Под оффтопом это автоматически значит «будет тормозить».

Так в MS же исходный код Windows на Git перевели: Microsoft переводит разработку Windows на Git
Так что думаю, что они за этим зорко следят. Да и Git особо со сменой версий как-то не сильно уж и меняется. А libgit2 вроде конфиг читает, там где всякое поведение git push/git merge в новых версиях изменилось, он это всё подсасывает

https://www.opennet.ru/opennews/art.shtml?num=45978

операция clone выполняется 12 часов, checkout - 3 часа, status - 8 минут, commit - 30 минут

Спасибо, очень удобно. По фен шую создал рабочую ветку, изменил строчку, сразу закомитил (а то вдруг потеряется), сделал pull/push — рабочий день закончился. Красота. Где можно пройти собеседование на такую работу?

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

Таким образом Microsoft через Git пытается пропихнуть всю свою экосистему с зондами (поскольку оно не работает ни на чем, кроме десятого оффтопа) и рекламой сервисов. С последней целью она выпустила VS Code, к слову.

У Git с маловесной libgit2 без зависимостей перспектив довольно много. А вкорячивать Python, тем более древний, это ужасно.

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

Ртуть хоть перешла наконец-то на Python 3 в сборках под Windows?

2.7 во всех релизах. Ну так-то тройка поддерживается, так что вопрос разве что в сборке.

Через python-pygit2: pagure и gitless (git с (более) человеческим интерфейсом командной строки)

Epic. Даешь git на питоне!

И что не так с текстом по ссылке?

И что не так с текстом по ссылке?

Ответили же в треде — ничерта не понятно, если ты не являешься экспертом по git:

Пал один из последних оплотов Mercurial (Hg) (комментарий)

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

Пал один из последних оплотов Mercurial (Hg) (комментарий)

https://git-man-page-generator.lokaltog.net/

Ну вот я себя экспертом по git назвать не могу. Но вроде как мне текст понятен

Готов назвать вторую IDE, которая поддерживает git не через парсинг текста из консоли?

GNOME Builder.

Таким образом Microsoft через Git пытается пропихнуть всю свою экосистему с зондами (поскольку оно не работает ни на чем, кроме десятого оффтопа) и рекламой сервисов. С последней целью она выпустила VS Code, к слову.

Да и флаг им в руки. GVFS они же открыли? Значит неплохо улучшили экосистему Git, не так ли?

2.7 во всех релизах

Я щитаю, это победа. Ничего, что срок поддержки второпитона утёк?

Ну так-то тройка поддерживается, так что вопрос разве что в сборке.

А вот это, я щитаю что дважды победа: Ценой перевода Mercurial на Python 3 может стать шлейф непредвиденных ошибок.

И да, что такое «грязная локальная репа?». Похоже ты суть DCVS тоже не осилил, живешь в мире SVN.

Ртуть вроде как и позиционировалась как SVN, но со вкусом DVCS. Разве нет? Понятно почему тогда многие проекты перешли с SVN на неё, а не стали грызть гранит Git’а.

Ты случаем не ведешь блог? Как-то получилось, что мне очень близок твой контент.

Ну вот я себя экспертом по git назвать не могу. Но вроде как мне текст понятен

И мне понятен. Потому что мне пришлось ознакомиться с tree-ish и индексами git, чтобы хоть как-то читать маны. А теперь представь себе, что в mercurial эдак половины этих фич не существует, поскольку не существует лишней сущности по имени «index».

А то!

>>> Подробности

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

Готов назвать вторую IDE, которая поддерживает git не через парсинг текста из консоли?

GNOME Builder

Gitg предоставляет часть функций git, а GNOME Builder предоставляет часть функций Gitg. В итоге имеем что имеем — огрызок. Так что не засчитываю.

Да и флаг им в руки. GVFS они же открыли? Значит неплохо улучшили экосистему Git, не так ли?

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

А по теме портирования на мак/линь — на самом деле есть еще один проект от MS:
https://github.com/microsoft/scalar
Потому ты прав в смысле «дарят людям больше добра и софта» — они хотят оседлать волну хайпа, когда свою кашу из топора они продали первыми и первыми почили на лаврах.

А вот это, я щитаю что дважды победа: Ценой перевода Mercurial на Python 3 может стать шлейф непредвиденных ошибок

Ждем питона 4, чо. Git/libgit2 еще больше уязвимы к подобному веселью, но тупо заваливая ресурсами их сделали стабильными:

https://github.com/libgit2/libgit2/issues?q=is:issue is:closed

Ртуть вроде как и позиционировалась как SVN, но со вкусом DVCS. Разве нет? Понятно почему тогда многие проекты перешли с SVN на неё, а не стали грызть гранит Git’а

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

Facebook

Так что не засчитываю.

Мне лень искать инфу и смотреть в сорцы популярных IDE на предмет использования ими libgit2. Это ведь тебе нужно, не мне. Отмечу лишь что в репозитории libgit2 есть такое:

libgit2 is used to power Git GUI clients like GitKraken and gmaster

А так как ты ищешь именно GUI к Git’у, а не IDE с libgit2 (иначе ты бы давно уже заюзал студию), то попробуй потыкать эти оболочки.

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

Дружище, они этот проект про который ты глаголил даже назвали не иначе как «VFS for Git», как он может быть вне Git-экосистемы?

Та вроде полноцегная DVCS, как бы. Ну то есть и патчсетами обменяться можно и между своими девайсами пуш/пул и сервер не обязателен. Что еще надо :)

Все долбятся в mq. Потому что ветки - ад как в сраном SVN. Переименование веток осуществляется созданием новой и чере-пиканьем.

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

http://justinhileman.info/article/git-pretty/

Беглый взгляд на блок схему позволяет сделать простой вывод: нет комитов — нет проблем, ты не поломаешь репу несчастного, который от твоей ветки делал производные правки. Есть вариант сравнимой безболезненности — это когда комиты есть, но они неопубликованы. Можно ничего не перебазировать и не удалять, а оставлять на локалхосте (и/или карманном сервере с копией репы).

Реальные проблемы начинаются, когда ветку ты опубликовал, непонятно кто эту ветку использовал, непонятно что с этим делать и что за это будет. В общем случае правило очень простое и логичное: НИКОГДА не удалять и не менять ПУБЛИЧНУЮ ИСТОРИЮ. Опубликовав мусор ты создал проблему, которую потом будешь героически решать. Прежде всего гитоушибленным нужно научиться грамотно вести работу с публичным репозиторием, а потом уже изучать команды и читать маны.

И да, изменение истории — это та самая волшебная фича git, которая при помощи небольшого таланта и везения способна перевести репозиторий в полностью неработоспособное состояние.

Ты никому не поломаншь репу если нет force push и вообще push.

командная строка у гита запутанная

Ровно наоборот это не командной строки проблема. Ну нарисует кто-то интефейс с кнопами пул пуш – окажется, что ничего путного с таким набором не сделаешь. А чтобы сделать, нужно миллион кнопок и теперь с этим невозможно разобраться, и CLI проще ибо поиск автодополнение и гуру на телефоне.

На самом деле гитово устройство не позволяет обходиться более простым интерфейсом. Для простого интерфейса нужно это устройсво радикально упрощать. А поезд уже ушёл.

А кто тебе говорил про публичную историю? Я хочу свою ветку с правками перебазировать на текущий master перед мерджем

Надуманные проблемы.

Ты явно пытаешься использовать rebase неправильно.

В общем случае правило очень простое и логичное: НИКОГДА не удалять и не менять ПУБЛИЧНУЮ ИСТОРИЮ.

Если это официальный реп, то конечно. Если личный, то я вообще могу его грохнуть в любой момент, не то что такие мелочи, как переписывание истории. На то он и личный.

Мне лень искать инфу и смотреть в сорцы популярных IDE на предмет использования ими libgit2. Это ведь тебе нужно, не мне

В данном случае я отвечал на:

Если в инструменте плохо реализована поддержка самой популярной VCS, то это наверное довольно плохой инструмент

А подержка Git — это вполне реально существующая проблема. Ну а так: платные программы, которые ты упомянул — это вполне себе годнота, не спорю.

Дружище, они этот проект про который ты глаголил даже назвали не иначе как «VFS for Git», как он может быть вне Git-экосистемы?

Ты можешь почитать архитектуру GVFS. Там изменяются все или почти все команды git, перехватывается доступ к файловой системе, и серверная репа тоже обвязана специальным сервисом. Прямо все наглухо перехвачено и эмулировано, только рожки да ножки остались, то есть, названия команд и их вывод. Это еще дальше от git, чем работать с репой в браузере через git.js, синхронизируясь с сервером на Ruby.

Ну нарисует кто-то интефейс с кнопами пул пуш

[trollmode]
Уже нарисовали и на ЛОРе опубликовали: Вышла EasyGG 0.1 — новая графическая оболочка для Git

Радуемся качеству новостей на ресурсе!
[/trollmode]

Помним! Ценим!

А подержка Git — это вполне реально существующая проблема.

Я пока не совсем понимаю, что у тебя за проблемы со спавном Git-процессов? Ты работаешь над такими огромными кодовыми базами, что они жрут память/CPU/DISK IO как не в себя? Или же у тебя слабая машина, где дорог каждый МБ оперативки?

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

С твоих слов это можно назвать «реализацией» Git от Microsoft, верно? А разные реализации одного и того же ПО всё равно входят в общую экосистему, пусть даже что-то общее между ними будет и не совместимо.

Вот если бы они сделали всё это но для TFS, тогда бы твоя точка зрения была верна. А так они выбрали Git и пофиг какие цели у них были – корыстные (прокатиться на волне Git-хайпа) или наивно-благосклонные (дать программистам Windows более удобную реализацию Git).

Ты никому не поломаншь репу если нет force push и вообще push

Хорошо, используй rebase/mqueue. Но ты же сам понимаешь, что это ни разу не простые фичи и их нельзя давать в руки человеку, который не может изменить строчку в конфиге. Это сложные инструменты для сложных ситуаций, вроде необходимости избирательно применять к произвольным ревизиями пакеты накопившихся локально правок.

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

Устранение индекса заметно упрощает работу. Даже консольные инструменты позволяют организовывать работу без индекса, но ретрограды будет до последнего цепляться за традиции.

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

Ну, и зачем тебе нужна была ветка? А через stash я могу добавлять/удалять правки из рабочей копии любой ревизии. Или тебе нужно обязательно, как Егору Бугаенко, каждую минуту выдавать по комиту, и потому это пушить в репу на гитхабе — вот, мол, я у мамки продуктивный программист? В любой более-менее солидной команде правки не вываливаются с бухты-барахты, это обычно конкретные готовые фичи, про которые знают конкретные люди: им не нужны твои «начал делать», «тут поправил», «здесь поправил» — им нужно только «фичанейм v1.0 релизнута» и «фичанейм v1.1 релизнута». А то и вовсе патчи, проходящие ревью, и попадащие в репу только будучи подписанные кровью.

Ну, и зачем тебе нужна была ветка?

Для работы над фичей, очевидно. Или мне в zip-архивах историю хранить, как в благословенном 1995-м?

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

Это пойдёт в главный реп. Какое отношение моя собственная история правок имеет к истории проекта? В большинстве случаев – никакого.

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

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

Мне нужно, чтобы моя работа была сохранена в надежном месте и была доступна с нескольких машин. А не так, что у «я у мамы программиста» отхлебнул ноут, и неделя работы ушла в /dev/null.

Мне в ходе подготовки фичи тесты в CI со сборкой под 4 операционные системы откуда гонять – на локалхосте развёртывать их? И потом прилагать скриношты с подписью «мамой кланус!»? Или так и отправлять неоттестированными на ревью?

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

Я пока не совсем понимаю, что у тебя за проблемы со спавном Git-процессов? Ты работаешь над такими огромными кодовыми базами, что они жрут память/CPU/DISK IO как не в себя? Или же у тебя слабая машина, где дорог каждый МБ оперативки?

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

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

Как думаю я: «я просто заберу правки с сервера и продолжу работать». Всё. ВСЁ. Ничего не нужно создавать, ничего не нужно ребейзить, никаких веток не нужно создавать. Возникли конфликты — решил, а если передумал и отказался от чужих правок — откатился. Просто и по делу, без лишних сущностей.

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

С твоих слов это можно назвать «реализацией» Git от Microsoft, верно? А разные реализации одного и того же ПО всё равно входят в общую экосистему, пусть даже что-то общее между ними будет и не совместимо

Хорошо, черт с тобой, входят в одну экосистему, потому что что-то там у них есть общее. Только не надо говорить про «Microsoft переводит разработку Windows на Git» — потому что переводит не на Git, а на GVFS.

Для работы над фичей, очевидно. Или мне в zip-архивах историю хранить, как в благословенном 1995-м?

Какую историю? Ее никто не будет читать, даже ты. История — это откат правок в редакторе: Ctrl-Z — предыдущая ревизия, Ctrl-Y — следующая. Вот тебе и репозиторий.

Это пойдёт в главный реп. Какое отношение моя собственная история правок имеет к истории проекта? В большинстве случаев – никакого.
Заводится ветка под фичу, в ней идёт работа. Потом коммиты схлопываются, патч перебазируется на актуальный мастер и делается пулл реквест или отправка на ревью или что там у вас будет в workflow по вкусу

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

Мне нужно, чтобы моя работа была сохранена в надежном месте и была доступна с нескольких машин. А не так, что у «я у мамы программиста» отхлебнул ноут, и неделя работы ушла в /dev/null

Есть самые разные варианты бэкапов и синхронизации, с минимальными усилиями со стороны кодера. А «удобство» git сравнится разве что с ручным/полуавтоматическим бэкапом файла патча.

Мне в ходе подготовки фичи тесты в CI со сборкой под 4 операционные системы откуда гонять – на локалхосте развёртывать их?

Вот это мне вообще взрывает моск. С каких пор вообще мир решил, что CI = Git? Да хоть тарбол пожатый заливай на сервер тестирования — какая разница?

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

Начать надо с того, зачем тебе тут rebase, а не обычный merge с историей. А то вообще не понятно, чего ты хочешь добиться.

Как думаю я: «я просто заберу правки с сервера и продолжу работать». Всё. ВСЁ.

Забираешь правки и мерджишь. ВСЁ.

Как думаю я: «я просто заберу правки с сервера и продолжу работать». Всё. ВСЁ.

Эмм. В git спокойно можно сделать rebase origin/веткаНаСервере в любой момент если у тебя autostash включен. Никаких лишних команд. Если твой origin/веткаНаСервере протух, можно сделать git fetch перед этим. Но никаких новых веток при этом не создаётся.

Как думаю я: «я просто заберу правки с сервера и продолжу работать». Всё. ВСЁ. Ничего не нужно создавать, ничего не нужно ребейзить, никаких веток не нужно создавать. Возникли конфликты — решил, а если передумал и отказался от чужих правок — откатился. Просто и по делу, без лишних сущностей.

А если тебе во время твоей работы над фичей «A» звонит начальник и, сука, требует быстро и решительно запилить фичу «B»? А коль ты откажешься её тут же начать делать, то будешь на следующей день слушать в трубке телефона «мы вам перезвоним» от миленьких и приветливых девочек.

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

Начать надо с того, зачем тебе тут rebase, а не обычный merge с историей. А то вообще не понятно, чего ты хочешь добиться

Сорта говна. Git в принципе не умеет не сношать мозги, поскольку не умеет сохранять незакомиченные правки. Ретрограды у руля разработки Git говоря «это фича, которую вы хотел всегда», а на вопрос «как мне работать без комитов» говорят «вам это не нужно было». А я отвечаю: мне не нужен был Git, работа с patch/diff/rsync меня устраивала.

В git спокойно можно сделать rebase origin/веткаНаСервере в любой момент если у тебя autostash включен

Да, это самое близкое к тому workflow, которое я описываю. Я не пробовал так пользоваться Git, потому не могу сказать, насколько это удобно/безопасно.

А если тебе во время твоей работы над фичей «A» звонит начальник и, сука, требует быстро и решительно запилить фичу «B»?
Ветки позволяют разрулить такую ситуацию без репутационных потерь, а вот твой подход с грязной репой грозит обернуться грязными штанами

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

Ну. autostash точно так же выкинет на тебя конфликты если они будут. Точно так же можно будет либо починить их, либо отменить rebase. Если станет совсем плохо — всегда остаётся вариант посмотреть хэш хорошего коммита в git reflog и сделать git reset до него.

Какую историю? Ее никто не будет читать, даже ты.

Ты мне будешь рассказывать, что мне что-то ненужно? Типичный ЛОР, ничего нового.

МНЕ нужна моя история. Для меня это достаточное обоснование, чтобы её хранить.

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

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

А если мне нужно протестировать ДВЕ разные реализации с учётом скорости, тестов и потенциальных подводных камней? А если нужно привлечь еще кого-то для оценки алгоритма?

История — это откат правок в редакторе: Ctrl-Z — предыдущая ревизия, Ctrl-Y — следующая. Вот тебе и репозиторий.

История, которая сбрасывается при:

• Закрытии редактора.
• Закрытии документа.
• Случайном нажатии любой алфавитно-цифровой клавиши.
• Падении редактора.
• Зависании системы.

Классная история.

Есть самые разные варианты бэкапов и синхронизации, с минимальными усилиями со стороны кодера. А «удобство» git сравнится разве что с ручным/полуавтоматическим бэкапом файла патча.

Самое минимальное усилие – это git push. У меня уже настроен git. Я уже умею с ним работать. Я не собираюсь забивать себе голову тем, как работать с очередными подпорками, если уже развёрнут инструмент, решающий задачу. Руководство проекта тоже не станет.

Вот это мне вообще взрывает моск. С каких пор вообще мир решил, что CI = Git? Да хоть тарбол пожатый заливай на сервер тестирования — какая разница?

С того, что это удобно. С того, что есть унифицированные механизмы. CI-ферме всё равно, чьи тесты гонять: из мастера или из рабочих веток. Какие нахрен тарболы я должен туда заливать? В интерфейсе CI эти тарболы куда обратно указывать должны, на что?

Тебе не нужны ветки, тебе не нужны комиты — это всё мусор, который нужно будет выносить.

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

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

Достаточно включить мозг: КУДА система КОНТРОЛЯ ВЕРСИЙ должна сохранять правки?

Система КОНТРОЛЯ ВЕРСИЙ сохраняет правки в виде, собственно, ВЕРСИЙ, то есть коммитов.

Это её предназначение.

а на вопрос «как мне работать без комитов» говорят «вам это не нужно было». А я отвечаю: мне не нужен был Git, работа с patch/diff/rsync меня устраивала.

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

Ретрограды у руля разработки Git говоря «это фича, которую вы хотел всегда»,

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

Я думал, тут будут какие-то реальные аргументы за hg, а тут просто нытьё неосилятора мануала.

Устранение индекса заметно упрощает работу

Или делают систему неприемлемой. Ибо его зачем-то придумывали же.

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

Скачал AppImage для Guitar, GitAhead (по соглашению собирает какие данные об использовании), GitQlient - все еле шевелятся с чтением дерева gentoo portage. Последний ничего кроме окошка не показал после выбора репозитория на диске.

GitKraken Free непонятно чем несколько минут занимается при первом запуске. Я так и не дождался после пары минут пока он закончит «opening gitkraken git gui».

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

история снова ненужна

Я мог позавчера пофиксить сегфолт в фиче, а после вчерашней правки у меня вылазит сегфолт на том же месте. Мне нужно точно знать, что именно я правил вчера и позавчера. Внёс я вчера снова тот же баг?

на каждый пофикшенный баг отдельный тест пишется и остается гоняться в ci навеки вечные.

Какой тикет, если это рабочий бранч для фичи?

Сегодня внесли, завтра пофиксили, послезавира снова сломали. Через два дня половину написанного кода выкинули, потому что руководство сократило фичу вдвое.

Такое ощущение, что тут некоторые код только на скриншотах видели.

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

А у вас веселая организация разработки. Как тебе другая, более прагматичная постановка: мы полгода назад сделали релиз, в нем всплыл сегфолт, какая из правок привела к нему, или может сделанный полгода «фикс был не полным»? Ты вот смеешься, а у меня есть опыт охоты на баг годами. Большинство писателей «чего-то сложнее хелловорлда» меняют проект раз в несколько месяцев и с такой проблемой просто не сталкиваются, потому Git им в чем-то там помог — более старые правки в нем они не смотрят, потому что история правок команды, как правило, представляет собой спагетти. Да и какой смысл пытаться откатиться на ревизии, большая часть из которых просто неработоспособны? Или ты каждые 10-20 минут делаешь комит и тестируешь его на CI/CD?

А если мне нужно протестировать ДВЕ разные реализации с учётом скорости, тестов и потенциальных подводных камней? А если нужно привлечь еще кого-то для оценки алгоритма?

Вот для этого нужны ветки/патчи. Но тебе не нужно делать это каждый день.

История, которая сбрасывается при:
Закрытии редактора.
...
Классная история

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

Самое минимальное усилие – это git push

А комиты у тебя автоматически по таймеру делаются или по сохранению файлов в редакторе?

У меня уже настроен git. Я уже умею с ним работать. Я не собираюсь забивать себе голову тем, как работать с очередными подпорками, если уже развёрнут инструмент, решающий задачу

«Этот костыль меня пока что устраивает».

В интерфейсе CI эти тарболы куда обратно указывать должны, на что?

На тарбол же ж. Точно так же, как в CI указывают на ревизию в Git.

Достаточно включить мозг: КУДА система КОНТРОЛЯ ВЕРСИЙ должна сохранять правки?
Система КОНТРОЛЯ ВЕРСИЙ сохраняет правки в виде, собственно, ВЕРСИЙ, то есть коммитов

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

Более того, при работе со слабой коммуникацией, аля open-source community, такая ситуация возникает при работе даже в одной формальной ветке проекта.

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

Индекс — это фича одного git, придуманная Торвальдсом, и больше ни в одном VCS не присутствующая. Гитовые утята в 2020 году, действительно, не понимают, как может существовать VCS без индекса.

Просто, Торвальдс любит, когда можно пердолиться со внутренностями системы. Да, в BitKeeper и Mercurial есть внутренняя сущность, предсталвяющая собой правки, которые будут превращены в комиты, но они не светят эту внутреннюю сущность пользователю. Также они не предоставляют возможность перекраивать историю правок, поскольку это перечеркивает весь смысл VCS. Можно удалять ветку, можно удалять последний комит, но нельзя переписывать историю ветки, нельзя менять сообщения в комитах, нельзя менять первый комит в ветке — как это позволяет делать Git.