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

Chris Angelico rosuav at gmail.com
Sat Jul 16 21:05:05 EDT 2016


On Sun, Jul 17, 2016 at 10:59 AM, Ryan Gonzalez <rymg19 at gmail.com> wrote:
>> 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.)
>
> What about subtrees:
>
> https://medium.com/@porteneuve/mastering-git-subtrees-943d29a798ec#.6bbjxspcj

Never used them; from a look at the article, that would include the
whole stdlib history still in the main repo, right? I'm not sure how
well this would scale to lots of people with lots of repos, or how
you'd clone appropriately. There would be duplicate commits (one in
stdlib, one in main) with different hashes, or else a really messy
graph of merges. Not sure this is an improvement.

ChrisA


More information about the core-workflow mailing list