git - Git预提交钩子(Hook)+ docker =不同的git状态

Question

我想在预提交的git钩子(Hook)中运行脚本。我希望该脚本从docker镜像中运行。此预提交挂钩的示例代码:

# 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时，预提交挂钩中 git commit --all的输出与docker容器中的不同。
例:

# 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

我希望通过在docker容器中运行 git commit --all和 git status可以看到所有更改已分阶段进行。

但是，更改不会在docker容器内进行。我之前编写的代码显示以下内容:

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

换句话说:在docker内部， 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)。

top level git documentation page has a section on environment variables包括:

GIT_INDEX_FILE

This environment allows the specification of an alternate index file. If not specified, the default of $GIT_DIR/index is used.

当git commit --all设置临时索引时，它使用此环境变量来指示其所有子命令查看临时索引，而不是$GIT_DIR/index。

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

幸运的是，在此特定位置设置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与其他临时索引​​一起使用时，“要提交的内容”不一定与工作树匹配。

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

旁注:#!行

您的示例可能出于StackOverflow发布目的而被修改，但是在:

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

#!行变得毫无用处。这些行必须是脚本的第一行。原因是内核(Linux或从中派生该脚本的Unix)运行这样的脚本的方式是检查文件的前几个字节。如果前两个字节是#!，则将第一行的其余部分(在一定的合理范围内)到第一条换行符的所有内容都用作解释器的名称，以及该解释器的选项。然后，内核运行解释器(而不是脚本)，从#!行(如果有)中传递选项，然后传递脚本的名称。

但是，如果第一行不是以#!开头，则内核仅拒绝直接运行该文件(execve失败，并显示ENOEXEC)。 shell 程序发现错误，检查文件本身，并确定该文件是否为 shell 程序脚本……如果是，则 shell 程序本身将运行该文件。这里的主要问题是 shell 程序可能选择了错误的 shell 程序来运行文件。使用正确的解释器名称的#!行可以避免这种情况。