将 Git 子存储库添加到 Mercurial

发布于 2024-09-29 11:19:35 字数 655 浏览 4 评论 0原文

我一直在尝试使用 bitbucket 设置一个项目,该项目的项目依赖项托管在 github 上。使用 Hg-Git Mercurial 插件我几乎可以做到这一点。

但到了推动的时候,事情就变得麻烦了。

Mercurial 子存​​储库 的文档指出:

2.4推送

当您推送时,Mercurial 将自动尝试首先推送当前存储库的所有子存储库。这将确保子存储库中的新变更集在被顶级存储库引用时可用。

但这会导致一个大问题,因为我不想推送所有子存储库(为什么要推送?)——我只有对它们的读取权限,所以 github 不允许这样做。只需将主存储库推送到远程服务器,但我不知道该怎么做。 hg 想要控制并推送所有子存储库,无论是否有更改。有没有办法绕过这个功能

唯一需要推送的是 .hgsub.hgsubstate。一旦它们通过替代路径推送(更新到子存储库不存在的变更集),就可以更新并从远程存储库中提取更改,但如果我要在变更集上再次推送子存储库中,整个考验会重演。

I've been trying to set up a project using bitbucket which has project dependencies hosted on github. Using the Hg-Git Mercurial plugin I am able to almost get there.

But when it comes time to push, things become troublesome.

The documentation for Mercurial subrepositories states:

2.4 Push

Mercurial will automatically attempt to first push all subrepos of the current repository when you push. This will ensure new changesets in subrepos are available when referenced by top-level repositories.

But this causes a big issue since I don't want to push all the subrepositories (why would I?) — I only have read access to them, so github won't allow it. Only the main repository needs to be pushed to the remote server, but I can't figure out how to do it. hg wants to take control and push all subrepositories, regardless of whether or not there are changes. Is there some way to bypass this feature?

The only things which need to be pushed are .hgsub and .hgsubstate. Once they've been pushed via alternative routes (updating to a changeset where the subrepositories don't exist), it's possible to then update and pull the changes from the remote repositories, but if I were to push again whilst on a changeset with the subrepositories, the whole ordeal repeats itself.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

埋情葬爱 2024-10-06 11:19:35

为了供将来参考,mercurial 的开发分支(以及即将发布的 1.8 版本)现在支持本机 git subrepos。这种特殊情况的实现非常好,如果不知道远程存储库是否有当前提交,则来自根存储库的推送只会告诉 git 子存储库进行推送。

For future reference, the development branch of mercurial (and thus the upcoming 1.8 release) now supports native git subrepos. This particular case is implemented very nicely and a push from the root repository will only tell the git subrepo to push if its remote repository is not known to have the current commit.

梦在深巷 2024-10-06 11:19:35

由于 Mercurial 的推送方法,这是不可能的。这是一个设计错误。

最好的解决方案是更新到子存储库不存在的先前版本,然后推送。这将绕过 Mercurial 的限制并上传必要的 .hgsub.hgsubstate 文件。这有点不方便,但这是迄今为止我发现的让 Mercurial 和 Git 相互协作的最佳方法。

也许将来 Hg-Git 将进行更新以自动处理此用例。

This isn't possible due to Mercurial's method of pushing. This is a by design error.

The best solution is to update to a previous revision where the subrepositories don't exist, and then push. This will bypass Mercurial's restriction and upload the necessary .hgsub and .hgsubstate files. This is a little inconvenient, but is the best way I've found so far to get Mercurial and Git to work with each other.

Perhaps in the future Hg-Git will be updated to handle this use case automatically.

等风来 2024-10-06 11:19:35

我认为你应该使用多个存储库; DVCS 这样效果更好。

例如,创建一个包含来自 github 的依赖项的存储库。您只需拉入该存储库即可获得更改,而无需推送。
然后您的项目就有了另一个用于开发的存储库。在这里你可以自由地做任何你想做的事。然后链接到您自己的 hg 存储库以获取依赖项。

如果我正确理解了你的问题以及你想要做什么:)

I think you should use multiple repositories; DVCS works better like that.

For example, make one repository that contains the dependencies from github. You only pull in that repo to get the changes, you never push.
Then you have another repository for your project, for development. Here you are free to do whatever you want. And then you link to your own hg repo for the dependencies.

That's if I correctly understood your problem and what you're trying to do :)

一身骄傲 2024-10-06 11:19:35

如果子存储库中没有传出变更集,则“推送”实际上除了从远程存储库检索最新变更集列表之外什么也不做。因此,推送的实际“推送”部分不会发生。我已成功使用只读 BitBucket 存储库作为子模块。

If you have no outgoing changesets in the subrepository, the 'push' should actually do nothing other than retrieve the latest changeset list from the remote repository. Therefore, the actual 'push' part of the push won't happen. I've successfully used read-only BitBucket repositories as submodules.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文