4

I am using Mercurial Queues on a repository, and have placed those patches in a patch repository. Another contributor has cloned my patch queue and made changes of their own. I would now like to merge their changes in my local patch repository.

I am trying to find a good workflow for performing this merge that

  • reflects the contributor's changesets in the history of the patch repository
  • invokes the user's merge tool in case of conflicts

Initially, I just tried to merge the patches directly. This is okay in very simple cases, but does not work well when many things have changed, since the patches depend on line number context which doesn't seem like something I should have to worry about adjusting myself. Overall, I find examining a 3 way diff of patches to be too complex.

Is there a better way?

user2864740
  • 60,010
  • 15
  • 145
  • 220
J. Ryan Stinnett
  • 801
  • 8
  • 13

2 Answers2

1

There's no great way to handle this. What I'd probably end up doing is creating two clones, and qfinishing your patch in one and the contributers patch in the other. That that point you'll have repos with each separate patch's net effect applied. Then you hg pull one of those clones into the other, and hg merge will let you use your graphical tools to merge the results of the patches -- and the only differences should be the differences in your patches. At this point, ideally, you'll be able to qimport the merge changeset, but you can't do that, so you have to 'hg diff -r tip-1 -r tip' to get a new diff that is the difference between before-everything-started and after-merging-the-two-results. You then 'qimport` that diff and commit it to your patch queue repo with a note saying where it came from.

Decidedly sub-optimal, but the best I can come up with. I'd love to hear a better solution.

Ry4an Brase
  • 78,112
  • 7
  • 148
  • 169
  • That's basically the only plan that occurred to me as well, but I was hoping others might have a better idea. This experience got me interested in using [pbranch](http://arrenbrecht.ch/mercurial/pbranch/index.htm) instead of MQ, as it seems to offer better support for this flow, since the patches are just regular branches. – J. Ryan Stinnett Jan 12 '11 at 21:28
  • I just use real commits rather than patches if I'm working with someone else on changes. Even if we never push from that clone back to "upstream" it provides us a place to work and good merge tools, and ease if pulling in changes from "upstream" and then we can import a 'hg diff' later to send upstream. – Ry4an Brase Jan 13 '11 at 15:41
0

I'm afraid that there is no automated way to merge patches.

However, one "trick" you can use is to create new patches instead of editing/refreshing existing patches when you need to amend them. When you all agree on the right way to do things, then hg qfold the patches.

That way you wont be stepping on each others toes as much since you create new patches.

Martin Geisler
  • 72,968
  • 25
  • 171
  • 229