If you use git-subtree in the mode that doesn't flatten the original tree it does not, afaik, modify any commits on either side. The original tree, as imported, and the tree being imported to, are both parents of the post-subtree tree with their original SHAs.
You seem to be very knowledgeable about subtree, so I'll ask a question you can hopefully answer:
I have multiple repositories each having 100,000-500,000 files, all relating to the same project. The reason I broke them up to multiple projects is that the git index doesn't handle millions of files all that well (e.g. index gets rewritten on every modification). Would subtree help me here in any way?
Of course, this is not a usual way to use git, and Facebook opted for switching to Mercurial when faced with a similar problem (though an order of magnitude or two larger, I'm sure).
submodules work for me now, but they are very clunky -- but the reason I didn't even try switching was the crypto signing of commits, which is apparently not a problem. Would subtrees help me with the scale as well in any way?
No, I don't think subtrees can really help you with this unfortunately. At least not directly. Using the flattened mode might help, but then you'd be back to your problem with signing them. The subtree merge commit does record the original SHA, so I suppose you could verify as a separate step if you needed to that that merge commit is indeed the result of a correctly signed SHA somehow.
But I think for your use case you're probably stuck with submodules.
