Michael Foord <fuzzy...@voidspace.org.uk> writes: > On 28/03/2011 11:35, Nick Coghlan wrote: > > I'm seeing if I can get the best of both worlds by having a public > > sandbox repo where I work on things (which has the full messy > > history of development on its feature branches), and then just drop > > them into the main repo as coherent patches. Once I land a patch, > > I'll close the original feature branch in the sandbox, so merge > > conflicts won't be an issue.
Yes, using Bazaar I get something similar by nominating one of my branches (often named “devel”) as the integration branch. All commit-often work is done on feature branches, with all the warts exposed. Merges into the integration branch are accompanied by a high-level commit message summarising the changes of interest to whomever follows that branch. Patches upstream, in the cases where upstream is not using Bazaar, are made from the integration branch with their useful-to-others diff and commit message. > For any non-trivial work I think this is the best approach. You still > get all the advantages of working with mercurial (able to commit > frequently) without polluting the history of the core repository. > > It has the major advantage of also being very simple to understand. I'm glad others have come to a similar conclusion. Perhaps the Python developers can encourage the Mercurial developers to make this workflow more obvious to new users? -- \ “My interest is in the future, as I am going to spend the rest | `\ of my life there.” —Charles F. Kettering | _o__) | Ben Finney _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
