Hi, I think I've discovered a bug in git-cvsexportcommit: where a file has been removed from a CVS repository, it linger in the Attic and CVS perversely reports them as 'no file X' with status 'Up-to-date'. git-cvsexportcommit then prevents files from being added with the same name. I have a patch against the current version of git's repository which seems to fix the problem. This is actually three commits: - the fix, - an extension to t9200-git-cvsexportcommit.sh to test the fix - EOL whitespace-removal I'm hesitant to send all three as separate emails, even though the SubmittingPatches document seems to imply I should - should I squash them into one commit? Anyway - to replicate the issue, create a CVS repository, add a file "x", then remove it. Then create a git repository tracking this CVS repository using git-cvsimport. Pull the changes from CVS, then try adding a file "x", and exporting it back to CVS. When I do that I get this error: File x is already known in your CVS checkout -- perhaps it has been added by another user. Or this may indicate that it exists on a different branch. If this is the case, use -f to force the merge. Status was: Up-to-date Exiting: your CVS tree is not clean for this merge. at /usr/lib/git-core/git-cvsexportcommit line 275. When comitting, I also sometimes get warnings like this: Huh? Status reported for unexpected file 'no file y' These seem to be ignorable, but I think they also result from the above issue. Cheers, Nick -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html