I'm curious what's the best practice of keeping your occasional contributions to an OSS project in git (e.g., on github/bitbucket/gitlab), whilst the upstream is exclusively CVS.
My take is that it's very convenient to simply commit CVS/{Entries,Repository,Root} directly into git, and then at any time and from any box, you can simply checkout your git repo (w/ git), and then update from the real upstream with cvs up, which is exactly what I do with my OpenBSD ports-readmes fork, as well as mdocml.
However, I've noticed that most people are quite surprised and puzzled to see these CVS files within these git repositories on my GitHub, supposedly thinking that it's some sort of an oversight on my part. Additionally, reyk's httpd, for example, doesn't have such a setup, either, even though he apparently usually updates it from upstream in bulk, without preserving the log from the upstream, either.
Am I missing something here? I feel like having CVS/{Entries,Repository,Root} within your git repository is a great idea, yet I've never seen anyone else doing it. Why?
I feel like having CVS/{Entries,Repository,Root} within your git repository is a great idea, yet I've never seen anyone else doing it. Why?
It seems a good idea, but it also mixup metadata (CVS reference) with data (your files of the repo).
That is why git-svn, for instance, do memorize that same kind of reference in git configuration (local config file, not part of the repo).
Anyone wanting to contribute to the upstream SVN repo need to to a git svn clone again.
An intermediate solution would be to explain in the README that a user need to create those CVS reference files once the repo is cloned, should he/she wishes to contribute back to (CVS) upstream.
来源：https://stackoverflow.com/questions/37585385/whats-the-best-practice-of-going-git-when-upstream-is-100-cvs