4

I have a huge Git repo with some 50 Maven modules (a Maven reactor build). How can I move some of those modules into a new Git repo?

I tried git subtree but those commands always move the code to the root of the new repo plus I can't say "I want a/, b/ and c/d/ in my new repo" - instead I have to move each individual tree and afterwards, I have to rename the files to move then from the root into their old place (relatively speaking).

How do I export/copy/move a set of changesets filtered by path from one Git repo to another without making any changes to them? Kind of: How do I repeat history with Git?

Notes: I want to move the data. The new repos shouldn't be linked by Git in any way; Maven already does that for me. No subtree magic necessary to push changes upstream or things like that. I want the world to look as if we had had two repos to begin with.

Aaron Digulla
  • 321,842
  • 108
  • 597
  • 820
  • Could you add some information on *why* you want to split? Are the repos just too big, do you want to version/branch them separately, is it for confidentiality reasons? – sleske Jul 03 '14 at 10:12
  • I want to split them into stable and development (i.e. one part that is very stable and changes rarely and another which changes every day). This is to speed up development: Compile less code, run fewer tests all the time. – Aaron Digulla Jul 03 '14 at 10:15
  • Why do you need to split repos to compile less code? Can't you just modify the build infrastructure to allow partial builds/deployments? E.g. create new Maven profiles that exclude some sub-projects. If the projects are ultimately branched, versioned and released together, I'd rather advise against putting them into separate repos. – sleske Jul 03 '14 at 10:34
  • @sleske: We plan to have three repos from which we release once per year, every three months and every three weeks, respectively. – Aaron Digulla Jul 03 '14 at 11:35

1 Answers1

5

Create several clones of the repo - one for each new repo you want to have in the end. Then use git filter-branch (or some tool built on it, like BFG Repo-Cleaner) in each new repo to remove everything you don't want to keep. This is described for example in Remove folder and its contents from git/GitHub's history .

For example, if you want to split one repo into two new ones, you make two clones (let's call them A and B). In A you delete everything that will go into B, and the reverse for B.

Afterwards, you will end up with several "new" repos ("new" in the sense that they contain new, rewritten commits), each of which contains some subtree of the original repo.

As part of the rewrite process, you can decide if you want to change the directory structure (e.g. move main/subA to subA, if the repo will only contain subA), or if you want to keep the old structure in each new repo.

Important: Before you try this on your real repo, create a clone (on your local computer and on the shared server) and try it out at least once.

In case you need to do this several times, you'll need to merge two repos into one. For this, see git merge different repositories?

Community
  • 1
  • 1
sleske
  • 81,358
  • 34
  • 189
  • 227
  • That's an interesting idea but only half of the picture. How can I merge these 15 new repos into one? – Aaron Digulla Jul 03 '14 at 10:16
  • @AaronDigulla: Is this a misunderstanding? There should be no merging necessary. If you just want to split into two new repos, you create two clones, A and B. In A you delete everything that goes into B, in B the reverse. I edited my answer to (hopefully) clarify things. – sleske Jul 03 '14 at 10:36
  • Oh, right. Yeah, I can delete `~B` to have only `B` back. – Aaron Digulla Jul 03 '14 at 11:34