Discussion: Use `git subtree` for libraries
Closed this issue · 0 comments
EmperorArthur commented
Several recent PRs have included libraries, and we need to figure out how to handle them. Especially since some are extremely useful, and would reduce the code we have to maintain.
I see a few options:
- The easy option, and what I approved for the threads library, is to just include a copy of the code.
- That does not work with libraries that are updated.
- Really not best practice.
- The classic option is
git submodule
.- Not easy to use.
- Makes checking out the project more difficult.
- Many people do not recommend it, to the point that pre-commit has a hook for migrating away from submodules.
- The new thing is
git subtree
.- Should be already installed with any relatively modern version of git. AKA everywhere but Debain stable. Maybe....
- I am unfamiliar with it, but it looks interesting.
- https://www.atlassian.com/git/tutorials/git-subtree
- We could also just remove the threads library and ban libraries all together.
- Avoids the complexities and issues of all the other options.
- It's de-facto what we've been doing so far.
- Not a fan personally.
Thoughts?
Edit:
Now that I've taken a closer look, git subtree looks far less appealing. I'm leaning towards submodules, and just adding documentation to set git config --global submodule.recurse true
[1] before initial checkout.
We aren't looking to perform edits in the libraries themselves directly through the submodules, and said libraries don't change often enough to cause some of the pain others have with submodules.