Ner*_*ris 7 git git-stash git-checkout git-reset
一两个星期前，我拿了一些我用一个简单的find |sed|tar|xz|gpgbash 脚本存档的文件，把它们全部解压，然后把它们的内容放在一个 git repo 中，提交，把下一个存档内容放在 repo 中，提交（冲洗并重复）为了有一个更好的系统。
所有文件都是在我的两台计算机中的一台上编辑的，都使用 Arch Linux，在 TeXstudio 或 Vim 中。
我试图签出一个旧版本，但它翻了出来——它不会让我因为更改非常出色。我尝试了所有我知道的方法，然后去谷歌寻找我不知道的东西。
关于这个主题还有许多其他问题。不幸的是，他们的回答对我没有帮助。为了完成，我将列出问题。
$ git status
在分支 master 上
没有为提交而暂存的更改：（
使用“git add ...”更新将提交的内容）
（使用“git checkout -- ...”放弃工作目录中的更改）修改：Arcs/arc1.tex
修改：Arcs/arc2.tex
修改：Arcs/frontmatter.tex未向提交添加任何更改（使用“git add”和/或“git commit -a”）
另外，所以人们不需要看下面，我已经做了显而易见的事情。
git reset --hard
git -a commit
git stash
git pull
以及从索引中删除所有内容并将其添加回来。
我不在 Windows 上。此外，这应该与行尾有关，因为我是唯一的用户。没有理由出现奇怪的行尾。
git reset --hard HEAD (among other possibilities)
git stash
git stash drop
git config core.autocrlf input
git rm --cached -r .
git reset --hard
git add .
git commit -m "Normalize line endings"
这不仅不起作用，而且增加了行为不端的文件数量，并且还为一个文件写入了 700 多行。. .原因。它甚至不是行为不端的文件。
更多的结束线的东西。
git clean -df
git checkout -- .
git checkout -- ./.
git checkout-index -a -f
git checkout --force master
我尝试提交更改git commit -am "WORK DAMN YOU!"然后git revert --hard HEAD^
我也尝试从我的私人遥控器中拉出，但只是被告知本地存储库已经是最新的。
这是非常令人沮丧的。
根据评论：
\n\n\n\n\n它是
\n.git/info/attributes。……为什么会有这样的效果？...我需要那些 [*.tex] 过滤器...
你可以使用它们。您只需要意识到 Git 不理解它们，并且您可能想以某种方式调整它们。不幸的是，几乎没有什么好的替代方案可以进行上述调整。
\n\n过滤器\xe2\x80\x94（称为清洁和污点core.autocrlf过滤器\xe2\x80\x94）的工作方式与行尾重整的工作方式直接相关。要自己理解它们，请从一些简单的事实开始：
任何 Git 对象\xe2\x80\x94commit、树、blob 或带注释的标记\xe2\x80\x94 的内容都无法更改。这是因为内容是通过其数据库密钥检索的，该数据库密钥是哈希 ID（当前是 SHA-1，将来可能是 SHA-3 或其他一些非常好的哈希），必须与内容的计算哈希相匹配。
您可以通过哈希 ID 检索提交。master类似或 的分支名称develop仅包含该分支上最新提交的实际哈希 ID。
每个提交都会存储其父提交的原始哈希 ID 作为其内容的一部分，并存储导致 Blob 对象的树对象的原始哈希 ID，从而生成该提交的快照。
要将新对象存储到数据库中，您可以将对象输入git hash-object -w（或者 Git 自己在内部执行此操作）。Git现在计算内容的哈希值，包括给出对象类型和大小的标头，并将值 xe2x80x94 内容 xe2x80x94 存储到数据库中并发出密钥。然后您可以在将来使用该密钥来检索内容。此时，Git会重新检查哈希值：它必须与密钥匹配。如果不匹配，则数据已损坏，Git 将停止。
因此，提交哈希必须与提交内容匹配，提交内容给出树内容的树哈希，树内容给出 blob 内容的 blob 哈希。如果提交本身不是分支的尖端，则通过回溯尖端提交到一定数量的先前提交（所有这些都通过它们的哈希 ID）来找到该提交。生成的数据结构是Merkle 树，它提供 Git 的数据完整性保证。
\n\n这意味着无法对已提交的内容进行任何过滤。然而，它必须在已经提交的内容上完成，以便 Windows 用户可以拥有 CRLF 行结尾。Git 如何解决这个悖论呢？
\n\n答案在于关于 Git 的另外几个事实：
\n\n您不能直接使用提交内容。它们需要被提取到一个称为工作树的工作区域中。工作树（或工作树或您喜欢的拼写方式）具有解压缩形式的提取文件，可以在其中读取和写入它们。
但 Git 还添加了一个中间数据结构，Git 最初将其称为索引。这不是一个很好的名字，所以这个数据结构有三个名字：索引、暂存区和缓存。该索引保留工作树上的选项卡，例如缓存（因此是第三个名称）stat系统调用数据。当前提交中的每个文件首先被提取到索引中，使其保持其特殊的压缩形式\xe2\x80\x94实际上，只需直接使用原始blob哈希ID\xe2\x80\x94，以便索引具有或实际上具有对 的引用，即提交中文件的副本。
在文件上运行会将git add文件复制到索引中（实际上，将其作为 blob 对象添加到主数据库中并计算其哈希 ID，然后更新索引中的哈希 ID）。这意味着索引始终是 Git 将用于您可以进行的下一次提交的图像。这就是暂存区名称的由来。因为您可以使用 覆盖索引文件git add，所以它们在这里是可写的，而在提交中它们是不可写的。
运行将git commit当前索引打包到树对象中，始终冻结它 \xe2\x80\x94blob 哈希不再可更改\xe2\x80\x94 并使用树对象进行新的提交。
与其他版本控制系统相比，这个索引是 Git 获得更快速度的原因。由于索引跟踪工作树，Git 可以比平常更快地完成很多事情：git status例如，可以调用stat目录或文件并将结果与缓存的stat数据进行比较，而无需读取文件本身。
（索引还在冲突合并期间发挥了扩展作用。这与清理和污迹过滤器以及 LF/CRLF 战争无关，但在我们讨论索引时值得一提。而不是每个条目只有一个条目对于要提交的文件，索引可以保存三个未提交的条目：一个来自合并基础，一个来自正在合并的两个分支尖端。）
\n\n我们现在准备看看过滤是如何工作的。让我们总结一下关于提交、索引和工作树的要点：
\n\ngit checkout将提交的树复制到索引，之后它与提交的树完全匹配，但采用更适合跟踪工作树的形式。git checkout 还将每个提交的文件复制到工作树，同时更新该文件的索引槽。git add将文件从工作树复制回索引，以便将来git commit可以冻结索引。现在，请记住，污迹过滤器应用于提交的内容，因为它已变成工作树文件。干净的过滤器应用于工作树内容，因为它变成了已提交的\xe2\x80\x94或至少是待提交的\xe2\x80\x94内容。污迹过滤时间是指 Windows 用户的仅 LF 行结尾可以变为 CRLF 行结尾的时间，而干净过滤时间是指 CRLF 行结尾可以变回仅 LF 行结尾的时间。
\n\n应用污迹过滤器的理想时间是在扩展文件时，即从索引复制到工作树时。 应用干净过滤器的理想时间是在压缩文件时，即从工作树复制到索引时。这就是Git 做的事情。
\n\n但与此同时，该索引的关键特征之一是速度。因此，从某种意义上说，Git假设应用污迹过滤器不会“更改”文件。工作树文件中的内容可能不再与解压缩的 blob 匹配，但是 \xe2\x80\x94 至少从意图和目的来看 \xe2\x80\x94 它仍然与通过清理和重新压缩工作得到的内容匹配-树文件。
\n\n当事实并非如此时，麻烦就会出现。如果清理并重新压缩文件会产生不同的内容并具有不同的哈希 ID，该怎么办？答案是Git 可能会注意到，但 Git 可能不会注意到，这一切都取决于索引即缓存的有效性和stat索引中保存的数据与stat稍后系统调用传递的数据的变化无常。
如果污迹和清洁过滤器是完美的镜像\xe2\x80\x94，那么污迹和重新清洁的文件始终与原始\xe2\x80\x94匹配，您可以在git add提取文件后，Git将更新保存的stat数据。只要这种情况不再发生变化，Git 现在就会认为该文件是干净的。如果底层文件系统有不可靠的stat数据，您可以使用索引的假设不变位来强制Git 认为该文件无论如何都是干净的。这是相当粗糙的解决方案，不是一个令人满意的解决方案，但它可以完成工作。