什么'；当上游是100%CVS时，使用GIT的最佳实践是什么？

我很好奇，在git中（例如，在github/bitbucket/gitlab上）保留您偶尔对OSS项目的贡献的最佳实践是什么，而上游完全是CVS

简单地将

CVS/{Entries，Repository，Root}

直接提交到

git

，然后在任何时候从任何框中，您都可以简单地签出您的git repo（w/

git

），然后使用

CVS up

从真正的上游进行更新，这正是我所做的，也是

然而，我注意到，大多数人在我的GitHub上看到这些git存储库中的CVS文件时都感到非常惊讶和困惑，他们可能认为这是我的疏忽。此外，例如，他也没有这样的设置，尽管他显然通常会从上游批量更新，但也不会保留上游的日志

我是不是遗漏了什么？我觉得在您的git存储库中拥有

CVS/{Entries，Repository，Root}

是个好主意，但我从未见过其他人这样做。为什么?

我觉得在您的git存储库中使用CVS/{Entries，Repository，Root}是个好主意，但我从未见过其他人这样做。为什么?

这似乎是个好主意，但它也将元数据（CVS引用）和数据（您的repo文件）混为一谈

这就是为什么

git svn

，例如，在git配置（本地配置文件，而不是repo的一部分）中记住相同类型的引用的原因。
任何想要为上游SVN回购做出贡献的人都需要再次进行git SVN克隆

---

一个中间解决方案是在

自述文件中解释，一旦repo被克隆，用户需要创建这些CVS参考文件，如果他/她希望回馈（CVS）上游。
问题是——git-CVS集成已经过时，因此，将旧式元数据与数据混合似乎是最好的方法。您甚至会如何在自述文件中解释如何生成这些
CVS
文件？这非常重要，因为他们必须引用存储库应该包含的内容的确切版本。@cnst我同意，我只是想找到一个中间位置，而不是建议使用git cvs。我用git svn来说明为什么这种文件通常不在git回购中，但我认为你所建议的中间解决方案实际上比任何其他解决方案都要糟糕。如果它本身不可行，为什么还要把它作为一种可能性呢？@cnst因为通常情况下，所有这些都是由git svn管理的。如果你没有git svn，你必须以某种方式解释你想做什么（即，用你的方法，解释为什么会有这些CVS文件）我想你误解了我上面的评论——这是关于你关于自述文件“创建那些CVS参考文件”的建议，这似乎是不可能的，提交CVS元数据的一个相当大的问题是它特定于您和您的签出版本。我这样做的方式是将
CVS
添加到
.gitignore
。这样，我仍然可以同时使用git和cvs，而世界上的其他人只是使用git，而不知道涉及到cvs repo。@BurhanAli，不，这就是cvs的全部要点——cvs元数据不是特定于我的，而是特定于我的签出版本，这就是全部要点，因为它与承诺给git的版本完全相同。我看不到将整个
CVS/
添加到
.gitignore
中有任何好处，因为当您清理本地git签出时，CVS数据将不可修复地消失。这对任何人来说都更好吗？如果你不相信我的话，试试看，在任何现代系统上，git和cvs（先用git检查后）应该都能正常工作。也许这是当时cvs使用方式的人工制品。我使用了
extssh
方法，因此我的
Root
文件包含类似
username@hostname：/repopath
，这对其他人没有用处。我也没有删除这个目录，因为我一直在积极地处理它。请仔细考虑这些文件是否对其他人有用，以及它们的存在是否会引起混淆。@BurhanAli，即使您的
CVS/Root
必须包含用户名，上载
CVS/{Repository，Entries}
仍可以快速设置
Root
（在文件中，或者通过
cvs
的参数，或者通过
env CVSROOT
），另一方面，如果
条目
文件丢失，那么在上游找到下游所基于的确切点将非常重要。