Git 错误：遇到 7 个应该是指针的文件，但不是

Question

提问by Kate Zz

How to clean repo, if staged files marked as modified?

如果暂存文件标记为已修改，如何清理存储库？

After

后

git reset --hard

I get

我得到

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

git clean -fdx

doesn't help too.

也没有帮助。

Answer 1

回答by BheemaSenan

Like Travis Heetermentioned in his answer, Try the following command sequence:

就像他的回答中提到的Travis Heeter一样，尝试以下命令序列：

git lfs uninstall
git reset --hard
git lfs install
git lfs pull

In case if this is not working (because this was not working for me), the following hack may work:

如果这不起作用（因为这对我不起作用），以下 hack 可能会起作用：

git rm --cached -r .
git reset --hard
git rm .gitattributes
git reset .
git checkout .

This worked for me!

这对我有用！

Answer 2

回答by Rian Sanderson

I had this exact error with some files stored with git-LFS and solved it the same way I've solved a linending induced borked index .

我在使用 git-LFS 存储的某些文件中遇到了这个确切的错误，并以与解决 linending 引起的 borked index 相同的方式解决了它。

Clear the cache and do a hard reset:

清除缓存并进行硬重置：

git rm --cached -r .
git reset --hard

This was significantlyfaster than a fresh clone for me due to the huge git-LFS files in my repo.

这是显著快于新的克隆，我由于我的回购巨大的git-LFS文件。

Answer 3

回答by slythfox

This can happen when you do a checkout that contains files which should have been been tracked by LFS as specified in .gitattributesbut somehow they've been committed directly instead. Most likely you have another program managing your repository such as a git GUI or IDE.

当您签出包含应由 LFS 跟踪的文件.gitattributes但不知何故直接提交时，可能会发生这种情况。很可能您有另一个程序管理您的存储库，例如 git GUI 或 IDE。

This can be frustrating because these files appear out of nowhere and prevent you from making checkouts. As soon as you stash your changes they return! If you get stuck in this situation, a quick fix is to commit these changes on a temporary branch so that you can checkout again.

这可能令人沮丧，因为这些文件无处不在并阻止您进行结帐。一旦你隐藏你的更改，它们就会返回！如果您遇到这种情况，一个快速的解决方法是在临时分支上提交这些更改，以便您可以再次结帐。

To genuinely fix this problem, make sure you've committed the files as LFS pointers. This should be as simple as using git add. Check your work using git lfs statusbefore committing. git lfs ls-fileswill show what files LFS is managing.

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

git lfs statusis misleading since it reads Git LFS objects to be committedwhen it really lists all changes. Files that you expect to be tracked by LFS should read something like (LFS: c9e4f4a)or (Git: c9e4f4a -> LFS: c9e4f4a)and not (Git: c9e4f4a).

git lfs status具有误导性，因为它Git LFS objects to be committed在真正列出所有更改时读取。您希望 LFS 跟踪的文件应该读取类似(LFS: c9e4f4a)or(Git: c9e4f4a -> LFS: c9e4f4a)和 not 的内容(Git: c9e4f4a)。

By way of example, I found this to be a problem when adding image assets through Xcode 9.2 where I added "CalendarChecked.png" which it automatically added:

举例来说，我发现这是通过 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:

$

Answer 4

回答by Travis Heeter

Neither of these solutions worked for me, but I pieced together a few sources to finally get all this fixed.

这些解决方案都不适合我，但我拼凑了一些来源，最终解决了所有这些问题。

Push any changes you don't want to lose
Make sure you're in your main branch, and everything is committed (except the bad files).
Stop Everything
SourceTree, any servers, file explorers and browsers. Sometimes this stuff won't work if it's being used somewhere else. When in doubt, stop it - with this it's better to overkill.
If you go through all this and your changes aren't sticking, consider restarting your computer, force-stopping anything from TaskManager that might affect your repo and trying again.
Open a Command Window (or Terminal)
On Windows, this is going to be a cmdor command window. If you're not sure, click the windows key, and type cmd. It'll suggest Command Prompt, click that.
cdto your repo.
Uninstall lfs
> git lfs uninstall
Then it'll say something like:
Hooks for this repository have been removed. Global Git LFS configuration has been removed.
Reset
> git reset --hard
It'll go through a lot of output...
Reinstall lfs
> git lfs install
This may again say it found files that should have been pointers but weren't. That's OK, keep going!
Pull with lfs
> git lfs pull
Hopefully pulling with lfs will overwrite the files that got borked.
A few of my sources said at this point their repo was working again, but not me personally. You can Open SourceTree to check if you want, but you may have to start from the top if it didn't work.
Migrate
The core issue here is that lfstracks large files by replacing them with pointers. _{^{If you're a programmer this is similar to how a variable points to a place in memory, rather than holding the actual value.}}
What we've done so far is
- uninstall lfs
- delete everything
- reinstall lfs
- pull everything
So now we have all these thingsin our folder that are either filesor pointers to files, and lfsneeds to figure out if any files should be pointers and vise versa (and herein is the source of our horrific error - some files should have been pointers but weren't). So we're going to perform migrateto kick off the procedure that goes through the files on the repo, and if they're greater than 1Mb, lfs is going to replace them with a pointer.
git lfs migrate
More Horror
Here's a point at which others have stopped and said they were working again, but not me. I got an error:
Error in git rev-list... exit status 128 fatal: bad revision '...v1.0.0'
There is a tragic hero, @guneyozsan over at a github help page, who posted this final piece to the puzzle even though it didn't fix his issue. He posted it about 2 hours before I started looking for the zillionthth time on how to fix this, even though the issue has been around for 2 years. Bless you @guneyozsan, and I wish you luck in resolving your issue.
> git lfs migrate info --include-ref=v1.0.0
Notice the version matches the version that errored - v1.0.0.
I haven't found a source on why this error occurs but my guess is that the lfs version number generated by migrateon your local repo doesn't match the source version. For whatever reason, the local lfs data was screwed up (for me, all this started when SourceTree crashed during a push and I forced a machine reboot, so that may have corrupted the lfs data), and when that happens, SourceTree doesn't know how to deal with it, so it just gets stuck in this loop where it's trying to update, but it can't read the corrupted data. Hence the lengthy troubleshooting.
Stash and Pull
When you open SourceTree, you'll probably see that it wants to add all your files back. Don't do that. Stash, then pull.
And boom, the horror is over. Hopefully. If not, this git hub pageor this onemay help you more, but this is what worked for me.

推送您不想丢失的任何更改
确保您在主分支中，并且所有内容都已提交（坏文件除外）。
停止一切
SourceTree、任何服务器、文件浏览器和浏览器。有时，如果在其他地方使用这些东西，它就不起作用。如有疑问，请停止它 - 这样做最好是矫枉过正。
如果您经历了所有这些并且您的更改没有保留，请考虑重新启动计算机，从 TaskManager 强制停止可能影响您的存储库的任何内容，然后重试。
打开命令窗口（或终端）
在 Windows 上，这将是一个cmd或命令窗口。如果您不确定，请单击 windows 键，然后键入cmd。它会建议命令提示符，单击它。
cd到你的回购。
卸载 lfs
> git lfs uninstall
然后它会说：
Hooks for this repository have been removed. Global Git LFS configuration has been removed.
重启
> git reset --hard
它会经历很多输出......
重新安装 lfs
> git lfs install
这可能再次说明它找到了应该是指针但不是指针的文件。没关系，继续！
拉用 lfs
> git lfs pull
希望用 lfs 拉动会覆盖那些无聊的文件。
我的一些消息来源此时表示他们的回购再次运行，但不是我个人。您可以打开 SourceTree 来检查是否需要，但如果它不起作用，您可能必须从顶部开始。
迁移
这里的核心问题是lfs通过用指针替换大文件来跟踪大文件。_{^{如果您是程序员，这类似于变量如何指向内存中的某个位置，而不是保存实际值。}}
到目前为止我们所做的是
- 卸载 lfs
- 删除一切
- 重新安装 lfs
- 拉一切
所以现在我们的文件夹中有所有这些东西，要么是文件要么是指向文件的指针，lfs需要弄清楚是否有任何文件应该是指针，反之亦然（这就是我们可怕错误的根源——有些文件应该是指针但不是）。所以我们将执行migrate启动通过 repo 上的文件的过程，如果它们大于 1Mb，lfs 将用指针替换它们。
git lfs 迁移
更多恐怖
在这一点上，其他人停下来说他们又开始工作了，但我不是。我有一个错误：
git rev-list 中的错误...退出状态 128 致命：错误修订版 '... v1.0.0'
有一个悲剧英雄，@guneyozsan 在github 帮助页面上，他将最后一块拼图发布到了拼图上，即使它没有解决他的问题。他在我第 2 次开始寻找如何解决这个问题之前大约 2 小时发布了它，即使这个问题已经存在 2 年了。祝福你@guneyozsan，我祝你好运解决你的问题。
> git lfs migrate info --include-ref=v1.0.0
请注意，版本与出错的版本匹配 - v1.0.0。
我还没有找到有关为什么会发生此错误的来源，但我的猜测是migrate本地存储库上生成的 lfs 版本号与源版本不匹配。无论出于何种原因，本地 lfs 数据都被搞砸了（对我来说，这一切都是在 SourceTree 在推送过程中崩溃并且我强制重启机器时开始的，所以这可能会损坏 lfs 数据），当发生这种情况时，SourceTree 不会知道如何处理它，所以它只是卡在这个试图更新的循环中，但它无法读取损坏的数据。因此需要冗长的故障排除。
藏匿和拉动
当您打开 SourceTree 时，您可能会看到它想要重新添加所有文件。不要那样做。藏起来，然后拉。
砰，恐怖结束了。希望。如果没有，这个git 中心页面或这个页面可能会帮助你更多，但这对我有用。

Answer 5

回答by karyon

Since git lfs 2.5.0, there is a new command available that makes this easier (docs):

从 git lfs 2.5.0 开始，有一个新命令可以使这更容易（docs）：

git lfs migrate import --no-rewrite "broken file.jpg" "another broken file.png" ...

This "migrates" files to git lfs which should be in lfs as per .gitattributes, but aren't at the moment (which is the reason for your error message).

这将“迁移”文件到 git lfs ，它应该在 lfs 中.gitattributes，但目前不是（这是您的错误消息的原因）。

--no-rewriteprevents git from applying this to older commits, it creates a single new commit instead.

--no-rewrite防止 git 将其应用于旧提交，而是创建一个新提交。

Use -m "commitmessage"to set a commitmessage for that commit.

使用-m "commitmessage"设置为犯commitmessage。

Answer 6

回答by Jordan

The problem comes from the mismatch beetween the filetypes marked as to be tracked by git LFS in the .gitattributesand some mathing files already under conventional non-LFS version control.

问题来自标记为由 git LFS 在 git LFS 跟踪的文件类型.gitattributes和一些已经在传统非 LFS 版本控制下的数学文件之间的不匹配。

So the simplest workaround here is to just remove the .gitattributesfile for a moment:

所以这里最简单的解决方法是.gitattributes暂时删除文件：

git rm .gitattributes
git reset .
git checkout .

Afterwards you can checkout any other branch.

之后，您可以结帐任何其他分支。

One more advice: When adding a new filetype to git LFS, prefer not to do this by hand by modifying the .gitattributesbut e.g. by running:

还有一个建议：在向 git LFS 添加新文件类型时，不要通过修改.gitattributes而是手动执行此操作，例如通过运行：

git lfs track PATTERN

where PATTERN is the pattern for matching files, e.g *.so

其中 PATTERN 是匹配文件的模式，例如 *.so

This way all already non-LFS versioned files matching the new tracking-pattern will be marked dirty and can be simlpy added, i.e. converted to git LFS (file pointers).

这样，所有与新跟踪模式匹配的非 LFS 版本化文件都将被标记为脏文件，并且可以简单地添加，即转换为 git LFS（文件指针）。

Answer 7

回答by Felix

Ensure you have git lfsversion 2.5 or higher installed (download here).

确保您git lfs安装了 2.5 或更高版本（在此处下载）。

Check you are using the git lfsversion you downloaded (2.7.7 for me):

检查您使用的是git lfs下载的版本（对我来说是 2.7.7）：

>git lfs version
git-lfs/2.7.2

Run:

跑：

git lfs migrate import --fixup --everything

Pull your branch and fix any merge conflicts.

拉你的分支并修复任何合并冲突。

Found in this github comment.

在此github 评论中找到。

Answer 8

回答by sonny

One possible cause for this error is due to git LFS-related changes to .gitattributesthat impacts already added files in a repo.

导致此错误的一个可能原因是与 git LFS 相关的更改会.gitattributes影响存储库中已添加的文件。

(I'm not sure of the exact steps to reproduce, but the issue seemed to occur when I touched a file that was newly affected by the .gitattributes that was previously committed as a non-LFS file that should now be an LFS file. The issue seemed aggravated by switching branches, or at least made it impossible to switch branches until the issue was resolved.)

（我不确定重现的确切步骤，但是当我触摸一个新受 .gitattributes 影响的文件时，问题似乎发生了，该文件以前作为非 LFS 文件提交，现在应该是 LFS 文件。切换分支似乎加剧了问题，或者至少在问题解决之前无法切换分支。）

In this case, I used the steps below to prevent this error from occurring repeatedly.

在这种情况下，我使用以下步骤来防止此错误重复发生。

Fix the issue for the branch you are on by following one of the other answers here (e.g. to clear the cache and reset. I found BheeMa's answerto be effective.)
Go to your main branch, and ensure there is nothing to commit with git status
Force git to recheck and "reapply" git attributes changes

按照此处的其他答案之一解决您所在分支的问题（例如清除缓存并重置。我发现BheeMa 的答案是有效的。）
转到您的主分支，并确保没有任何可提交的内容 git status
强制 git 重新检查并“重新应用”git 属性更改

From Ratata Tata's answerin How to make change to .gitattributes take effect)

来自Ratata Tata在How to make change to .gitattributes 中的回答）

 git rm --cached -r .
 git add -A

Warning: make sure in step 2 that there was nothing to commit, as the steps above will add any files that were not previously versioned

警告：确保在第 2 步中没有要提交的内容，因为上述步骤将添加以前未进行版本控制的任何文件

Verify the results with git status(it should only have modified relevant files to become LFS pointers, i.e. files that can potentially cause the "encountered files that should have been pointers" error) and commit changes
(Optionally, merge/rebase this fix to all other branches if possible. Otherwise, this error could pop up again when switching to those branches. Note that it may be necessary to repeat the initial fix for each branch as per step 1 to be safe, though it could be ok just to commit the affected files.)

验证结果git status（它应该只将相关文件修改为 LFS 指针，即可能导致“遇到应该是指针的文件”错误的文件）并提交更改
（可选地，如果可能，将此修复程序合并/重新绑定到所有其他分支。否则，切换到这些分支时可能会再次弹出此错误。请注意，可能需要按照步骤 1 对每个分支重复初始修复程序以确保安全，尽管提交受影响的文件也可以。）

Answer 9

回答by Gillespie

Here's the problem I ran into:

这是我遇到的问题：

Say you created a branch, and you somehow committed files as non-LFS. So then you tried to correct it by later committing the LFS version of the files on the same branch. However, now you can't rebase or squash because you'll keep running into this "files that should have been pointers but weren't" error in the middle of the rebase.

假设您创建了一个分支，并且以某种方式将文件提交为非 LFS。因此，您尝试通过稍后在同一分支上提交文件的 LFS 版本来更正它。但是，现在您不能变基或压缩，因为您将在变基过程中不断遇到“应该是指针但不是指针的文件”错误。

Solve using git reset --soft: https://stackoverflow.com/a/5201642/2516916

解决使用git reset --soft：https: //stackoverflow.com/a/5201642/2516916

Answer 10

回答by Junji Shimagaki

If you just want to get away from that bad commit, you can go back to master by

如果你只是想摆脱那个糟糕的提交，你可以通过

git reset --soft origin/master
git reset --hard

Then you are free from the nasty 7 non-LFS files:-)

然后你就摆脱了讨厌的 7 个非 LFS 文件:-)

Git 错误：遇到 7 个应该是指针的文件，但不是

提问by Kate Zz

回答by BheemaSenan

回答by Rian Sanderson

回答by slythfox

回答by Travis Heeter

回答by karyon

回答by Jordan

回答by Felix

回答by sonny

回答by Gillespie

回答by Junji Shimagaki

相关推荐

最近更新

标签

Git 错误：遇到 7 个应该是指针的文件，但不是

提问by Kate Zz

回答by BheemaSenan

回答by Rian Sanderson

回答by slythfox

回答by Travis Heeter

回答by karyon

回答by Jordan

回答by Felix

回答by sonny

回答by Gillespie

回答by Junji Shimagaki

相关推荐

git 从远程存储库中获取单个标签

git 如何从 GitHub 完全删除提交？

Git 从现有的远程分支添加工作树

我们是否应该将 pod 文件提交到版本控制系统（GIT 或 SVN）

相关推荐

最近更新

标签