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 example, within each project I can do:
project1$ git subtree add --prefix=lib1 /path/to/lib1.git master
project2$ git subtree add --prefix=lib1 /path/to/lib1.git master
Now in the course of working on project1, I make some changes to lib1, say lib1/file1.c, and push this back to the central repo:
project1$ git add lib1/file1.c
project1$ git commit -m "updates to lib1"
project1$ git subtree push --prefix=lib1 /path/to/lib1.git master
So far, so good. But now I'd like to update project2's copy of lib1. So I try:
project2$ git subtree pull --prefix=lib1 /path/to/lib1.git master
Auto-merging lib1/file1.c
CONFLICT (content): Merge conflict in lib1/file1.c
Automatic merge failed; fix conflicts and then commit the result.
What's going on? I know for certain that no changes were made to any of the lib1 files under project2, so why should there be a conflict here?
The conflicts are half-empty, like those reported in this question. Everything is being pulled/pushed within a single system (OS X), so I know there's no issue with line endings as suggested there.
Surely this is a common use case for git-subtree, and has a simple answer I just can't see. Please help!
EDIT: I found an unsatisfying workaround: immediately after pushing changes to the subtree, I need to re-run subtree pull:
project1$ git subtree push --prefix=lib1 /path/to/lib1.git master
project1$ git subtree pull --prefix=lib1 /path/to/lib1.git master
Even though there were no changes, it will find something, and do a merge commit. Then, after making some changes elsewhere, the conflict won't happen the second time I pull from the central repo. But if I forget to run pull immediately after pushing, the next pull will get this conflict.
So now my question is, why does this work? Is there a bug in the way git-subtree tracks pushes, or am I missing something?
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!