5 ms·

Moving Git commits between repos (2017)

41 points by piinbinary 3y ago

whoomp12341 3y ago
How is this different from running git pull or git push to a remote?
- edgyquant 3y ago
  Because this is about two repos with unrelated histories
  - OJFord 3y ago
    You can have multiple orphan/root commits, it can be that simple conceptually.
- tripleo1 3y ago
  Without reading everything it seems like you can change the paths and still keep the history (of both), while seeing both simultaneously, as opposed to switching branches, like it seems you are saying.
  - whoomp12341 3y ago
    no, I am not talking about switching branches. I mean pushing to a remote repository. Git was designed to be decentralized such that you can push and pull from multiple machines in any flow you like. Most folks at engineering shops use git in a central model from my experience
oftenwrong 3y ago
I recommend using https://github.com/newren/git-filter-repo https://github.com/newren/git-filter-repo instead of filter-branch.
jaeckel 3y ago
The mainstream version of this post is called subtree-merge and supported by recent Git versions ootb
whateveracct 3y ago
huh good to know. I often just make and apply patches when I'm dealing with different histories. Doesn't always work though.
jackconsidine 3y ago
I merged two codebases (several thousand commits each) into a monorepo using a similar strategy. Instead of top level files in an api repo, and top level files in a web repo, we have packages/api and packages/web. It feels magical that I can open up a blame for a file in either package when most commits occurred in separate repos spanning back 5 years
jez 3y ago
If the goal is to move all the commits of one repo into another repo, Git provides subtree merges: https://docs.github.com/en/get-started/using-git/about-git-subtree-merges https://docs.github.com/en/get-started/using-git/about-git-s... For companies that started out making lots of small repositories that want to moev incrementally to a monorepo, this strategy can be useful because it sets up the smaller repo as a self-contained unit of the larger repo, preserving things like git commit history and git blames. After a subtree merge, further steps can more tightly integrate the code into the larger repository (i.e., so that it is no longer wholly contained in the subtree).

41 points by piinbinary 3y ago

whoomp12341 3y ago

How is this different from running git pull or git push to a remote?

edgyquant 3y ago
Because this is about two repos with unrelated histories
- OJFord 3y ago
  You can have multiple orphan/root commits, it can be that simple conceptually.
tripleo1 3y ago
Without reading everything it seems like you can change the paths and still keep the history (of both), while seeing both simultaneously, as opposed to switching branches, like it seems you are saying.
- whoomp12341 3y ago
  no, I am not talking about switching branches. I mean pushing to a remote repository. Git was designed to be decentralized such that you can push and pull from multiple machines in any flow you like. Most folks at engineering shops use git in a central model from my experience

oftenwrong 3y ago

I recommend using https://github.com/newren/git-filter-repo https://github.com/newren/git-filter-repo instead of filter-branch.

jaeckel 3y ago

The mainstream version of this post is called subtree-merge and supported by recent Git versions ootb

whateveracct 3y ago

huh good to know. I often just make and apply patches when I'm dealing with different histories. Doesn't always work though.

jackconsidine 3y ago

I merged two codebases (several thousand commits each) into a monorepo using a similar strategy. Instead of top level files in an api repo, and top level files in a web repo, we have packages/api and packages/web. It feels magical that I can open up a blame for a file in either package when most commits occurred in separate repos spanning back 5 years

jez 3y ago

If the goal is to move all the commits of one repo into another repo, Git provides subtree merges: https://docs.github.com/en/get-started/using-git/about-git-subtree-merges https://docs.github.com/en/get-started/using-git/about-git-s... For companies that started out making lots of small repositories that want to moev incrementally to a monorepo, this strategy can be useful because it sets up the smaller repo as a self-contained unit of the larger repo, preserving things like git commit history and git blames. After a subtree merge, further steps can more tightly integrate the code into the larger repository (i.e., so that it is no longer wholly contained in the subtree).