Hello, I am currently using git subtree in a project : https://github.com/asmodehn/wkcmake This is basically a set of cmake scripts that help writing convention based (folder hierarchy, etc.) cmake builds. My setup is that "master" has the set of scripts needed. and many other branches ("test" and "tests/*" most notably) have tests projects for these scripts. Travis run build of these to check if the build setup works as expected. The "test" branch has a hierarchy of dependent projects (ProjectA, ProjectB, ProjectC) , all using the wkcmake scripts to build. So I am using git-subtree to pull and push "ProjectA/CMake" ProjectB/Custom CMake" "ProjectC/CMake". I had enough trouble with push to stop using it( merge not happening as I thought it would ). Not sure if I am to blame or not for these... Anyway now, after a commit into the test branch, I instead split the CMake subtree to a new branch, and merge in manually back to master. That seems to work okay so far. However I realized that when I do : git subtree pull -P ProjectA/CMake git@xxxxxxxxxx:asmodehn/ wkcmake.git origin master git subtree pull -P "ProjectB/Custom CMake" git@xxxxxxxxxx:asmodehn/wkcmake.git origin master git subtree pull -P ProjectC/CMake git@xxxxxxxxxx:asmodehn/wkcmake.git origin master I get only one merge commit into the "test" branch. All the other subtree pull returns "Already up to date" even though the content of the working directory in the prefix passed is NOT uptodate. The possible behavior that I could understand would be : - One subtree pull update all prefixes, with only one merge commit, and the prefix doesnt really matter anymore ( could be problematic... ) - Each subtree pull update the appropriate prefix with one merge commit each. So I am curious : I this a scenario that subtree doesnot support ? Am I using it wrong ? Is it a current limitation/bug of subtree that is on the roadmap to be addressed sometime in the future ? Thanks a lot for the help. -- AlexV -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html