Git预提交钩子+坞=不同的git状态

Question

我想在预提交git钩子中运行一个脚本。我想要那个脚本从码头图像中运行。这个预提交钩子的示例代码：

# pre-commit hook
#!/bin/bash
repo_root=$(git rev-parse --show-toplevel)
docker run -v ${repo_root}:${repo_root} -w ${repo_root}  <my_docker_image> <path_to_my_script.py>

my_script.py内部运行git status以确定要在预提交钩子中处理哪些文件。

问题:当我运行git status时，在预提交钩子中的输出与在码头容器中的输出不同。示例：

# pre-commit hook
#!/bin/bash
git status
echo "------------------------------------"
repo_root=$(git rev-parse --show-toplevel)
docker run -v ${repo_root}:${repo_root} -w ${repo_root} <my_docker_image> git status

我希望通过运行git commit --all，在码头容器中运行git status，我可以看到所有的更改。

然而，更改并不是在码头容器内进行的。我之前编写的代码打印如下：

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    modified:   tools/git-hooks/pre-commit
------------------------------------
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   tools/git-hooks/pre-commit

换句话说:在坞内，git status不会检测到--all选项；更改不会被分阶段进行。

我遗漏了什么？

Answer 1

TL;DR:加-e GIT_INDEX_FILE。但是，您可能希望允许额外的Git变量。或者，您可以简单地禁止这样的提交，或者使用完全不同的机制(参见下面描述中的最后几段)。

描述

当您使用git commit --all时，Git会创建一个临时索引来保存暂存的文件，因为它们还没有在正常的索引中分阶段进行。如果提交成功，这个临时索引最终将成为常规索引，。在那之前，这不是常规指数。

现在，您的预提交脚本包括行：

docker run -v ${repo_root}:${repo_root} -w ${repo_root} ...

-v选项在运行docker映像的子进程中挂载文件系统，-w将其设置为工作目录。但是，docker命令过滤子进程中的环境，去掉所有未使用--env或--env-file显式启用的可疑变量( --env的简称为-e)。

documentation page has a section on environment variables，包括：

GIT_INDEX_FILE 此环境允许指定备用索引文件。如果未指定，则使用默认的$GIT_DIR/index。

当git commit --all设置一个临时索引时，它使用这个环境变量来引导它的所有子命令来查看临时索引，而不是$GIT_DIR/index。

值得注意的是，Git也设置了$GIT_DIR，但它可能已经将其设置为.，因此当docker run将其去掉时，Git将从当前工作目录开始查找存储库，您通过-w将其设置为存储库根目录--因此剥离.是无害的。尽管如此，您可能还是想考虑传递Git的所有环境变量。但是，这并不像盲目传递文档中列出的所有内容那样简单:例如，如果有一个需要导出的GIT_ALTERNATE_OBJECT_DIRECTORIES路径，那么您也需要使用更多的-v选项将该路径中的每个元素挂载到停靠实例中。

幸运的是，当GIT_INDEX_FILE设置在这个特定的点时，它被设置为表单.git/temporary-name的路径名，因此不需要安装额外的文件系统来将Git临时索引放到正在运行的映像中。这是因为这个名称将被重命名为.git/index，Git希望确保重命名可以作为原子文件系统操作来完成，这要求它与.git本身存在于同一个挂载点上。实际上，对于git commit --all来说，它只是.git/index.lock，尽管git commit --only使用了其他名称：--only表单需要多个临时索引文件，而用于提交的并不是成功时将成为正常索引的文件。

最后--这完全独立于Docker--请注意，可以要求Git提交与不匹配的分阶段文件，而现在工作树中的文件是不匹配的。例如，使用git add -p，很容易在索引中存储一个文件的版本，该版本只存在HEAD版本和工作树版本之间的一些差异。我猜您计划让docker环境对提交的内容进行某种类型的测试。这很好，但请注意，“要承诺的”并不一定是“工作树中的内容”。当使用--all和临时索引时，临时索引包含要提交的内容，而该临时索引只是从工作树构建的，因此它们将匹配；但是当不使用--all和使用真正的索引时，或者当使用不同的临时索引使用--only时，“要提交的内容”并不一定与工作树匹配。

编写一个很好的预提交钩子，可以看到“要提交什么”，这是很棘手的，但也不是不可能的。一种方法是将索引中的任何内容提取到与当前工作树无关的临时目录中。然后，您可以在临时目录上运行测试系统，不受存储库本身的干扰，也不受当前工作树的干扰。如果您在预提交脚本中这样做，您可以(通过-v和-w)挂载这个临时目录，而不必担心在docker映像中运行任何Git命令。

旁注：#!行

您的示例可以为StackOverflow发布目的进行修改，但在以下内容中：

# pre-commit hook
#!/bin/bash
git status

#!线已经变得无用了。这些行必须是脚本的第一行。原因是内核(Linux，或派生它的Unixes )运行这样的脚本的方式是检查文件的前几个字节。如果前两个字节是#!，则第一行的其余部分--从第一个换行符到第一个换行符的所有内容(在一定的合理限制范围内)--都被用作解释器的名称，也许还可以作为该解释器的选项。内核然后运行解释器，而不是脚本，从#!行传递选项(如果有的话)，然后是脚本的名称。

但是，如果第一行没有以#!开头，内核只是拒绝直接运行文件(execve在ENOEXEC中失败)。shell发现错误，检查文件本身，并确定文件是否为shell脚本.如果是这样的话，shell本身运行文件。这里的主要问题是shell可能选择错误的shell来运行文件。使用带有正确解释器名称的#!行可以避免这种情况。