that is what i meant with merging. regardless of the method used, they were combined somehow, now giving the appearance that they were always part of the repo. but in reality they were not part of the repo until they were included.
They were always part of the repo, just with a different path. And only the path within the repo changed, the path in a checkout remained the same.
m1 is the point where the code was added with cvs module, and m2 where it was moved to the main tree. either m1 or m2 could be considered mergepoints, and represented with a merge commit in git and the tags represent a state that matches history as it happened
How? I agree in principle as far as m1 is concerned, but what could possible be merged at m2? The tree is the union of all files in the main tree and in all modules, so it looks exactly the same before and after m2.