linux - 我可以让 Mac、Windows 和 linux 共享一个 git 存储库而不用担心行结束吗？

Question

大家好:我正在为研究人员建立一个 git 存储库，以共享研究项目的脚本和数据。研究人员不是程序员，也不是特别精通 git，所以我希望将桌面 git 客户端指向一个共享存储库——每个人都可以在他们的本地文件系统中访问它。

问题:行结尾。我们有人在使用:

• Windows(主要是 R)(CRLF)
• linux 和 Mac 脚本(主要是 R 和 python)(仅限 LF)
• Mac 上的 Excel，另存为 .CSV(仅限 CR，是的，这是真实的)

git 的 autocrlf 出于某种原因不理解 Mac 行尾，所以这对我来说效果不佳。

首先，我想在不告诉人们“你不能使用你熟悉的工具”的情况下跟踪对这些文件的更改，因为那样他们只会将数据和脚本存储在存储库之外的某个地方。

其次，我不想让 git 存储库充满愚蠢的行结束提交和 merge 冲突，因为我可能需要解决所有发生的 merge 冲突。

第三，我希望人们不必手动运行一些“修复所有行尾”脚本，因为那会很糟糕。如果这就是我需要做的……我想随便吧。

假设“首先，规范化行尾”是答案，我应该选择哪一个？

我曾考虑过预提交 Hook ，但听起来这涉及以某种方式让相同的脚本在 Windows 和 Unix 上运行，这听起来很糟糕。也许这是一个 secret 实用的选择？

谢谢。

Answer 1

作为Marek Vitek said in comments ，您可能至少需要编写一小段代码。

其次，为了清楚起见，以下是 Git 本身处理(或不处理)数据转换的方式:

• 提交中的数据(文件)是神圣不可侵犯的。从字面上看，它不能被更改，所以一旦某个内容在提交中，它就会永远存在。¹

• 工作树中的数据可以而且应该采用“主机友好”格式。也就是说，如果您在 Mac 上运行的程序 P_mac 要求行以 CR 结尾，则数据可以采用该格式.如果您在运行等效 P_windows 的 Windows 机器上要求行以 CR+LF 结尾，则数据可以位于格式。

• 当文件从索引/暂存区移动到工作树时，就会转换为“主机格式”。从“主机格式”到“内部存储格式”的转换发生在文件从工作树到索引/暂存区时。

大多数 Git 的内置过滤器只进行 CRLF 到 LF，或 LF 到 CRLF 的转换。有一个“更大”的内置过滤器，称为 ident(不要与 indent 混淆)，您可以定义您自己的过滤器clean 和 smudge，可以做任意事情。这意味着您可以定义一个 smudge 过滤器，在 Mac 上(但不是在 Windows 上)将(例如)将 LF 更改为 CR。相应的 Mac-only clean 过滤器可能会将 CR 更改为 LF。

请注意，许多转换不是对原始二进制数据进行数据保留:可能有一个字节恰好类似于 LF 或 CR，或者连续两个字节类似于 CRLF，但并不意味着 以这种方式解释。如果你改变这些，你破坏了二进制数据。因此，重要的是仅将过滤应用于那些似乎是其中之一的字节，实际上是其中之一的文件。您可以使用 .gitattributes 路径名匹配，例如 *.suffix，来推断哪些文件应用了哪些过滤器。

当然，要应用的正确过滤操作将取决于主机。

merge 和“重新规范化”

在进行 merge 时，Git 通常只是直接从每个涉及的提交中的纯版本中获取文件。由于是 Git(和 git diff)对行进行解释，因此您通常希望这些具有 Git 首选的“行”格式，即以 LF 结尾(如果它们在行之前有或没有 CR 都可以) LF 只要所有三个版本进入三路 merge 都具有相同 CR-before-LF-ness)。不过，您可以使用“重新规范化”设置，让 Git 在执行三向 merge 之前通过您的涂抹然后清理过滤器进行虚拟传递。仅当您现在打算 merge 的现有提交(基本和两个分支提示)以与您现在同意保留在永久提交中的方式不同的方式存储时，您才需要它。 (我还没有真正尝试过这些，但原理很简单。)

---

¹您可以删除一个提交，但要这样做，您还必须删除该提交的所有后代。实际上，这意味着已共享/推送的提交通常永远不会消失；只有私有(private)提交可以消失或被新的和改进的提交所取代。很难让所有提交过 a9f3c34... 的人放弃它，转而支持新的和改进的 07115c3...，即使您能说出这个词 < em>给所有人。