Add TODO to README about cherry-pick-like commits

README

@@ -168,6 +168,9 @@ git-subhistory assimilate <subproj-path> <subproj-branch>
    commits is prioritized, and git-subhistory merge will be made more
    sophisticated and will automatically resolve conflicts in the "Main"
    tree outside "path/to/sub/" in favor of HEAD.)
+  (Note: it is recommended to only split from/merge into the same Main
+   branch. TODO: explain why merging in commits split from another
+   branch can be like cherry-picking.)
 
 git-subhistory merge <subproj-path> <subproj-branch>
 

git-subhistory.sh

@@ -195,7 +195,9 @@ subhistory_assimilate () {
 		#   + [FN1]: others weren't split into ancestors of SPLIT_HEAD, and hence
 		#     aren't in the split-to-orig-map, and thus couldn't be a rewritten
 		#     parent. This is actually why merge explicitly doesn't invert splitting
-		#     of all commits, it only inverts splitting of ancestors of HEAD.
+		#     of all commits, it only inverts splitting of ancestors of HEAD, at the
+		#     cost of the potentially surprising cherry-pick-like commits described
+		#     in the README.
 		#   + [FN2]: augh, this takes more than a dozen lines: looping over each
 		#     parent, read the tree for the (rewritten) parent into the index, delete
 		#     "path/to/sub/" from the index, and then if this is the first parent,