[HN Gopher] Moving Git commits between repos (2017)
___________________________________________________________________
Moving Git commits between repos (2017)
Author : piinbinary
Score : 29 points
Date : 2024-01-02 18:21 UTC (4 hours ago)
(HTM) web link (jeremymikkola.com)
(TXT) w3m dump (jeremymikkola.com)
| whoomp12341 wrote:
| How is this different from running git pull or git push to a
| remote?
| edgyquant wrote:
| Because this is about two repos with unrelated histories
| oftenwrong wrote:
| I recommend using https://github.com/newren/git-filter-repo
| instead of filter-branch.
| jaeckel wrote:
| The mainstream version of this post is called subtree-merge and
| supported by recent Git versions ootb
| whateveracct wrote:
| huh good to know. I often just make and apply patches when I'm
| dealing with different histories. Doesn't always work though.
| jackconsidine wrote:
| 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 wrote:
| 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-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).
___________________________________________________________________
(page generated 2024-01-02 23:02 UTC)