Create patch for series of existing changesets that were created without using MQ?

Question

I've recently started to work on an open source project which uses Mercurial. I'm a new user to Mercurial, so I read the HG book and started working. My goal was to write code and always pull and merge changes from the upstream so I can stay up-to-date. The area that I am working on is also under heavy development by others so I do want to merge my changes after a long period of time. I cloned a repo. So, my workflow is like this:

1. I created a bookmark mybook

2. hg up mybook

3. Write code

3.1 hg commit -m 'new functions'

4. hg up default

5. hg pull

6. hg update

7. hg up mybook

8. hg merge default

9. Go to step 3.

In my mind this is the simplest workflow that allows me to stay up-to-date. I also have only one HEAD because I always merge.

Since I am not a contributor yet, I am not allowed to push changes to remote repo.

Recently I wanted to show my work to a project lead and he said send me a patch. And this is where I am stuck. hg out shows 10 changesets. First of which appeard already a month ago. They're numbers are 3341, 3342, 3345, 3346, 3349, 3356, 3360, 3365, 3366, 3368. The changeset numer 3368 is the tip.

I've recently read the chapter about the MQ extension. And this extensions seems to be what I need. But the problem is that I wrote code without using the MQ extension.

So, how can I make use of the MQ extension on already created changesets so that I can make a patch to send to the project lead so that he can apply it and see my changes?

I've just issued hg qinit. What's next? Issueing hg qimport -r 3341 gives

abort: revision 3341 has unmanaged children

Reading the book and googling further does not help me. I need an advice.

PS I've tried not using hg and MQ at all: simple diff -urN old/ new/ but I want understand how to do it with the MQ.

Thank you.

Answer 1

Yeah, don't use MQ. It's a parallel system, meant for keeping things out of the history, and more important you don't need it.

You were asked for "a patch", not a complete history of your work, so I would recommend sending it in the form of a single before-after diff. hg export will give you a series of diffs, for all the work you've done, including the merges. I find it's far easier to read and review a single diff (before applying it). But instead of plain diff, use hg diff which knows to only look at tracked files, and has a number of other nice features (including the --git option, which provides richer metadata). This should do it:

hg up mybook
hg diff --git -r default > mywork.patch

Before sending it off, do an hg up default and apply the patch to check that it works without conflicts. And mention to the recipient which version of default you are patching against.

Edit: As you can read in the comments, @LazyBadger is a fan of the step-by-step patch generated by export. I prefer the single-step patch since my history is usually TMI: Nobody cares about all the times I added a forgotten file, or noticed a bug too late and fixed in in the next commit, etc. Take your pick.