Question

我正在尝试git bisect一个代码库来查找问题的根源。

检出较旧的修订版时，由于eol问题，文件正在被修改：

$ git status
HEAD detached at v1.9.3
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:   ports/stm32/usbdev/Release_Notes.html

由于此更改，git bisect被卡住了：

error: Your local changes to the following files would be overwritten by checkout:
        ports/stm32/usbdev/Release_Notes.html
Aborting

我正在上游代码库中处理历史提交，所以我无法修改.gitattributes，也不能修改文件并重新设置基准一切。

我尝试在此存储库中将core.safecrlf设置为false：

git config core.safecrlf false

...但是这似乎对该问题没有任何影响。是否有任何方法可以在不修改存储库本身中的文件的情况下覆盖Git对此文件的行为？

Answer 1

我承认这有点丑陋和可怕，但它似乎可以工作（请参阅注释）：对于Git抱怨的每个文件，只需删除工作树副本即可。例如，之后：

git bisect good

（或与bad相同），您收到有关ports/stm32/usbdev/Release_Notes.html的投诉。所以：

rm ports/stm32/usbdev/Release_Notes.html
git bisect good  # or bad

Git现在可以自由切换到下一个要测试的提交。

请勿盲目删除所有文件，因为下一次提交的git checkout将不提取与当前和下一次提交相同的文件。 Bisect确实应该有一种方法可以将-f传递到git checkout步骤，以处理git reset --hard HEAD由于行尾问题而仍留下修改后的文件的情况。嗯，那还是Git应该有一个更通用的方法来处理“由于行尾问题而导致存储库中的文件无法匹配工作树”的情况。

将core.safecrlf设置为false时，摆脱“警告：CRLF将被LF取代”不起作用

1 个答案: