Git -stitch-import: how to make one leading branch?

Question

I am trying to merge several git repositories into a new repo with each old repo as a subdirectory in the new repo. git -stitch-repo seems to be the tool I want.

However, the documentation is less clear. I was able to follow him ( https://metacpan.org/pod/distribution/Git-FastExport/script/git-stitch-repo ) to the part where it says: "Now you can create the main branch and point it to the right commit and delete two branches master-A and master-B.

What is the “correct fixation” and how to complete these steps?

Right now, I have several branches labeled master-A, master-B, etc., which seem to match the original repositories. I really only wanted a master branch that contains everything. It seems like you can get there, but I don’t know how to do it.

Answer 1

I am author git-stitch-repo . Given your description, this is really the tool you are looking for.

Here's how the program works :

• it scans all the commits received from git fast-export output for each repository to merge and create a new thread for git fast-import
• in a new thread, the commit can be transferred from any other repository as a parent
• the program ensures that if you filter out all commits from other repositories, you will get the original repository

Since all repositories can have links with the same name, the program adds -A , -B , etc. at the end of the link names, so you can find out in which repository each link in the new repository is accessed. That is why you get master-A and master-B . Choosing the “right” wizard only means that from master-A and master-B is your new master .

The biggest problem with the current version (I'm currently working on a fix) is that for each branch point in repository A, the system must decide which side to attach the next commit from repository B (if there is actually an alternative between several valid commits, which adhere to the limitations of the stitching algorithm . If all options are valid, the choice is mostly random. And then master-A and master-B can end up on different branches, which is usually not what you want. (This is what RT # 70695 is about .

As I said above, I am working on a fix, and I have a good hope that it will fix your problem. I expect to be able to make a new release with a few days.

Answer 2

If you do not mind having multiple roots, you can do this (for each subproject):

• go to the subproject - we will call it the project 'foo'
• create the folder 'foo' there (we want everything contained in the project name)
• git mv everything in the root directory in the root folder 'foo'
• commit changes

Now in the main project (suppose you want to merge the "master" branches):

• git remote add foo /path/to/foo/project
• git fetch foo
• from the main branch of the do- git merge foo:master project

This will create a merge commit, and from now on you will have everything related to the foo subproject in the foo folder in the main project. Before this confluence, you will be on either of two separate trees. For their stories, it makes no sense to mix, so this is a great way to set up a situation where two trees only connect at the place where you decided to combine them.

If you want the whole story of each subproject to merge into ...

This is a little trickier. The main idea is that you select the last commit from the main project and relocate the entire subproject to this point, so the whole subproject - that is, all its commits - grows from now on, d combine the head of the subproject back into the main project, possibly with - no-ff (no fast forward) so you can see the whole subproject in the commit bubble. This requires that the entire background of the subproject be in a subfolder of the project name (ie, "Foo" from the first section).

This will require a ton of manual work or something with git filter-branch , which I will have to work with for a while - I can’t think of it from my head. I assume this will be --tree-filter , and you will have to move everything that was not in the 'foo' folder to it for each commit. I don’t know how this processes branches and merges in the project, but I suspect that this works. I will not try to understand this in case you are ok with the first sentence with several roots (I think this is the best option for two).

If you don't mind multiple roots, but want to be able to send a back link up ...

If this is the case for subprojects - they are going to this repo forever and will never be able to see the light of day, none of the first two options will be in order. If you sometimes want to push you back, you should look into git submodules and subtrees .

Submodules essentially allow you to clone a repo into a specific folder in your project. Your project should only have tracks that need to be fixed. When you clone your main repo, the submodule folder will not exist. You can do this by running git submodule init to create a folder, and git submodule update to pull out all the files.

Fakes go further and read the entire subproject directly into a folder of your choice, mainly a repo. From now on, this folder exists just like any other folder in your project. Most of the magic here comes from merging a subtree, which allows you to make changes from a subproject without any history, while push changes are the other way around.

Given the option of all 3, I would prefer to use submodules or subtrees. This is a clean way to merge repositories together.