[core-workflow] What would it take to split the stdlib out into its own git repo?

[Chris Angelico]

On Sun, Jul 17, 2016 at 10:46 AM, Brett Cannon <brett at python.org> wrote:
> For instance, would we be able to split the history, or would the original
> history stay in the CPython repo and we would start from scratch in the
> stdlib repo and `git log` would hopefully be smart enough to merge the two
> histories? How bad is it to work in a repo with a submodule where you will
> be making changes to submodules regularly?

I detest working with git submodules; if the repositories get split,
I'd much rather have ./python look for ../python-stdlib as a parallel
repo. They stand entirely separately; you simply clone both repos into
the same directory. (For example, the editor SciTE and its component
Scintilla work this way. I have /home/rosuav/scintilla and
/home/rosuav/scite, and build Scintilla first, then build SciTE. The
building part wouldn't be an issue with the stdlib, so it'd be
easier.)

Splitting out the history can certainly be done. You simply clone the
main CPython git repo, then tell git to throw away everything that
isn't in the Lib/ directory. Not all commits will read sensibly like
that (maybe there's a trivial edit to the stdlib, associated with a
core interpreter edit, and the commit message mentions only the core),
but it's faithful and reliable, and you get the full history, going
back deep into the Mercurial days. (And earlier, if the hg repo
imported other data.)

ChrisA