[Python-Dev] Using feature branches for local development
"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