• Choose a category
• All
• Classic-Fiction

diff -r c88942a2377a -r 1934c63ed3c5 other.c

--- /dev/null Thu Jan 01 00:00:00 1970 +0000

+++ b/other.c Tue May 05 06:44:41 2009 +0000

@@ -0,0 +1,1 @@

+double u;

Useful Things to Know About

There are a number of aspects of MQ usage that don’t fit tidily into sections of their own, but that are good to know. Here they are, in one place.

Normally, when you qpop a patch and qpush it again, the changeset that represents the patch after the pop/push will have a different identity from the changeset that represented the hash beforehand. See qpush—Push Patches onto the Stack for information as to why this is.

It’s not a good idea to hg merge changes from another branch with a patch changeset, at least if you want to maintain the “patchiness” of that changeset and changesets below it on the patch stack. If you try to do this, it will appear to succeed, but MQ will become confused.

Managing Patches in a Repository

Because MQ’s .hg/patches directory resides outside a Mercurial repository’s working directory, the “underlying” Mercurial repository knows nothing about the management or presence of patches.

This presents the interesting possibility of managing the contents of the patch directory as a Mercurial repository in its own right. This can be a useful way to work. For example, you can work on a patch for a while, qrefresh it, then hg commit the current state of the patch. This lets you “roll back” to that version of the patch later on.

You can then share different versions of the same patch stack among multiple underlying repositories. I use this when I am developing a Linux kernel feature. I have a pristine copy of my kernel sources for each of several CPU architectures, and a cloned repository under each that contains the patches I am working on. When I want to test a change on a different architecture, I push my current patches to the patch repository associated with that kernel tree, pop and push all of my patches, and build and test that kernel.

Managing patches in a repository makes it possible for multiple developers to work on the same patch series without colliding with each other, all on top of an underlying source base that they may or may not control.

MQ Support for Patch Repositories

MQ helps you to work with the .hg/patches directory as a repository; when you prepare a repository for working with patches using qinit, you can pass the hg -c option to create the .hg/patches directory as a Mercurial repository.

* * *

Note

If you forget to use the hg -c option, you can simply go into the .hg/patches directory at any time and run hg init. Don’t forget to add an entry for the status file to the .hgignore file, though (hg qinit hg -c does this for you automatically); you really don’t want to manage the status file.

* * *

As a convenience, if MQ notices that the .hg/patches directory is a repository, it will automatically hg add every patch that you create and import.

MQ provides a shortcut command, qcommit, that runs hg commit in the .hg/patches directory. This saves some bothersome typing.

Finally, as a convenience to manage the patch directory, you can define the alias mq on Unix systems. For example, on Linux systems using the bash shell, you can include the following snippet in your ~/.bashrc.

alias mq=`hg -R $(hg root)/.hg/patches'

You can then issue commands of the form mq pull from the main repository.

A Few Things to Watch Out For

MQ’s support for working with a repository full of patches is limited in a few small respects.

MQ cannot automatically detect changes that you make to the patch directory. If you hg pull, manually edit, or hg update changes to patches or the series file, you will have to hg qpop hg -a and then hg qpush hg -a in the underlying repository to see those changes show up there. If you forget to do this, you can confuse MQ’s idea of which patches are applied.

Third-Party Tools for Working with Patches

Once you’ve been working with patches for a while, you’ll find yourself hungry for tools that