在提交时加密添加到 Mercurial 存储库的文件

发布于 2024-09-24 12:25:45 字数 335 浏览 2 评论 0原文

读过 this git 过去的问题后,我会想问是否存在类似的东西,但

  1. 可以在每台机器上以编程方式完成(文件列表);
  2. 为 Mercurial 工作。

原因是我想在我的公共 dotfiles 存储库中包含一些以明文形式存储密码的配置文件。我知道我可以为 hg(1) 编写一个环绕脚本,但我想知道是否有其他方法,只是出于好奇。

谢谢。

Having read this past question for git, I would like to ask if there exists something like that, but

  1. can be done programmatically (file list) on each machine;
  2. works for Mercurial.

The reason for this is that I would like to include in my public dotfiles repository some configuration files that store password in plaintext. I know I could write a wraparound script for hg(1) but I would like to know if there are alternative approaches, just for the sake of curiosity.

Thank you.

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

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

发布评论

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

评论(2

毁虫ゝ 2024-10-01 12:25:45

您可以根据需要使用一对 pre-commitpost-update 挂钩来加密/解密。请参阅 http://hgbook.red-bean.com /read/handling-repository-events-with-hooks.html 了解更多详细信息。

然而,值得指出的是,如果您在存储库中存储加密文本,您将无法创建有意义的差异 - 本质上所有内容都将像二进制文件一样,但压缩性也很差。

You could use a pair of pre-commit and post-update hooks to encrypt/decrypt as necessary. See http://hgbook.red-bean.com/read/handling-repository-events-with-hooks.html for more details.

However, it's worth pointing out that if you're storing encrypted text in your repo you'll be unable to create meaningful diffs -- essentially everything will be like a binary file but also poorly compressible.

淡莣 2024-10-01 12:25:45

Mercurial 有一个过滤系统,可让您在文件被破坏时对其进行修改从存储库中读取或写回。如果您有一个像 SSH 代理这样的程序正在运行,可以让您进行非交互式加密和解密,那么这可能是可行的。

正如 Ryan 指出的那样,这必然会导致存储库更大,因为文件的每个加密版本看起来都与以前的版本完全不同。 Mercurial 会检测到这一点并存储未压缩的版本(加密文件无论如何都无法压缩)。由于您将其用于点文件,因此您可以忽略空间开销,但如果您将以加密形式对更大的文件进行版本控制,则需要考虑这一点。

请将您的经验发邮件到 Mercurial 邮件列表,以便其他用户可以从中受益他们也是。

Mercurial has a filter system that lets you mangle files when they are read from the repository or written back. If you have a program like the SSH agent running that lets you do non-interactive encryption and decryption, then this might just be workable.

As Ryan points out, this will necessarily lead to a bigger repository since each encrypted version of your files will look completely different from the previous version. Mercurial detects this and stores the versions uncompressed (encrypted files cannot be compressed anyway). Since you will use this for dotfiles, you can ignore the space overhead, but it's something to take into consideration if you will be versioning bigger files in encrypted form.

Please post a mail to Mercurial mailing list with your experiences so that other users can benefit from them too.

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