【问题标题】:How to prevent git from committing two files with names differing only in case?如何防止git提交两个名称不同的文件,以防万一?
【发布时间】:2017-04-30 10:58:04
【问题描述】:

我们在混合环境中开发 - 有些人在 Mac 上工作,有些人在 Linux 上工作。这有时被证明是一个挑战,因为那些在 Linux 上工作的人习惯于让他们的文件系统区分大小写,因此提交(意外或其他)多个不同的文件是没有问题的。 (例如 FileName.extfilename.ext

但是,当人们在 Mac 上查看存储库时,具有不区分大小写的文件系统意味着这两个文件(仅在大小写上有所不同)相互覆盖并造成普遍的破坏。

我知道有各种 git 设置可以帮助不区分大小写的文件系统上的人们更好地处理大小写更改(例如 core.ignorecase),但是这些并不能解决存储库中有两个不同文件的问题,只是不同分情况。

我意识到修复它的唯一方法是确保 Linux 人员不会首先提交两个不同的文件,以防万一。 -- 如果用户在区分大小写的文件系统上尝试提交会在不区分大小写的文件系统上相互混淆的文件,git 中是否有一些设置会弹出警告或错误?

【问题讨论】:

  • 注意this Unix & Linux SE post 包含一种在大多数 Linux 的目录中查找此类文件的方法,但未与 git 挂钩。 (因此它不会在文件提交之前运行,并且不仅限于提交的文件。)

标签: linux git macos case-sensitive case-insensitive


【解决方案1】:

没有内置任何东西(尽管应该有,毫无疑问)。你可以做的是提供一个 pre-commit 钩子来验证所有名称是否正常,如果不正常则阻止提交。

这个钩子只需要在 Linux 机器上运行(虽然让它在 Linux 和 Mac 上运行很容易,但问题在于 Windows 及其默认的贫乏工具箱)。您可能想将它添加到一个分支中,并为 Linux 人员提供有关设置的说明。

您可能还想检查分支names,如git pre-commit or update hook for stopping commit with branch names having Case Insensitive match。 (有趣:这个问题的答案是我自己的;我忘记了。)

首先,让我们编写一个“检查大小写冲突”函数。这只是用大小写折叠排序的问题(以便“helloworld”和“helloWorld”彼此相邻放置),然后使用uniq -di 打印任何重复的(在大小写折叠之后)字符串,但没有非重复:

sort -f | uniq -di

如果这产生任何输出,这些都是“坏名”。让我们在一个临时文件中捕获输出并检查它的大小,以便我们也可以将它们打印到标准输出:

#! /bin/sh

TF=$(mktemp)
trap "rm -f $TF" 0 1 2 3 15
checkstdin() {
    sort -f | uniq -di > $TF
    test -s $TF || return 0   # if $TF is empty, we are good
    echo "non-unique (after case folding) names found!" 1>&2
    cat $TF 1>&2
    return 1
}

现在我们只需要在将要提交的文件上使用它,也许还可以在分支名称上使用它。前者用git ls-files列出,所以:

git ls-files | checkstdin || {
    echo "ERROR - file name collision, stopping commit" 1>&2
    exit 1
}

您可以想象一下,使用git diff-index --cached -r --name-only --diff-filter=A HEAD 仅检查添加的文件,允许现有的案例冲突继续,和/或尝试跨多个分支和/或提交检查内容,但是变得困难。

将以上两个片段组合成一个脚本(并测试),然后简单地将其复制到一个名为.git/hooks/pre-commit 的可执行文件中。

检查分支名称有点棘手。这确实应该在您创建分支名称时发生,而不是在您提交时发生,并且在客户端上做得非常好是不可能的 - 它必须在具有适当全局视图的集中式服务器上完成。

这是一种在服务器上以预接收脚本、shell 脚本而不是 Python 执行此操作的方法(如链接答案中所示)。不过,我们仍然需要 checkstdin 函数,并且您可能希望在更新挂钩而不是预接收挂钩中执行此操作,因为您不需要拒绝 整个 推送,只需一个分支名称。

NULLSHA=0000000000000000000000000000000000000000 # 40 0s

# Verify that the given branch name $1 is unique,
# even IF we fold all existing branch names' cases.
# To be used on any proposed branch creation (we won't
# look at existing branches).
check_new_branch_name() {
    (echo "$1"; git for-each-ref --format='%(refname:short)' refs/heads) |
      checkstdin || {
        echo "ERROR: new branch name $1 is not unique after case-folding" 1>&2
        exit 1  # or set overall failure status
    }
}

while read oldsha newsha refname; do
    ... any other checks ...
    case $oldsha,$refname in
    $NULLSHA,refs/heads/*) check_new_branch_name ${refname#refs/heads/};;
    esac
    ... continue with any other checks ...
done

【讨论】:

  • 不同意这是 git 一直要处理的问题,因为它涉及到系统特定文件名约定的每个排列的逻辑。无论如何都赞成高质量的响应。
  • @JoeAtzberger:确实,这里有无穷无尽的问题。但我认为我们可以通过通用的“文件名映射”解决方案(在 Git 本身中)和简单的案例冲突检测和操作(作为 Git 支持的 3rd-party contrib 代码,有点像邮件接收脚本的演变方式)。我想到的“文件名映射”相当于.gitattributes.git/info/exclude 之类的东西,可能存储在.git/info 中,上面写着“用路径Y 替换路径X”。第三方代码将构建地图,checkout 将使用它。
  • 稍微更详细一点,映射实际上将应用于进出索引的文件转换,与清理和涂抹过滤器以及行尾 (CR/LF) 转换的方式相同过滤器完成。这将允许 Windows 或 Mac 用户提取、修改和提交他们实际上无法访问其名称的文件。这不适合长期普遍使用,除非它被证明是实用的(似乎不太可能)。
猜你喜欢
  • 2017-12-08
  • 1970-01-01
  • 2021-09-16
  • 1970-01-01
  • 1970-01-01
  • 2010-09-08
  • 2017-08-08
  • 2014-08-04
  • 2014-03-22
相关资源
最近更新 更多