将 $HOME 放入 git 而不是符号链接点文件是否存在陷阱?

将 $HOME 放入 git 而不是符号链接点文件是否存在陷阱?

多年来我一直将我的整个$HOME目录都检查到颠覆中。这包括我所有的点文件和应用程序配置文件、许多脚本、工具和黑客、我喜欢的基本主目录结构、不少奇怪的项目和一个随机数据仓库。这是一件好事。虽然它持续了。

但事情已经失控了。几十个系统的基本检查都是相同的,但并非所有这些东西都适合我的所有机器。它甚至不能很好地与不同的发行版配合使用。

我正在清理房子——将数据分离出它所属的位置,将一些脚本拆分为单独的项目,修复应该自动化的内容中的一些损坏的链接,等等。

我的目的是替换subversiongit顶级签出$HOME,但我想将其削减为我希望在所有系统上拥有的东西,这意味着点文件、一些目录和一些基本的自定义脚本。

在网上阅读时,很多人似乎都使用符号链接方法来执行此操作:克隆到子目录中,然后从$HOME存储库中创建符号链接。$HOME十多年来,我一直处于完全版本控制之下,我不喜欢这种方法的想法,而且我不明白为什么人们似乎如此反对直接结账方法。git作为顶级结帐,我是否需要了解特定的陷阱$HOME

PS:部分作为良好编码的练习,我还计划在 GitHub 上公开我的 root checkout。可怕的是,我允许在文件中收集多少安全敏感信息,而这些信息本应不假思索地共享! WiFi 密码、未加密的 RSA 密钥等。哎呀!

答案1

是的git,在考虑管理与 . 无关的主目录时,至少存在一个主要陷阱subversion

默认情况下,Git 既贪婪又递归

Subversion 会天真地忽略它不知道的任何内容,并且当它到达它不知道的文件夹(或属于不同的存储库)时,它会停止处理从结帐向上或向下的文件夹。另一方面,Git 不断递归到所有子目录,由于命名空间问题,使得嵌套签出变得非常复杂。由于您的主目录很可能也是您签出和处理其他各种 git 存储库的地方,因此将您的主目录放在 git 中几乎肯定会让您的生活变得一团糟。

事实证明,这是人们将点文件签入独立文件夹然后符号链接到其中的主要原因。当您在$HOME.虽然如果将你的家检查为颠覆,这纯粹是一个偏好问题,但如果使用 git,这就成为一个必然问题。

然而,还有一个替代解决方案。 Git 允许一种称为“假根”的东西,其中所有存储库机器都隐藏在一个备用文件夹中,该文件夹可以与签出工作目录物理分离。结果是 git 工具包不会感到困惑:它甚至不会看到您的存储库,只能看到工作副本。通过设置几个环境变量,您可以在管理主目录时提示 git 在哪里可以找到所需的内容。如果没有设置环境变量,没有人会更明智,您的家看起来就像是经典的文件自我。

为了让这个技巧变得更流畅,有一些很棒的工具。这vcs-home 邮件列表似乎是事实上的起点,“关于”页面方便地总结了操作方法和人们的经验。一路上有一些漂亮的小工具,比如VCSH,先生。如果你想将主目录直接保留在git中,vcsh几乎是必备工具。如果您最终在幕后将主目录拆分为多个存储库,请结合vcsh使用mr快速且不太肮脏的方式来一次性管理所有目录。

答案2

我不希望我的整个主目录签入版本控制,因为这意味着我进入的每个子目录都将具有我的主目录的版本控制上下文。在这种情况下,类似的命令git checkout会有一个实际的操作,如果我不小心从错误的目录运行某些东西,无论该东西是git它本身还是调用 git 的脚本,都会导致问题。

它还使得更有可能向存储库添加您不想要的内容,当您签入所有内容时这不会是问题,但现在变成了问题。如果你不小心添加了私钥文件(可能是出于习惯)并将其推送到 github 该怎么办?

话虽如此,我认为主要的缺点并不是真正的技术性的——只是想让我摆脱自己的束缚。

至于符号链接:您可以将存储库克隆到子目录中,并使用一个脚本来更新任何需要更新的符号链接。不过,此脚本所需的维护量可能会超过拥有它的好处;符号链接可能会减少工作量。

使用符号链接,您还可以轻松地添加特定于发行版(甚至特定于主机)的内容,并将其签入 git。您的符号链接更新脚本将忽略用于不兼容平台或不同主机的文件,并且仅更新适当的文件。

就像是:

HOMEREPO=$HOME/homerepo
HOST=$(hostname)
UNAME=$(uname)

for dotfile in $HOMEREPO/shared/* $HOMEREPO/host-$HOST/* $HOMEREPO/uname-$UNAME/*
do
    target=$HOME/$(basename $dotfile)
    [ ! -r $target ] && ln -s $dotfile $target
done

就我个人而言:我使用符号链接,并且不使用符号链接目录;仅其中的文件。这使我可以灵活地在这些目录中进行站点本地更改(即添加/删除文件)。在新系统上设置我的帐户非常繁琐,因为我必须手动重新创建所有符号链接。

答案3

给出另一个观点:我从某个时候起就将 $HOME 放在 git 下,并且没有发现任何缺点。我显然没有将这个 git repo 同步到 github;我使用具有私人存储库的服务。我也不将任何媒体文件、下载或包置于 git 控制之下。

  • git status是一种“要做、要清理”的清单。

  • 我有一个~/tmp临时的东西,它被 gitignored 了。

  • 我喜欢看到git status任何最近安装的软件都敢添加到我的 $HOME 中,并且经常删除这些文件,甚至卸载罪魁祸首。

  • 我手动将真正有用的本地文件和目录添加到.gitignore,这样可以实现“知道安装时要做什么”的好处。

  • 如果我构建一个新的虚拟机或安装一台新的 PC,我只需将我的远程主目录克隆到 $HOME,并立即拥有我需要的一切。

  • 像 vim 插件 vundle 这样的东西不再需要了。

我不喜欢复杂性。当我调整任何 rcfile 时,我只是这样做,提交并推送。然后,作为反射,我每隔一天 git pull in $HOME ,并且始终拥有最新的配置。就是这么简单。

目前处于此状态的机器:家用笔记本电脑、工作 PC、工作虚拟机以及 3 或 4 台远程服务器。

答案4

这里有一个:如果您尝试执行此操作git rebase -i --root并且已签入.gitconfig存储库中的第一个提交,git 将暂时删除该.gitconfig文件,这反过来将使其无法完成变基操作,因为它需要您的姓名和电子邮件来完成那些存储在该文件中的内容。

您可以再次配置它们并执行操作git rebase --continue,但是在我这样做并完成 rebase 操作之后,我的 git 存储库获得了一个空提交,在该提交之前没有提交消息,该提交之前是存储库中的第一个提交,我不知道如何摆脱。

我不知道如果您git rebase -i <commit>这样做会发生什么,并.gitconfig与之后的任何提交一起签入<commit>

也许最简单的解决方案是避免添加.gitconfig到存储库中,而是将其列出在.gitignore.

相关内容