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

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.