git子模块中的本地git配置

我的存储库结构：

repo_a
└── repo_b
    └── .gitconfig

repo_b

是一个子模块。

.gitconfig

：

[alias]
    b = branch

如何添加

.gitconfig

的路径，以便只有

repo_b

可以使用它

预期产出：

$ cd repo_a
$ git b
git: 'b' is not a git command. See 'git --help'.
$ cd repo_b
$ git b
* master

编辑#1：

来自@jthill和@bk2204的答案很好。
它们描述了如何使用以下命令访问子模块的配置文件：

git rev-parse --git-path config

我想指定我想要的内容。
我希望git跟踪

repo_b

中

.gitconfig

文件中的更改。这样，当仅克隆

repo_b

时，我也可以访问相同的

.gitconfig

@jthill的解决方案似乎是可行的。然而，它似乎也很容易出错，我必须为git中可能更改

.gitconfig

的每一个更改添加一个钩子。例如

git pull

，

git checkout

，

git merge

因此，我的问题将分为两部分：

如何跟踪

repo/.gitconfig

的更改并将其用作本地配置文件

如何在普通回购和子模块内实现上述功能

---

我认为这是不可能的：

在阅读中，似乎有两种可能的选择：

• 在子模块的根目录中创建名为

  config

  的文件
• 向超级项目的

  .gitmodules

  文件添加内容

我试图在这两个文件中添加别名，但别名没有生效

编辑：

事实上，现在我正在花时间思考，这是有道理的，因为git子模块的代码并不是按照从子模块中运行git命令的想法编写的，而是直接从超级项目运行git命令

---

如果您在子模块内为子模块运行git命令，则您没有使用子模块功能。在这种情况下，您最好在超级项目中创建一个正常的回购，并将其路径添加到超级项目的

.gitignore

文件中。不过，最好是从超级项目中学习处理子模块。

如果您正在寻找子模块的等价物

.git/config

，那么最简单的方法就是从

repo\b

中运行

git rev parse--git path config

。这是为本地存储库设置配置的最简单方法

您不能将

.gitconfig

文件放入存储库并期望它被使用；在存储库中共享配置是不安全的，所以Git不允许这样做

---

如果您想使用

git config

编辑本地配置，您可以将其更改为

repo_b

作为冒烟测试，您可以让人们使用repo do

cat .gitconfig >>$(git rev-parse --git-dir)/config

这将把您的配置附加到存储库设置中。为了更安全的版本

sed -si '/^# --repo-b-config--$/,/^# --repo-b-config--$/d; $r .gitconfig' \
        $(git rev-parse --git-dir)/config

在特殊文件的顶部和底部有

#--repo-b-config--

行

Git故意不允许fetch覆盖管理选择。没有办法让fetch篡夺任何东西。您的存储库是您的。你决定里面会发生什么，这意味着除非你自己为他们建造道路，否则没有人可以偷袭任何东西。您可以在签出时运行任意命令来更新本地配置或任何其他内容，但在您的存储库中，在您管理的每个存储库中（例如，包括您使用

git clone

或

git init

或

git子模块更新--init

创建的每个repo），您可以控制这些命令的内容

---

因此，如果您想在每次结账后运行上述

sed

，请将它（可能是一个固定版本）放入该回购协议的

挂钩/结账后

，您将得到您想要的。

出于安全考虑，我没有实现此功能

我决定在JSON中使用一个单独的配置文件，并将所需的值存储在那里。

---

因此，我可以在需要时解析配置文件，而不是使用git。

谢谢，这使查找配置文件变得更容易，但是，这并不能完全解决我的问题，请参阅我问题中的“Edit#1”。git不支持您所要求的，因为这是一个安全问题。Conffig可以包含要运行的任意程序，允许存储库发送配置将允许可以修改存储库的人在克隆存储库的任何人的系统上执行任意代码。谢谢，这使查找配置文件变得更容易。我确实认为，如果我能够覆盖所有相关的钩子，这可能会起作用。然而，正如我在问题的“编辑#1”中所指出的，如果我能找到一个不太容易出错的解决方案，我会更喜欢。Git并没有让这件事变得容易，因为这是一个坏主意。如果您想运行一个repo本地别名/脚本，请承认这就是您正在做的，然后去做。将git和它所管理的代码历史混为一谈会让人大吃一惊。是的，我最终决定不对我最初的问题使用这种方法