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.
either this point when the modules were added to the main repo, or the point when they were actually moved to the main tree can be regarded as a merge point which in git could be represented as a real merge commit.
what i mean is, that currently in cvs the history looks like:
P---M---P-t-M--P------M---P-t-M---------P---M---... (where P are commits to pike itself, M commits to external modules, and t are tags that are only made to the main repo)
while in reality what happened is:
M-------M--- \ m1---M-------M--- \ P-------P-T----P----------P-T------m2---P---M---...
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
greetings, martin.