How to change the source of a Git subtree merge

Question

I have a project where I've merged in a library using Git subtree. I've pushed and pulled a few minor changes between the library and the project.

Later on, a new repository has been created which is the definitive home for the library. It contains essentially the same version of the library code as my project did, with perhaps one or two minor changes. For various reasons, it doesn't share any direct Git history with the previous home of the library (it is not a clone of the previous library).

What I want to do now is change my project so that it pulls/pushes the library from the new location. The first time this happens I also need to resolve any merge conflicts, although in this case the changes are trivial and they could just be redone later.

What is the best way to do this?

I tried deleting taking a copy of the the library in my project, then removing it along with the old remotes and branches. I then tried doing subtree add etc from the new location. This seemed to work, but when I try to push back from my project to the library I'm getting a fatal bad object error.

I assume that there's a flaw in the approach that I've tried - probably to do with the lack of a shared history - but I don't quite have a deep enough understanding of what's going on to know how to fix it, or what the "proper" approach to this problem should be.

[update: edited the question to make it slightly clearer - it was a bit ambiguous]

Answer 1

Try cloning the new project. then adding yours as a remote and doing

git remote update

This will pull in all the refs from your project. now do

git cherry-pick <sha1>

of the sha's that you want in the new project. That's the easiest way I think.

Also you should know that git doesn't require a common history (though it makes for less nice merging the first time) for a merge. so you could just do what I said and then instead of cherry-picking you could merge your history. it will probably have conflicts. I suggest once you start the merge (if you do) use git mergetool and know how to use the 3-way diff.

Answer 2

Is there any reason you aren't referencing your library as a submodule from your project?
(See true nature of submodules)

The advantage in your case would be how easy it is to change a submodule address.

Answer 3

Perhaps, you should set up a separate working branch (or repositiory) with your version of the library (only the library tree with your changes) which you could then push back to the original library repo.

So, in order to push to the original remote repo, first prepare locally what you expect to appear as a commit remotely; there can be different workflows to achieve this: either, during the work on your project, you first commit your library changes to your special local working branch dedicated to the library (that branch should inherit the original history of the library), and then merge this branch with the library changes into your project working branch (where the library is a subtree), or merge your changes back from the project working branch into the dedicated library working branch. Then you can push your dedicated library working branch to the original remote repo when you wish.

So, essentially, first you create a local dedicated working branch so that it inherits the original history:

git branch MY_LIBFOO REMOTE_BRANCH_LIBFOO

(REMOTE_BRANCH_LIBFOO is your locally strored remote branch that interests you, which is updated by git fetch)

then, following your workflow, make sure that your changes to the library are in the working branch MY_LIBFOO, and then you can

git push original_libfoo MY_LIBFOO:TARGET_BRANCH_REMOTELY

This way, there is a clear idea of what is happening.