mq vs stgit

Очень интересует мнение tailgunner.

Я не очень понимаю как mq тебе поможет в данной проблеме.

> Недавно хотел сбежать на hg, потому что один проект совершенно не управлялся гитом ([git] Параллельные ветки), а mq выглядело (по туториалу, по крайней мере) решением проблем.

А как stgit справится с этой проблемой? Он случаем там не переписывает историю также, как это делал бы обычный rebase?

Я не очень понимаю как mq тебе поможет в данной проблеме.

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

То есть, сейчас работа, упрощенно, происходит так:

master> hack...
master> git commit

py3-stgit> stg rebase
py3-stgit> fix py3 incompatibilities...
py3-stgit> stg refresh
py3-stgit> stg publish py3

Он случаем там не переписывает историю также, как это делал бы обычный rebase?

Под него у меня есть третья ветка (не-public). В принципе, на отдельной ветке можно было бы и rebase'ом пользоваться, но в свое время это показалось тоже достаточно трудоемким процессом.

«py3-stgit> stg rebase»

Если ручками нужно делать rebase, то не пойму чем это отличается от обычного git rebase.

то не пойму чем это отличается от обычного git rebase.

Потом при мерже не надо указывать стратегию recursive theirs. Плюс удобное редактирование отдельных патчей.

Я git использую только в рамках git {pull,diff,checkout}, так что stgit не пользовался. Вполне возможно, что он хорош, но, насколько я знаю, вынужденные переселенцы с mq используют guilt.

guilt

Мне не понравилось, что он слишком сбоку приделан. Тупо файлы с патчами. В stgit это полноценные объекты репозитория. Может в guilt удобнее сделан обмен патчами, это достаточно критичная вещь при разработке крупных проектов.

>> guilt

Мне не понравилось, что он слишком сбоку приделан. Тупо файлы с патчами.

Думаю, что там, в традиции mq, наложенные патчи являются коммитами. А то, что патч лежит как файл, и его можно редактировать обычным редактором - очень удобно.