[Python-Dev] Using feature branches for local development (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Sun Mar 13 13:47:29 CET 2011

Am 13.03.11 07:25, schrieb Nick Coghlan:

I'm experimenting with creating some local branches for things I'd like to work on during the sprints this week, and have a couple of questions about the associated workflow.

1. While the feature branches are active, is it correct that I can't use a bare "hg push" any more, since I don't want to push the feature branches to hg.python.org?

Despite what anybody told so far: yes, you can continue to use a bare "hg push". In the clone, edit .hg/hgrc, and have "default" point to the remote repository you want to push to. As the remote repository, you can use one of those you created with a remote clone.

If you want to continue to pull from cpython to merge upstream changes, set up a default-push path in .hg/hgrc. Then pull will get incoming changes cpython, outgoing changes go to the sandbox repository.

2. Once I'm done with the feature branch, I need to nuke it somehow (e.g. by enabling the mq extension to gain access to "hg strip" command)

I think this will need reconsidertion. Apparently, the recommendation is that you need to flatten all changes into a single commit when integrating is. The way I would do it is to produce a diff, and apply a patch to cpython. One way of producing the patch is to use "hg outgoing", another is to use a named branch in your clone and do "hg diff default feature".

The mercurial-recommended way is that you just push your changes to cpython when done, which puts all your individual commits into Python's history.

I tried to find an official statement on which way it should be in the devguide, but couldn't find anything.

Regards, Martin

More information about the Python-Dev mailing list