In short, I want to "fork" a subdirectory of another project (not under my control) to the top-level of a new repository and make enhancements to the code in that subdirectory while preserving the ability to merge in changes from the subdirectory in the upstream project.
I've been reading up on this topic for a while now but can't find a sure answer for my situation. Most of the uses of git subtree
break down into these cases:
- A subdirectory of a project is being spun off as its own separate project. The parent project is removing the subdirectory entirely and the new project lives its own life.
- A maintainer of a parent project wants to allow maintenance of a subdirectory on its own terms and spins it off into its own repository, which is added back to the main project using
git subtree add
These use cases don't apply to me: I'm not forking-and-forgetting, and I don't own both sides of this fork, so the git subtree add
flow isn't applicable.
So let's say the original module lives in contrib/foo
in the main project. My current idea is to:
- Use
git subtree split -P contrib/foo -b upstream_vx.y
to create a new history that "hoists" the subdirectory up to the top-level of a repository - Create a
master
branch from my project with enhancements from this point - Keep updating
upstream_vx.y
by runninggit subtree split
occasionally - When I need a bug fix or whatnot from upstream, merge
upstream_vx.y
into mymaster
This doesn't feel "git-like" to me. Specifically, I'm basically creating a parallel history of the upstream project's subdirectory and maintaining my own "hoisted" branch for each major upstream branch (to say nothing of being able to reference upstream tags).
Is there a better way to go about this?