On 6/2/09, Markus Wanner <mar...@bluegap.ch> wrote: > 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).
Not a problem for git I think - it assumes they are same if they have same contents... > 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). Well, such behaviour may be a feature for some repo with complex CVS usage, but currently we should aim for simple and clear conversion. The question is - do such merges make any sense to human looking at history - and the answer is no, as no VCS level merge was happening, just some copying around (if your description is correct). And we don't need to add noise for the benefit of GIT as it works fine without any fake merges. Our target should be each branch having simple linear history, without any fake merges. This will result in minimal confusion to both humans looking history and also GIT itself. So please turn the merge logic off. If this cannot be turned off, cvs2git is not usable for conversion. > > parsecvs managed to do it without them. > > > > Now, I'm not calling it broken, but cvs2git's output is arguably better in > that regard. Seems it contains more complex logic to handle more complex CVS usage cases, but seems like overkill for us if it creates a mess of history. > As you certainly see by now, conversion from CVS is neither simple nor > unambiguous. I know, thats why I'm discussing the tradeoffs. Simple+clear vs. complex+messy. :) -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
