I got this ridiculously large Git repo in GitHub. This repo consists of several independent projects that I want to break down into their own separate repos, and continue their development there.
ridiculously-large.git
├───Project1
├───Project2
├───...
└───Project1000
For now, I'm interested in Project2
. I want to "clone" Project2
only, along with its history, to a new repo Project2.git
exclusively dedicated to it, and leave ridiculously-large.git
only for historical purposes.
So far, I've been somewhat successful with the following approach:
First, create a brand new repo in GitHub,
Project2
with no commit history (this seems to be important in order to avoid those "fatal: refusing to merge unrelated histories...") and clone it.git clone https://github.com/me/Project2.git
Thus, my local repo is already configured with default remote
origin
pointing to the new GitHub repo that will be specific to further development ofProject2
.Then, within the new local repo:
git config core.sparseCheckout true echo Project2/ >> .git/info/sparse-checkout
Then, I add a temporary upstream remote
temp
pointing toridiculously-large.git
:git remote add -f temp https://github.com/me/ridiculously-large.git
So far so good. There is still nothing to commit.
Then, pull the
master
branch from thetemp
remote into a newwork
local branch:git pull temp master:work
(I do this because of personal practice: I never work in any local
master
branch, whether or not the there is an upstream branch configured for it.)This successfully accomplishes the goal of pulling only the sources related to
Project2
into the working copy. So far so good.Now, after I push
work
to the newly dedicated remoteorigin
:git checkout work git push --set-upstream origin work
... I see THE WHOLE SHEBANG pushed to the newly dedicated remote for
Project2
, miserably defeating the entire purpose of this endeavor.
The Question(s)
- What is the established/recommended approach to achieve my goal?
- Is it possible to do it as a variation of what I'm doing (or not doing correctly?)
- Are there any other Git constructs more appropriate altogether?
Thanks in advance for any enlightenment!