>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.
  • CVS... Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum
    • ... Henrik Grubbstr�m (Lysator) @ Pike (-) developers forum
    • ... Peter Bortas @ Pike developers forum
    • ... Martin Bähr
      • ... Henrik Grubbstr�m (Lysator) @ Pike (-) developers forum
        • ... Martin Baehr
      • ... Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum
        • ... Martin Baehr
          • ... Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum
            • ... Martin Baehr
              • ... Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum
    • ... Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum
      • ... Stephen R. van den Berg

Reply via email to