diff --git a/committing.rst b/committing.rst
--- a/committing.rst
+++ b/committing.rst
@@ -364,56 +364,34 @@
 Python version.
 
 
-Porting Within a Major Version
-''''''''''''''''''''''''''''''
+Merging between different branches (within the same major version)
+------------------------------------------------------------------
 
 Assume that Python 3.4 is the current in-development version of Python and that
-you have a patch that should also be applied to Python 3.3. To properly port
+you have a patch that should also be applied to Python 3.3.  To properly port
 the patch to both versions of Python, you should first apply the patch to
 Python 3.3::
 
-   hg update 3.3
+   cd 3.3
    hg import --no-commit patch.diff
    # Compile; run the test suite
-   hg commit
+   hg ci -m '#12345: fix some issue.'
 
-With the patch now committed, you want to merge the patch up into Python 3.4.
-This should be done *before* pushing your changes to hg.python.org, so that
-the branches are in sync on the public repository.  Assuming you are doing
-all of your work in a single clone, do::
+Then you can switch to the ``3.x`` clone, merge, run the tests and commit::
 
-   hg update default
+   cd ../3.x
    hg merge 3.3
    # Fix any conflicts; compile; run the test suite
-   hg commit
+   hg ci -m '#12345: merge with 3.3.'
 
-.. index:: null merging
+If you are not using the share extension, you will need to use
+``hg pull ../3.3`` before being able to merge.
 
 .. note::
-   If the patch should *not* be ported from Python 3.3 to Python 3.4, you must
-   also make this explicit by doing a *null merge*: merge the changes but
-   revert them before committing::
-
-      hg update default
-      hg merge 3.3
-      hg revert -ar default
-      hg resolve -am  # needed only if the merge created conflicts
-      hg commit
-
-   This is necessary so that the merge gets recorded; otherwise, somebody
-   else will have to make a decision about your patch when they try to merge.
-   (Using a three-way merge tool generally makes the ``hg resolve`` step
-   in the above unnecessary; also see `this bug report
-   <http://bz.selenic.com/show_bug.cgi?id=2706>`__.)
-
-When you have finished your porting work (you can port several patches one
-after another in your local repository), you can push **all** outstanding
-changesets to hg.python.org::
-
-   hg push
-
-This will push changes in both the Python 3.3 and Python 3.4 branches to
-hg.python.org.
+   Even when porting an already committed patch, you should *still* check the
+   test suite runs successfully before committing the patch to another branch.
+   Subtle differences between two branches sometimes make a patch bogus if
+   ported without any modifications.
 
 
 Porting Between Major Versions