git-cat 文件输出

Question

当我在提交上运行 git cat-file --batch 时，它输出“缺少...”，但提交确实存在。为什么会发生这种情况？当使用 -t 开关运行 cat-file 时，它​​只会输出我所期望的“提交”。任何人都可以解释这一点吗？我是 git 新手。谢谢。

编辑：我已经找到原因了。 msysgit 期望 LF 而 ENTER 生成 CRLF。

Answer 1

我不确定 git cat-file --batch 是否应该按照您在问题中提到的方式工作。
（可能在 2016 年 3 月 git 2.8 之后，见下文）

即使在“GitMagic book”中，在 unix 环境中，git cat-file 也会像 cmets 中提到的 sinelaw 一样使用：

通过键入检查此文件是否确实包含上述​​内容：

$ echo 05b217bb859794d08bb9e4f7f04cbda4b207fbe9 | git cat-file --batch

---

正如上面提到的 OP Alex.Shen，这是一个 newline 问题：
git 命令总是需要 LF ^{(换行，U+000A)}，而不是 Windows CRLF ^{(@987654361 @+LF: CR (U+000D) 后跟 LF (U+000A))} 序列。
使用 '|'，它使用 bash msysgit shell (LF) 的 EOL 字符，因此它始终有效。

---

注意：Git 2.5+（2015 年第 2 季度）将添加对带有 git cat-file --batch 的符号链接的支持。
（新的 Git 版本可通过 github.com/git-for-windows/git/releases 获取 Windows）

参见commit 122d534David Turner (csusbdt)，2015 年 5 月 20 日。
^{（由 Junio C Hamano -- gitster -- 合并，commit 67f0b6f，2015 年 6 月 1 日）}

cat-file：将--follow-symlinks 添加到--batch

“git cat-file --batch(-check)”学习了“--follow-symlinks”选项，当被问及 对象通过扩展的 SHA-1 语法。

例如HEAD:RelNotes 指向Documentation/RelNotes/2.5.0.txt。

使用新选项，该命令的行为就好像 HEAD:Documentation/RelNotes/2.5.0.txt 被作为输入代替。

---

2016 年 2 月更新：

Git 2.8 为一些 git 命令添加了对 CRLF 的支持：

见commit a551843、commit 933bea9、commit 1536dd9、commit b42ca3d、commit 692dfdf、commit 3f16396、commit 18814d0、commit 1f3b1ef、commit 1f3b1ef、commit 72e37b6、commit 6e8d46f、commit 6e8d46f(80804344 2015 年）Junio C Hamano (gitster)。
^{（由 Junio C Hamano -- gitster -- 合并于 commit 0175655，2016 年 2 月 3 日）}

特别是commit b42ca3d 使用strbuf.c#strbuf_getline()（它可以将LF 或NUL 以外的字节作为行终止符）

使用 git 2.8：

cat-file：使用strbuf_getline() 读取批处理流

可以用 DOS 编辑器准备一个文本文件并输入它 作为命令的批处理命令流。

---

请注意，在 Git 2.33（2021 年第三季度）之前，“git cat-file --batch-all-objects”^(man) 在使用 --batch 且未要求某些对象特征时行为异常。

参见ZheNing Hu (adlternative) 的commit ee02ac6、commit e16acc8（2021 年 6 月 3 日）。
^{（由 Junio C Hamano -- gitster -- 合并到 commit 5d96bcb，2021 年 7 月 13 日）}

cat-file：用--batch-all-objects处理琐碎的--batch格式

^{协助人：Jeff King
签字人：胡哲宁
签字人：Jeff King}

用于打印对象的--batch 代码假定我们通过调用oid_object_info_extended() 找到了对象的类型。
对于默认格式也是如此，但即使是自定义格式，我们也需要手动修改 object_info 结构以询问类型。

845de33 打破了这个假设（cat-file：避免对 sha1_object_info_extended 进行 noop 调用，2016-05-18，Git v2.9.0-rc1 -- merge）（cat-file：避免对 @ 进行 noop 调用987654398@2016-05-18).
当 --batch-all-objects 正在使用时，该提交会完全跳过对 oid_object_info_extended() 的调用，并且自定义格式不包含任何需要调用它的占位符。

或者当自定义格式只包含 %(objectname) 或 %(rest) 等占位符时，oid_object_info_extended() 将无法获取对象的类型。

当我们尝试确认类型没有改变时，这会导致错误：

$ git cat-file --batch=batman --batch-all-objects
  batman 
  fatal: object 0000239 changed type!?  

并且还有其他微妙的影响（例如，我们无法流式传输 blob，因为我们一开始没有意识到它是一个 blob）。

我们可以通过颠倒设置顺序来解决此问题。
“我们是否需要获取对象信息”的检查必须在我们决定是否需要查找类型之后进行。