> With #3, I can see that you want something different than I do; you > want to silently revert your own patches out of the submodule's > history, when you upgrade the submodule to a new version. Personally, > I find this concept a bit objectionable (it's like "git merge -s > ours"), but okay, it's pretty easy to implement, and you've submitted > a patch to git-subtree that does it. My question is: why would you > want this? Isn't it clearer to 'git revert' the patches you don't > want? While writing the docs for the --prune option I've found this sentence in git-subtree.txt: 'git subtree merge --squash' always adjusts the subtree to match the exactly specified commit, even if getting to that commit would require undoing some changes that were added earlier. I think this is not true, and it contradicts with what you've just said. Or I don't understand it correctly. Thanks, Santi -- 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