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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4