Hi,

Quoting "Marko Kreen" <mark...@gmail.com>:
Btw this conversion seems broken as it contains random merge commits.

Well, that's a feature, not a bug ;-)

When a commit adds a file to the master *and* then to the branch as well, cvs2git prefers to represent this as a merge from the master branch, instead of adding the file twice, once on the master and once on the branch.

This way the target VCS knows it's the *same* file, originating from one single commit. This may be important for later merges - otherwise you may suddenly end up with duplicated files after a merge, because the VCS doesn't know they are in fact the same.

(Okay, git assumes two files to have the same origin/history as long as they have the same filename. But just rename one of the two, and you are have the same troubles, again).

Also note that these situations occur rather frequently in the Postgres CVS repository. Every back-patch which adds files ends up as a merge. (One could even argue that in the perfect conversion *all* back-patches should be represented as merges, rather than as separate commits).

parsecvs managed to do it without them.

Now, I'm not calling it broken, but cvs2git's output is arguably better in that regard.

As you certainly see by now, conversion from CVS is neither simple nor unambiguous.

Regards

Markus Wanner

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to