On 17 January 2016 at 20:48, Brett Cannon
Rationale ========= . . . The overarching goal of this migration is to improve the development process to the extent that a core developer can go from external contribution submission through all the steps leading to committing said contribution all from within a browser on a tablet with WiFi.
Later on, at least for the main “cpython” repository, you mention maintaining a linear history, avoiding the automatic Git Hub merge button, and cherry-picking between branches. I guess you would need the commit bot to help do all this from a browser. If so, mention that, otherwise this gives the impression that people will Git Hub’s merge button, which seems to contradict later sections.
Document steps to commit a pull request ''''''''''''''''''''''''''''''''''''''' During the process of choosing a new development workflow, it was decided that a linear history is desired. This means that the convenient "Merge" button in GitHub pull requests is undesireable, as it creates a merge commit along with all of the contributor's individual commits (this does not affect the other repositories where the desire for a linear history doesn't exist).
Please clarify whether this linear history is just avoiding the suprious merge commits that Git Hub can add for each pull request (merging a pull request with its parent commit), or whether we are going to stop merging maintainence branches into master, and do cherry-picks instead.
Linking a pull request to an issue ++++++++++++++++++++++++++++++++++ . . . (technically it should be a many-to-many association for when a single fix solves multiple issues, but this is fairly rare and issues can be merged into one using the ``Superceder`` field on the issue tracker).
Spelling: ``Super[s]eder``
Status ====== . . . Repositories whose build steps need updating:
There is some stray indentation starting here which seems to be messing with the markup.
The fate of hg.python.org ------------------------- With the code repositories moving over to Git [#git]_, there is no technical need to keep hg.python.org [#h.p.o]_ running.
I presume this means other repositories will be migrated somewhere else too? For instance, I recently had to update the “pythontestdotnet” repository.
Tools and commands to move from Mercurial to Git ------------------------------------------------ A decision needs to be made on exactly what tooling and what commands involving those tools will be used to convert a Mercurial repository to Git. Currently a suggestion has been made to use https://github.com/frej/fast-export. Another suggestion is to use https://github.com/felipec/git-remote-hg. Finally, http://hg-git.github.io/ has been suggested.
The migration to Git might be a good opportunity to clean up some of the older Subversion history. I would like to investigate this. In particular, rewriting svnmerge commits as proper Git merges, and restoring the missing history for merges and imports from feature branches. On the other hand, there is already a Git mirror https://github.com/python/cpython which many seem to be already using. Perhaps it would be good to ensure the commit hashes used there are kept current. Which tool is used to update that mirror? Are there any deficiencies that would mean we need to use a different tool, possibly affecting the commit hashes?
Separate Python 2 and Python 3 repositories ------------------------------------------- It was discussed whether separate repositories for Python 2 and Python 3 were desired. The thinking was that this would shrink the overall repository size which benefits people with slow Internet connections or small bandwidth caps.
In the end it was decided that it was easier logistically to simply keep all of CPython's history in a single repository.
Agreed. If people really only want one of the branches, they can set Git to only download from that branch. And Git supports shallow clones (only download the most recent commit, or N commits deep), although some functions may not work in this mode (but apparently things have improved since I learnt about it).