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

Question

I am used to Mercurial mq extension to maintain a set of custom patches over the upstream. They can be published as a separate repository aside from the upstream. Now in git

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.