我通常从macOS提交一个项目，我没注意到前导和尾随空间是偶然嵌入文件夹名称的，但最近我试图从Windows克隆repo， 我收到这个错误：
fatal: cannot create directory at 'FolderName /SubFolderName'
warning: Clone succeeded, but checkout failed.
有没有办法从Windows成功结帐而无需从Mac修改？如何防止导致Windows中检出失败的前导和尾随空格？有没有办法强制Finder突出显示macOS中的所有前导或尾随空格？甚至更好：出于兼容性目的拒绝它们？
答案 0 :(得分：2)
最简单的方法是在MacOS中重命名它们。但你也可以使用低级命令在Windows中修复它：
git ls-tree HEAD:<parent dir>或git ls-tree HEAD如果目录在顶层，它会打印类似于＆＃34; 040000树df2b8fc99e1c1d4dbc0a854d9f72157f1d6ea078 invalid_dir＆＃34; git update-index --add --cacheinfo 040000,df2b8fc99e1c1d4dbc0a854d9f72157f1d6ea078,valid_dir git rm -r --cached 'invalid_dir ' git commit -m 'Rename invalid direct' git reset --hard（注意：我假设您在此实例中尚未完成任何工作，因此没有任何损失）答案 1 :(得分：0)
与先前的回答相比略有改进。
前提条件：您有一个git存储库，克隆成功，而检出失败。工作目录已部分填充，您尚未在其中完成任何工作。
git reset --hard或git restore -s@ -SW -- <some sub folder>。前者尝试修复您的部分填充的工作目录，一旦遇到第一个无效文件或目录，它将失败。如果重置成功，则继续执行步骤7。如果git reset命令花费很长时间，则可以在子目录上使用git restore命令，一个接一个地修复。它还列出了无效文件，但不会在第一个文件中止。git ls-tree HEAD:<parent dir>。输出应包含040000 tree df2b8fc99e1c1d4dbc0a854d9f72157f1d6ea078 <invalid name> git update-index --add --cacheinfo 040000,df2b8fc99e1c1d4dbc0a854d9f72157f1d6ea078,<new valid name> git rm -r --cached '<old invalid name>' git commit -m 'Fixed filenames.' git reset --soft HEAD~5和git commit -m "Fixed filenames." 答案 2 :(得分：0)
在 MacOS 上，在 Git 2.31（2021 年第一季度）之前，克隆后的 git restore（新 checkout）可能会失败：
当命令从子目录启动时，它们可能必须将子目录的路径（称为前缀并从 $(pwd) 中找到）与跟踪的路径进行比较。
在 macOS 上，$(pwd) 和 readdir() 生成分解路径，而跟踪路径通常被归一化为预组合形式，导致不匹配。
已通过采用与规范化命令行参数相同的方法来解决此问题。
请参阅 commit 5c32750 的 Torsten Bögershausen (tboegi)（2021 年 2 月 3 日）。
（2021 年 2 月 12 日在 Junio C Hamano -- gitster -- 被 commit 8b25dee 合并）
MacOS：precompose_argv_prefix()报告人：丹尼尔·特罗格
帮助：菲利普·布莱恩
签字人：Torsten Bögershausen
以下序列导致在 MacOS 下运行的“BUG”断言：
DIR=git-test-restore-p
Adiarnfd=$(printf 'A\314\210')
DIRNAME=xx${Adiarnfd}yy
mkdir $DIR &&
cd $DIR &&
git init &&
mkdir $DIRNAME &&
cd $DIRNAME &&
echo "Initial" >file &&
git add file &&
echo "One more line" >>file &&
echo y | git restore -p .
Initialized empty Git repository in `/tmp/git-test-restore-p/.git/`
BUG: [`pathspec.c`](https://github.com/git/git/blob/5c327502dbf7a27c8784c20037851206a87857c1/pathspec.c):495:
error initializing `pathspec_item`
Cannot close git diff-index --cached --numstat
[snip]
命令 git restore(man) 从 Git 存储库内的目录运行。
Git 需要将 $CWD 分成两部分：存储库的路径和“其余部分”（如果有）。
“其余部分”成为后来在路径规范代码中使用的“前缀”。
例如，“/path/to/repo/dir-inside-repå”会将“/path/to/repo”确定为存储库的根目录，即找到配置文件 .git/config 的位置。
其余部分成为前缀（“dir-inside-repå”），路径规范机制从这里扩展“.”，稍后会详细介绍。
如果存在分解形式（使分解像这样可见），“dir-inside-rep°a”与“dir-inside-repå”不匹配。
Git 命令需要：
core.precomposeunicode”第一次提交，76759c7（Mac OS 上的 git 和预先组合的 unicode，2012-07-08，Git v1.7.12-rc0 -- merge 列在 batch #6 中）git on Mac OS 和预组合的 unicode 寻址 (a) 和 (b)。
对 precompose_argv() 的调用已添加到 parse-options.c 中，因为在编写补丁时，这似乎是一个好地方。
不使用解析选项的命令需要自己做 (a) 和 (b)。
命令 diff-files、diff-index、diff-tree 和 diff 在 commit 90a78b8 中学习了 (a) 和 (b) (diff: run参数通过 precompose_argv, 2016-05-13, Git v2.9.0-rc0 -- merge) "diff: run arguments through precompose_argv"
使用分解代码点导致分解文件名的分支名称（或一般引用）已在 commit 8e712ef 中得到修复（Honor core.precomposeUnicode in more place, 2019-04-25, Git v2.22.0-rc1 -- merge) “在更多地方尊重 core.precomposeUnicode”
上面的错误报告显示了两件事：
解决方案：precompose_argv() 现在处理前缀（如果需要），并重命名为 precompose_argv_prefix()。
在这个函数内部，配置变量 core.precomposeunicode 像以前一样被读入全局变量 precomposed_unicode,。
如果之前已阅读过 precomposed_unicode，则跳过此阅读。
预组合 unicode 的原始补丁 76759c7，将 precompose_argv() 放入 parse-options.c
现在也将它添加到 git.c::run_builtin() 中。
diff-files.c 中的现有预组合调用和其他调用可能会变得多余，如果我们审核到达这些位置的调用流以确保在不通过添加到 run_builtin() 的新调用的情况下永远无法到达它们，我们可能会能够删除这些现有的。
但是在这次提交中，我们不会费心这样做，而是将这些预组合调用站点保持原样。
因为 precompose() 是幂等的并且可以安全地在已经预先组合的字符串上调用，所以这比不完全审查调用流就删除现有调用更安全。
当然有清理的空间 - 此更改旨在修复错误。
清理需要更多的测试，例如t/t3910-mac-os-precompose.sh，并且应该在以后的提交中完成。
参见git-bugreport-2021-01-06-1209.txt (git can't deal with special characters)