如何清理回购,如果阶段性文件标记为修改?

git reset --hard

我得到

Encountered 7 file(s) that should have been pointers, but weren't:

运行git clean -fdx也没有帮助。


当前回答

帮助我的是git 2.23中添加的git恢复命令,而不涉及整个repo

git restore——source=HEAD——staging——worktree——affected_files

执行该命令几次,直到所有警告消失。

其他回答

在我的例子中,它是一个lfs规则下的文件(我假设它是在没有安装lfs或其他东西的情况下检入的)。

所以我在.gitattributes文件中找到了它的扩展名,并将这一行注释为

#*.7z filter=lfs diff=lfs merge=lfs -text

保存这个.git属性,然后git状态显示没有问题。

之后,我取消了这一行的注释(删除了#),保存了.gitattributes和git状态仍然显示没有问题。

这可能发生在您执行包含文件的签出时,这些文件本应由LFS跟踪(如.gitattributes中指定的那样),但它们却被直接提交了。大多数情况下,您有另一个程序管理您的存储库,如git GUI或IDE。

这可能会令人沮丧,因为这些文件不知从哪里冒出来,阻止您进行签出。只要您将更改隐藏起来,它们就会返回!如果您陷入这种情况,一个快速的解决方法是在一个临时分支上提交这些更改,这样您就可以再次签出。

要真正解决这个问题,请确保将文件提交为LFS指针。这应该和使用git add一样简单。在提交之前使用git lfs状态检查你的工作。git lfs ls-files将显示lfs正在管理的文件。

git lfs状态是误导性的,因为当它真正列出所有更改时,它会读取git lfs对象以提交。您希望由LFS跟踪的文件应该读取类似于(LFS: c9e4f4a)或(Git: c9e4f4a -> LFS: c9e4f4a)的文件,而不是(Git: c9e4f4a)。

举例来说,我发现这是一个问题,当通过Xcode 9.2添加图像资产时,我添加了“CalendarChecked.png”,它会自动添加:

$ git status
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png

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:   Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png

$ git lfs status

Git LFS objects to be committed:

    Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png (Git: c9e4f4a)

Git LFS objects not staged for commit:

    Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png (File: c9e4f4a)

$ git add Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png`
$ git lfs status

Git LFS objects to be committed:

    Empty/Empty/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png (LFS: c9e4f4a)

Git LFS objects not staged for commit:

$

分析

这是因为LFS没有跟踪这些文件,但是它们符合一些.gitattributes文件的描述。

例如,

服务器/ .gitattributes:

conf/** filter=lfs diff=lfs merge=lfs -text

server/conf/client.conf文件太大,被LFS跟踪 服务器/ conf /客户端。gflags是在git而不是LFS中跟踪的

然而,客户端。Gflags匹配服务器/。git会从LFS中拉出它,但是它没有LFS信息,错误就会被抛出。

解决方案

找到描述与encounter文件相匹配的.gitattributes文件,删除错误的描述或优化一些通配符匹配。

优化上面的例子, 服务器/ .gitattributes:

conf/client.conf filter=lfs diff=lfs merge=lfs -text

run

git add --renormalize .

并提交这些更改。即使当另一个用户在另一个分支上做同样的事情时,这样做也是安全的,因为LFS指针是从文件的散列派生的。它还可能捕获一些行尾错误的文件。

下面的进程将添加一个提交,将所有应该是lfs指针的二进制文件替换为lfs指针。

Clean working copy completely. Together with the force add below this prevents any files getting added or removed due to .gitignore patterns. git clean -dfx git reset --hard git checkout -- . Add remove for everything to staging area. Working copy will not be touched. git rm --cached -r . Readd all files from working copy again. This will basically undo the previous command but will reevaluate lfs filters. Use -f to ignore .gitignore. All files present were previously checked in and should get added again. git add -f . You staging area now should only contain the binary files that previously raised the 'should have been pointers' error. git commit -m "moved files to lfs"