On Sun, Jul 17, 2016 at 10:46 AM, Brett Cannon <br...@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 _______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
