Hi! On Sun, Jan 17, 2016 at 08:48:42PM +0000, Brett Cannon <brett@python.org> wrote:
Change sys._mercurial ''''''''''''''''''''' Once Python is no longer kept in Mercurial, the ``sys._mercurial`` attribute will need to be removed. An equivalent ``sys._git`` attribute will be needed to take its place.
Shouldn't there be a sys._vcs with possible values 'subversion', 'mercurial' or 'git'? Well, currently it can be only 'git', of course, but in the future it will change.
Rejected Ideas ============== Commit multi-release changes in bugfix branch first --------------------------------------------------- As the current development process has changes committed in the oldest branch first and then merged up to the default branch, the question came up as to whether this workflow should be perpetuated. In the end it was decided that committing in the newest branch and then cherrypicking changes into older branches would work best as
That's a rather strange workflow. Gitworkflows recommands against it [1], people recommends against it [2], [3].
most people will instinctively work off the newest branch and it is a more common workflow when using Git [#git]_.
Most people commit to master because most [visible] repositories are for web sites/services/applications that don't have many branches. But for a project with a lot of release branches merge workflow is usually recommended. 1. https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html 2. https://stackoverflow.com/a/1241829 3. http://dan.bravender.net/2011/10/20/Why_cherry-picking_should_not_be_part_of... Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.