это способ управлять набором патчей, которые еще не добавлены в основную линию; можно быстро применить (qpush) и отменить (qpop), изменить порядок и изменить их. Сами патчи управляются как простые файлы. Когда они применяются, вся очередь исправлений выглядит как ветвь для Mercurial, когда они не применяются, хранилище выглядит так, как если бы их не было. Хорошо поддерживать частные настройки, разрабатывать сложные функции (например, с rebase) или экспериментировать. StGit и Guilt, кажется, делают то же самое для Git.
вык к ртутиmq расширение поддерживать набор пользовательских патчей поверх апстрима. Они могут быть опубликованы в виде отдельного репозитория, кроме вышестоящего. Теперь в Git я использую частные ветви иrebaseи это работает хорошо, пока я не хочу поделиться своими патчами с кем-то еще.
В Mercurial очередь исправлений является независимым хранилищем и может публиковаться как обычно. Bitbucket даже предлагает функцию очереди исправлений, чтобы связать ее с родительским репозиторием. В Git, если я публикую частную ветку с моими патчами, я теряю возможность перебазировать их больше (если не нарушаю слияния), но патчи нужно время от времени обновлять.
Изеще один вопрос Я обнаружил, что в мире Git StGit предлагается как эквивалент дляmq, Это похоже на использованиеmq, но как мне опубликовать очередь патчей с StGit?
(stg publish похоже, что он создан для создания новой ветки, удобной для слияния, а не для публикации самих патчей.
Каковы другие подходы к публикации очередей исправлений в Git?