0

I am currently facing a large git repository (lets call it upstream) with commits that reach back more than 10 years. I don't need most of the history from it. Actually it would be enough to slice out a branch from it and transfer it into its own repo and maintain the ability to merge commits from the original upstream branch now and then. In my head, this would keep the repo size small.

Depicted: from

          D' - E' upstream/release
         /
A - B - C - D - E upstream/dev

to

D' - E' myrepo/release

and be able to git merge upstream/release or git rebase myrepo/master.

I'm aware that myrepo/release would need some artificial init. I already tried a lot with git checkout --orphan, git rebase --onto etc. but didn't come to a solution. Maybe someone can help with a nice idea!

Thanks, Jens

jenzopr
  • 70
  • 1
  • 9

1 Answers1

0

I came up with the following:

git checkout --orphan my_release D'
git add .
git commit -m "Started new history"

and then rebasing the entire upstream/release branch:

git checkout upstream/release
git rebase --onto my_release D' upstream/release

and merging:

git checkout my_release
git merge upstream/release

This results in new commit-IDs, but updating in future might work via rebasing.

This answer helped a lot.

jenzopr
  • 70
  • 1
  • 9