如何清理回购,如果阶段性文件标记为修改?
后
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也没有帮助。
当前回答
与上面的@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在.git属性中标记为要跟踪的文件类型与一些已经在传统的非LFS版本控制下的匹配文件之间的不匹配。
所以这里最简单的解决方法是暂时删除.gitattributes文件:
git rm .gitattributes
git reset .
git checkout .
之后,您可以结帐任何其他分支。
另外一个建议:当添加一个新的文件类型到git LFS时,最好不要手动修改.gitattributes,而是通过运行:
git lfs track PATTERN
其中PATTERN是匹配文件的模式,例如*.so
通过这种方式,所有匹配新的跟踪模式的非LFS版本文件将被标记为dirty,并可以简单地添加,即转换为git LFS(文件指针)。
接受的答案为我工作,但它只会在我手动输入命令时工作,我把每个命令之间的睡眠,现在它作为一个bash脚本工作:
git rm --cached -r .
sleep 1
git reset --hard
sleep 1
git rm .gitattributes
sleep 1
git reset .
sleep 1
git checkout .
这些解决方案都不适合我,但我拼凑了一些资源,最终解决了所有这些问题。
Push any changes you don't want to lose If you can... If not, or if you don't care about your changes, press on. 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. Also, go into Task Manager, force quit any bash.exe processes. Git Bash tends to hold files open after you close the window. Open a Command Window (or Terminal) cd to your local 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 probably... 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 or whatever 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 lfs, instead of downloading large files like audio, video, images - anything larger than 1Mb - it just points to them on a server. This is useful if you have a bunch of large files, you're not pulling down all that stuff. So your local repo is smaller and nimbler. However, through circumstances I'm not sure about, it seems possible to corrupt the pointers. I'm sure this is an issue that the lfs people are aware of and are working on, but for now we have to work it out ourselves. What we've done so far is uninstall lfs delete everything reinstall lfs pull everything So now we have all these things in our folder that are either files or pointers to files, and lfs needs to figure out if any files should be pointers and vise versa. And hopefully by performing the steps above we deleted the corrupted pointers. So we're going to perform migrate to 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 Errors 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' @guneyozsan over at a github help page, posted this final piece to the puzzle, even though it didn't fix his issue. > git lfs migrate info --include-ref=v1.0.0 Notice the version matches the version that errored - v1.0.0. You will need to replace v1.0.0 with whatever version you got in your error. I haven't found a source on why this error occurs but my guess is that the lfs version number generated by migrate on your local repo doesn't match the source version. For me, all this started when SourceTree crashed during a push and I forced a machine reboot, and when that happens, lfs 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
当您打开SourceTree时,您可能会看到它想要将您的所有文件添加回来。不要那样做。藏起来,然后拉出来。
然后,恐怖事件有望结束。如果没有,这个git集线器页面或这个可能会帮助你更多,但这对我来说是有效的。
这是我遇到的问题:
假设您创建了一个分支,并以某种方式将文件提交为非lfs。因此,您试图通过稍后在同一分支上提交文件的LFS版本来纠正它。然而,现在你不能重基或压缩,因为你会一直遇到这种“文件应该是指针,但不是”错误在重基中间。
解决使用git重置——软:https://stackoverflow.com/a/5201642/2516916
自从git lfs 2.5.0以来,有一个新的命令可以让这变得更容易(docs):
git lfs migrate import --no-rewrite "broken file.jpg" "another broken file.png" ...
这将文件“迁移”到git lfs中,根据.gitattributes应该在lfs中,但目前没有(这就是出现错误消息的原因)。
——no-rewrite阻止git将此应用于旧的提交,而是创建一个新的提交。
使用-m "commitmessage"为该提交设置一个提交消息。