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

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 I use private branches and rebase, and it works well until I want to share my patches with someone else.

In Mercurial the patch queue is an independent repository, and can be published as usual. Bitbucket even offers a patch queue feature to link it to the parent repository. In Git, if I publish a private branch with my patches, I lose the ability to rebase them anymore (unless I break merges), yet the patches need to be updated from time to time.

From another SO question I found, that in the Git world StGit is proposed as an equivalent for mq. It is similar in use to mq, but how do I publish a patch queue with StGit?

(stg publish seems to be indended to create a开发者_开发知识库 just a new “merge friendly” branch, not to publish the patches themselves)

What are other approaches to publish patch queues in Git?

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.