Hi, Quoting "Greg Stark" <st...@enterprisedb.com>:
This is all completely irrelevant to the CVS import.
To the CVS import it is, yes. After all, CVS has no notion of renaming files. But my example is about renaming with git *after* the conversion. Git *does* support renaming (to some extent). However, it fails as explained if you feed it with "corrupt" data (the corruption being the missing link between the two added files - after a rename, git simply has no chance of knowing it should be the same file).
I don't think we've ever renamed files because CVS can't handle it cleanly.
Yes, that applies to the past. But I think we *are* going to rename files *after* the switch, because git *can* handle it cleanly - given a correct import.
If that defect would only affect historic information, I'd not be half as pestering as I am. But it's such delayed effects which might surprise you years after the cause, which make me nervous.
It does sound to me like we really ought to have merge commits marking the bug fixes in old releases as merged in the equivalent commits to later branches based on Tom's commit messages.
Now, I don't know how you got to that conclusion, but I absolutely agree ;-) 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
