Hi,
Quoting "Greg Stark" <stark@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