What's the best practice of going GIT when upstream is 100% CVS?

Question

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?

Hijack

One rather large problem with committing your CVS metadata is that it is specific to you and your checkout out version. The way I have done it is to add CVS to .gitignore. That way I can still use both git and cvs and the rest of the world just uses git with no idea that there is a cvs repo involved. – Mobcap

@BurhanAli, no, that's the whole point of cvs -- the CVS metadata is NOT specific to me, but it IS specific to my checkout version, which is the whole point, because it's the exact same version that's committed to git. I cannot see any benefit whatsoever in adding the whole CVS/ to .gitignore, because then the minute you clean up your local git checkout, CVS data will be irreparably gone. How's that better for anyone? If you don't believe me, try out github.com/cnst/mdocml, it should work as is with both git and cvs (after checking out with git first) on any modern system. – Hijack

Maybe it's an artefact of how cvs is being used then. I used the extssh method and so my Root files contained something like username@hostname:/repopath which would not be useful to others. I also didn't delete the directory because I was always actively working on it. Just think carefully about whether these files are useful to others and whether or not their presence will cause confusion. – Mobcap

@BurhanAli, even if your CVS/Root has to contain a username, uploading CVS/{Repository,Entries} would still make it possible to quickly set up Root (either in the file, or through arguments to cvs, or through env CVSROOT), on the other hand, if the Entries file is missing, it'll be quite non-trivial to find the exact point in upstream that your downstream is based upon. – Hijack

Answer 1

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.

Statist

Thing is -- git-cvs integration is rusty, so, mixing the old-style metadata with data seems like the best approach. And how would you even explain in README how to generate those CVS files? It's very non-trivial, as they have to reference the exact versions of what your repository is supposed to contain. – Hijack

@Hijack I agree, I was just trying to find an intermediate position, not suggesting to use git-cvs. I was using git-svn to illustrate why that kind of file is generally not in a git repo. – Statist

But I think that the intermediate solution you suggest is actually worse than any of the alternatives. Why even suggest it as a possibility, if it's not even doable per se? – Hijack

@Hijack Because normally, all this is managed by git-svn. If you don't have git-svn, you have to somehow explain what you want to do (ie, with your approach, explain why those CVS files are there) – Statist

i think you misunderstood my comment above -- it is specifically about your suggestion for a README to "create those CVS reference files", which seems about impossible – Hijack

@Hijack I did understood your comment. The README part of my answer stands: you have to explain something. Either my approach (that you won't select), or yours (where you mix metadata and data in the same repo). – Statist

But your approach doesn't even work, so, why even mention it? And with my approach, why exactly would it have to be explained explicitly in README? An extra README will only add confusion and an extra diff compared to upstream, so, why should one even bother with that? – Hijack