我正在寻找一个类似于高级瓷器命令git checkout -- .
我最初的想法是使用git checkout-index --all --force
,但在core.autocrlf = input
的情况下,这并不能完全恢复工作目录:
#!/bin/bash
set -ex
rm -rf repo
git init repo
cd repo
git config --local core.autocrlf input
python3 -c 'open("foo", "wb").write(b"1\r\n2\r\n")'
git add foo
python3 -c 'open("foo", "wb").write(b"3\r\n4\r\n")'
git checkout-index --all --force
echo 'I expect this `git status` to have no modifications'
git status
这会产生以下输出:
+ rm -rf repo
+ git init repo
Initialized empty Git repository in /tmp/foo/repo/.git/
+ cd repo
+ git config --local core.autocrlf input
+ python3 -c 'open("foo", "wb").write(b"1\r\n2\r\n")'
+ git add foo
warning: CRLF will be replaced by LF in foo.
The file will have its original line endings in your working directory.
+ python3 -c 'open("foo", "wb").write(b"3\r\n4\r\n")'
+ git checkout-index --all --force
+ echo 'I expect this `git status` to have no modifications'
I expect this `git status` to have no modifications
+ git status
On branch master
Initial commit
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: foo
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: foo
请注意git checkout -- .
正确地将工作目录还原为index
的内容,即使在这种情况下也是如此。
答案 0 :(得分:1)
这似乎是git checkout-index
中的一个错误:它不知道如何处理工作树与索引匹配的事实。
如果我们添加git ls-files --stage --debug
,我们会看到在第一个git add
之后,索引包含:
100644 1191247b6d9a206f6ba3d8ac79e26d041dd86941 0 foo
ctime: <ct>
mtime: <mt>
dev: <d> ino: <i>
uid: <u> gid: <g>
size: 6 flags: 0
(我在这里用<...>
替换了无关的变量值)。请注意,列出的大小为6,而不是4:这是工作树文件的大小,实际上长度为6个字节,因为它包含\r\n
行结尾。
接下来,我们这样做:
python3 -c 'open("foo", "wb").write(b"3\r\n4\r\n")'
替换文件,用新的时间戳和新内容重写现有的inode。新内容长6个字节。
然后我们这样做:
git checkout-index [arguments]
使用索引内容覆盖工作树文件,就像git checkout
一样。该文件现在长4个字节......但索引仍然说该文件长6个字节。
如果我们重命名 foo
,那么git checkout-index
必须使用不同的inode编号重新创建foo
,我们会发现{{1}索引中的信息仍然过期。换句话说,即使stat
正在重写git checkout-index
,它也永远不会更新缓存的统计信息。因此foo
的内部索引与工作树差异使用快速路径(将缓存的统计数据与实际文件系统文件的统计数据进行比较),并假设必须对其进行修改。
(奇怪的是,git status
也不会触及缓存信息,我不知道为什么不这样做。)
解决方案似乎是直接使用git update-index --refresh -q
,至少在修复git checkout
之前。