2

Right now I'm attempting to slim down a bloated repo by deleting git objects associated with long-deleted binary files in source control. I'm using the BFG repo cleaner, which is succeeding at slimming the repo and leaving the current commit untouched, but I'm struggling with how to orchestrate the migration to the slimmed repo.

For context, all developers work off of forks of the main repo, and only merge changes via PRs. For the migration, I'm thinking to have everyone pull the latest changes from upstream, then run the BFG job, force push, then have everyone re-fork and re-clone.

That much is pretty straightforward, but things are tricky because everyone has history in their own forks of a repo whose history is about to be fundamentally re-written. What I'm struggling with is how to let the devs migrate feature branches from their old forks and clones to their new forks and clones. Everything I've tried (i.e. adding the old repo as a remote and pulling) is bringing over way more history than I want, or no history at all (i.e. cherry-pick); ideally we'd only bring as much history as has been changed in the branches and their commits.

Is there a best practice here?

Answorth
  • 147
  • 1
  • 2
  • 10

1 Answers1

1

adding the old repo as a remote and pulling

Almost: add the old repo and fetch.

Then you can do a git rebase --onto, which allows you to replay section of the history to the new repo

git checkout master # or any other commit from  which you want the feature branch to start
git checkout -b feature_branch old_repo/feature_branch # re-create the feature-branch
git rebase --onto master first_commit_fb~1 feature_branch

With first_commit_fb being the first commit of that feature branch in the old repo.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250