如何清理回购,如果阶段性文件标记为修改?
后
git reset --hard
我得到
Encountered 7 file(s) that should have been pointers, but weren't:
运行git clean -fdx也没有帮助。
如何清理回购,如果阶段性文件标记为修改?
后
git reset --hard
我得到
Encountered 7 file(s) that should have been pointers, but weren't:
运行git clean -fdx也没有帮助。
当前回答
在这个问题上有多个步骤来解决。
如果你只是处于一个破碎的状态,就像卡在一个分支上,因为你不能重置/丢弃对问题文件的更改:删除.gitattributes文件可能足以让你进行下一次git移动。一旦你移动了你的git,你可能需要恢复.gitattributes文件,但至少你摆脱了困境。
我希望我在尝试上述所有方法之前就知道这一点。至少尝试一下是一个低风险的选择。
其他回答
run
git add --renormalize .
并提交这些更改。即使当另一个用户在另一个分支上做同样的事情时,这样做也是安全的,因为LFS指针是从文件的散列派生的。它还可能捕获一些行尾错误的文件。
这可能发生在您执行包含文件的签出时,这些文件本应由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:
$
与上面的@John Kugelman一样,但我把它放在一个别名中,因为我必须这么做很多次。
git rm --cached -r . > /dev/null && git reset --hard > /dev/null && git rm .gitattributes > /dev/null && git reset . && git checkout . > /dev/null
我有这个确切的错误与一些文件存储与git-LFS和解决它的方式一样,我已经解决了一个linending诱导borked索引。
清除缓存并进行硬复位:
git rm --cached -r .
git reset --hard
对于我来说,这比一个新鲜的克隆要快得多,因为我的repo中有巨大的git-LFS文件。
上面的命令对我都没用,我在这里找到了答案
git status -s | cut -c 4- | xargs git update-index --assume-unchanged
rm .git/index && git reset