What's the Git approach to publish a patch queue?

╄→гoц情女王★ 提交于 2019-11-30 06:11:32
sastanin

To summarize the answers and comments. With git there are two approaches to publish small custom modifications over the remote upstream:

  • forget rebase, publish a branch and new merges as necessary
  • declare that a branch is rebasing, just rebase and publish (pro: clean history, contra: can be a pain to be used continuously by someone else, example: linux-next)

So far the pure patch queue workflow doesn't seem to be doable with git, but guilt seems to be be very close to mq, even names of the commands. It doesn't allow for a version-controlled (and publishable) patch queue.

Considering the comments given, it seems an approach more or less equivalent to Mercurial's mq would be using guilt. Unlike mq, guilt does not directly provide an interface for a "patch repository", but you could turn the .git/patches/<branch> into a .git repository manually.

There is a git extension called git-series which uses git to maintain a versioned patch queue. It allows similar functionality to mq in that you can maintain multiple series (equivalent to multiple hg queues), refactor patches based on feedback, and commit the series to git. It's the closest to mq, but is different enough that you should expect some foot shooting.

AFAICT from the provided link about Mq, it has about the same publish problems as git rebase?

All-in-all I think publishing your branch, with the warning that it is a rebasing branch is your best option. For example, that is how the linux-next branch is maintained.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!