-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
switch to git subtree for typeshed #1219
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
We discussed subtrees before switching to submodules (#882). I'm fine with reopening this as I don't particularly enjoy git submodules, though I've never used subtrees. Before we can make a decision we should at least document how various common workflows would change, and what new git commands contributors would have to use. Based on the previous discussion, these seem to be some of the worst things about subtrees:
I'd love to hear feedback especially from people who have some experience with the current submodule workflow (and maybe even subtrees). |
I've used subtree merges, but not the "new" After setting this up initially (
All in all, subtrees don't sound too horrible. The main thing I don't like is that the configuration of the subtree isn't copied onto your system via Unless users have carefully read all the documentation, it'll be typical that mypy gets a PR which contains commits touching both mypy and typeshed. Then, you'll either have to tell users to split the changes, or, if you don't mind a bit of commit-message redundancy, you have to do the corresponding I'm also a bit worried that there's going to be the temptation to "let typeshed float", i.e. not push changes to |
What's the current workflow for making a mypy change that requires typeshed changes? I don't think it's self documenting, particularly. Are you forced to upstream your typeshed changes first? One downside of the submodule approach is that everyone that develops on mypy has to deal with it, even if they don't touch typeshed. I agree that the temptation to "let typeshed float" is worrisome. Is there something we could do to prevent that? Is being disciplined enough? |
Revisiting this (and rereading the subtree workflow that Matthias helpfully outlined!), I'm less convinced that it makes sense to switch to git subtree for managing typeshed. Here's how the tradeoffs look to me now (focusing on the pain points for both approaches): submodule:
subtree: (I think these basically echo Matthias's earlier concerns)
On balance, I'm starting to think that we may be better off just sticking with submodules. Maybe the real fix here (for me) is to start using a post-checkout hook that runs Thoughts? |
I added |
git subtree is vastly nicer than git submodule. Let's use git subtrees instead for including typeshed.
Benefits:
git submodule init
orgit submodule update
See this blog post and the man page for more info on git subtree.
The text was updated successfully, but these errors were encountered: