Entry tags:
современная чёрная магия
Одно из мест обитания сверхестественных существ, это git. В наш быт вошли заклинания призыва демонов, которые быстро делают то, что нужно, когда нужно. У некоторых неопытных пользователей гита это может вызвать иллюзию полного контроля над демонами, но это не так.
Достаточно сделать git stash pop не в том бранче, чтобы демоны вышли из под контроля. Наивные пользователи могут пытаться использовать всё более мрачные заклинания, но они будут приводить к всё большей и большей потери контроля над демонами.
Единственным решением в этой ситуации (кроме "ничего не делать и вызвать git-экзорциста") может быть только планомерное закрытие ошиьбочных порталов в git, чтобы перевести ситуацию из аварийной в хроническую. Для этого очень важно знать, какие именно порталы открыты. Например, в случае с неудачным git stash pop, ключевым инсайтом должно быть то, что апокалипсис происходит в stage/work, а history и stash (! это важно!) не затронуты. Таким образом, достаточно всего лишь аннигилировать stage и work, сохранив нетронутой history и stage. Ошибочные попытки общения с демонами истории могут лишь эскалировать ситуацию до развёрстывания малых врат Гита. А если после этого сделать push --force, то это откроет и Большие Врата Гита, и как известно, в мире есть всего 3 человека (вместе образующие 1.3 человека, если считать по органам), способные восстановить мир после открытия Больших Врат Гита.
Ряд встроенных защит от особо опасных демонических проявлений позволяет избежать усложнённой ситуации (когда нужно спасать локальные изменения - stash apply отказывается открываться, если они есть). Я, правда, не знаю, что происходит, если есть staged. Возможно, необратимая гибель staged.
Upd: В моём случае проблема того, что я писал не в том бранче (а изменений много, и они хорошие) осталась, но мне удалось локализовать демонические проблемы на том, что у меня не проходит cherry-pick из одного бранча в другой, а это весьма комфортная ситуация (по сравнению с малым гитопокалипсисом сломанного stash pop).
Достаточно сделать git stash pop не в том бранче, чтобы демоны вышли из под контроля. Наивные пользователи могут пытаться использовать всё более мрачные заклинания, но они будут приводить к всё большей и большей потери контроля над демонами.
Единственным решением в этой ситуации (кроме "ничего не делать и вызвать git-экзорциста") может быть только планомерное закрытие ошиьбочных порталов в git, чтобы перевести ситуацию из аварийной в хроническую. Для этого очень важно знать, какие именно порталы открыты. Например, в случае с неудачным git stash pop, ключевым инсайтом должно быть то, что апокалипсис происходит в stage/work, а history и stash (! это важно!) не затронуты. Таким образом, достаточно всего лишь аннигилировать stage и work, сохранив нетронутой history и stage. Ошибочные попытки общения с демонами истории могут лишь эскалировать ситуацию до развёрстывания малых врат Гита. А если после этого сделать push --force, то это откроет и Большие Врата Гита, и как известно, в мире есть всего 3 человека (вместе образующие 1.3 человека, если считать по органам), способные восстановить мир после открытия Больших Врат Гита.
Ряд встроенных защит от особо опасных демонических проявлений позволяет избежать усложнённой ситуации (когда нужно спасать локальные изменения - stash apply отказывается открываться, если они есть). Я, правда, не знаю, что происходит, если есть staged. Возможно, необратимая гибель staged.
Upd: В моём случае проблема того, что я писал не в том бранче (а изменений много, и они хорошие) осталась, но мне удалось локализовать демонические проблемы на том, что у меня не проходит cherry-pick из одного бранча в другой, а это весьма комфортная ситуация (по сравнению с малым гитопокалипсисом сломанного stash pop).

no subject
no subject
Спасибо, не знал.
no subject
Неопытному пользователю нужно как можно раньше увидеть
gitkили эквивалент. Возможность наблюдать глазами эффект всех кастуемых заклинаний быстро переводит магию в категорию науки.no subject
И как созерцание gitk поможет понять что произошло во время неудачного git stash pop?
no subject
Ну, как минимум, оно показывает, что целевая ветка никуда не сдвинулась, новых коммитов нет, неудачно наложенный стэш не дропнулся. А то ещё и можно заметить, что целевая ветка не та, на которую предполагалось. И конфликты будет видно.
no subject
Это в каком месте в gitk видны стеши?
no subject
Ну я даже не знаю, как на этот вопрос отвечать. Во всех?
no subject
О, я не знал про редактирование view. В целом, я эту штуку в голове не в таком виде представляю, как gitk показывает.
Алсо, мой промах с бранчем был неисправим ничем, даже gitk, потому что я не в том бранче код писал, то есть его надо будет либо адаптировать под соседний бранч, либо перепиливать весь мердж на набор осмысленных патчей.
no subject
А вот в голове как раз полезно представлять именно в таком виде. Сначала граф коммитов, потом в каждом коммите его диффы с разбивкой по файлам.
Код, написанный не в той, но достаточно похожей ветке, исправляется так: коммитим его во временный коммит, ребейсим/черрипикаем на правильную целевую ветку, во время ребейса/черрипика резолвим конфликты. Ну или, что технически то же самое: стэшим, переключаем ветку, применяем стэш, резолвим конфликты, дропаем стэш.
Код, написанный не в той и совсем непохожей ветке, исправляется
git reset --hard’ом на старой ветке и написанием заново в целевой, да.no subject
Ну вот я не считаю так. Почему? Потому что визуализация gitk - для песочниц или карманных репозиториев. Почему?
git branch|wc -l 126
В моей картинке в голове всё менее плоское. Я не обязан в голове бороться за планарность графа. gitk вынужден либо бороться, либо пересекаться.
Хронологические отношения между коммитами важны не всегда.
Я всё равно трекаю в голове cherry-pick с доредактированием, а gitk уже не может.
Хотя основное, это уравнивание бранчей. Нет, я не считаю master равным остальным, и для меня история master всегда приоритетна. Остальные от него бранчуются, причём в неравноправном состоянии.
Появление git vendor сносит крышу gitk (либо я не могу понять его визуализацию).