If I replace a directory in my project with a submodule, then later attempt to cherry-pick a commit that predates this change (but does not touch the directory), git always marks the submodule path as containing an created/deleted merge conflict. This makes absolutely no sense, as the change in question has nothing to do with the directory, but git seems convinced that it did. % mkdir a b % cd b % git init % touch b && git add b && git commit -m 'initial' % cd ../a % git init % touch a && git add a && git commit -m 'initial' % mkdir b && touch b/b && git add b/b && git commit -m 'add file b/b' % git checkout -b test && touch c && git add c && git commit -m 'add file c' % git checkout master % git rm -rf b % git submodule add file://$PWD/../b b % git commit -m 'replace dir b with submodule' % # everything is fine at this point % git cherry-pick test At this point, the spurious merge conflict exists. Even more annoyingly, if I run git mergetool, it actually moves the submodule out of the way, which requires manual repairs after I've aborted the command. If instead of cherry-pick I run `git show --pretty=email test | git am` everything works as expected. This was reproduced using git version 1.7.4.45.g3c41d, built from the next branch. -Kevin Ballard-- 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