git-subtree conflict when pulling from central repo

Question

I have several projects that depend on the same library, for which I\'d like to maintain a separate git repository to be managed with git-subtree within each project. So for

Answer 1

Well, it seems to be a bug in git-subtree. I evaluated it for my needs and gave up. Basicaly, git-subtree push alters commit messages and thus, SHA1 of commit changes. You have to pull to merge additional commits which introduce exactly the same changes but just have different SHA1 hashes due to altered commit messages. GIT handles double merges (merging same changes again) correctly, so it silently notes the merge.

Someone has to fix it!

Answer 2

I actually found the proper way to do this through some trial and error.

After this command:

project1$  git subtree push --prefix=lib1 /path/to/lib1.git master

execute a fetch command:

project2$  git fetch /path/to/lib1.git master

and then do your pull:

project2$  git subtree pull --prefix=lib1 /path/to/lib1.git master

Answer 3

There is unfortunately no good way to split commits out of the tree without giving the newly-split commits totally different commit ids. This is because they are, after all, different commits: they don't contain the parts that weren't in the subtree. That means when you pull them back in, git will see them as entirely new commits and generate a conflict.

There are two things you can do. One of the other answers suggested doing a git subtree pull right after you push. This will work, but you end up with two copies of every commit because there really are technically two sets of changes: the upstream ones (auto-generated by git-subtree push/split) and the ones in your combined project, and you are merging them together. A shortcut for this method is the --rejoin option to split/push, which adds the extra merge commit right away.

The second option is to use --squash. This also creates new merge commits, but since you merge all the changes from the upstream repository as a single commit instead of one per original commit, it causes less clutter in your history. Most people seem to like it better with --squash.

Answer 4

Inside your main project, try to pull and push with squash commands always :

step 1 : subtree pull with a squash

 git subtree pull --prefix=mainProjectFolder/subtreeFolder http://bitbucket.org/repo.git master --squash

step 2 : subtree push with a squash

 git subtree push --prefix=mainProjectFolder/subtreeFolder http://bitbucket.org/repo.git master --squash

squash flag will avoid creation of new SHA1 id's for the same commit in different repositories.

Explanation : To over come this issue you can make it a convention to use the squash flag while pushing and pulling your subtree. The issue described by @Borg about SHA1 commit id's is correct, but subtree were not really built for this. You should avoid to keep the commit Id' of the subtree(library) repository in both the parent project and subtree project. And if at all you push changes from the parent repository to the subtree repository follow this statement from the documentation(line 58): That is, if you make a change that affects both the library and the main application, commit it in two pieces.

Also this video explains it when not to use subtrees. Drag straight to 11:00 minutes to find that subtree's are not the correct solution for you if :

you have constant updates to the repository,

or, if you have many dependencies,

or, if everyone in the team has to learn subtrees.