20

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?

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
sastanin
  • 40,473
  • 13
  • 103
  • 130
  • 6
    Is there some reason you can't simply publish the branch with the understanding that it's not finalized and may be rebased further? – Cascabel Feb 16 '11 at 13:37
  • Well, it will break merges for anyone who tries to pull/fetch from it, right? Then what's the point of publishing it as a version-controlled repo, if it doesn't allow to smoothly upgrade to the last version? – sastanin Feb 16 '11 at 14:07
  • 2
    @jetxee: That's the point: if it can be rebased further, you *don't* merge it into any important branches. You fetch and work on it in isolation. – Cascabel Feb 16 '11 at 14:12
  • 3
    But the point of publishing the patches is to let someone else using them _before_ they are merged into the mainline (or also if they are never merged there). Well, I'll consider a "perpetually rebasing branch" as a Git approach instead of patch-management. – sastanin Feb 16 '11 at 14:16
  • Also, stgit is essentially just a wrapper for some ref management and rebasing. If you really wanted to, you could publish `branch` and `branch.stgit` (I think that's what it calls it) - but still, there has to be an understanding that it shouldn't be merged into any real branches. – Cascabel Feb 16 '11 at 14:22
  • 2
    @jexee: Ah. In my mind, the purpose of publishing the patches is to let others work on them until they are ready to be merged. Perpetually rebasing isn't quite as scary as it sounds, though - if there's an end user who's just using the whole patch queue, they don't really have to rebase. They can just continually reset to the updated patch queue. – Cascabel Feb 16 '11 at 14:24
  • Why do you need to rebase at all? Can't you just periodically merge in the upstream? If you use merge instead of rebase, publishing your branch is suddenly not a problem. – Walter Mundt Feb 19 '11 at 20:45
  • 2
    @Walter I'd like to maintain a patch, which can be cleanly applied to the mainstream. I am not sure if the patch will ever be accepted there. Locally I do it with `rebase`. I see that avoiding `rebase` at all, publishing a public branch as usual, with ongoing merges is the most reliable solution. – sastanin Feb 21 '11 at 09:44

4 Answers4

8

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.

Luke Girvin
  • 13,221
  • 9
  • 64
  • 84
sastanin
  • 40,473
  • 13
  • 103
  • 130
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.

ctuffli
  • 3,559
  • 4
  • 31
  • 43
  • Git-series is made for the Linux/Git Project workflow of publishing one or many versions of patch series to mailing lists for review. A patch queue sounds like a different use-case, although maybe it could work well for that use-case too (I don’t know). – Guildenstern May 01 '21 at 19:47
1

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.

Lars Noschinski
  • 3,667
  • 16
  • 29
-2

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.

Rawler
  • 1,480
  • 1
  • 11
  • 23
  • 1
    It allows to put patches under version control in a _separate_ repository, so the main repository is unaffected and the repository with patches can be published independently on its own. So it doesn't have the same problems as `git rebase`, because it doesn't rewrite the history (in fact, it doesn't change it at all). – sastanin Feb 21 '11 at 09:38
  • @jetxee, ok so it's a way to annotate the "unstable" branch, warning that it is unstable and rebasing? Sounds like a good thing to have. – Rawler Feb 21 '11 at 13:27
  • 1
    it's a way to manage a set of patches which are not yet committed to the main line; it's possible to quickly apply (qpush) and unapply (qpop), reorder and change them. The patches themselves are managed as simple files. When they are applied the whole queue of patches looks like a branch to the mercurial, when they are not applied the repository looks like if they did not exist. It's good to maintain private customizations, develop complex features (like with rebase) or experimenting. StGit and Guilt seem to do the same for Git. – sastanin Feb 21 '11 at 18:05