gpt4 book ai didi

git: fix CRLF mess retroactively(Git:追溯修复CRLF混乱)

转载 作者:bug小助手 更新时间:2023-10-26 21:09:34 28 4
gpt4 key购买 nike



I mistakenly committed some files with the CRLF line endings.

我错误地提交了一些以CRLF行结尾的文件。


Now I set core.autocrlf = false and fixed the files locally (in the editor).

现在我设置了core.autocrlf = false并在本地修复了这些文件(在编辑器中)。


Is there a way to fix this (e.g., using some combination of rebase -i &c) so that CRLF completely disappear from history permanently?

有没有办法解决这个问题(例如,使用rebase-i和c的某种组合),以便CRLF完全从历史中永久消失?


更多回答

this seem to contain useful hints, hope it helps (see also the contained "renormalize" info): aleksandrhovhannisyan.com/blog/…

这似乎包含有用的提示,希望它能有所帮助(另请参阅所包含的“重新规范化”信息):aleksandrhovhannisyan.com/blog/.

If you use rebase -i, you can always squash the commit that introduced the CRLFs with the one the removed them and there won't be a trace in history after that.

如果您使用rebase-i,您总是可以用删除它们的提交来挤压引入CRFL的提交,并且在那之后将不会有任何历史痕迹。

@DecimalTurn: how do I know which commit introduced CRLF? What if a commit that killed CRLFs was also doing something else?

@DecimalTurn:我怎么知道哪个提交引入了CRLF?如果一个杀死CRLF的提交也在做其他事情呢?

Hopefully the list of possible commits isn't too long and you can check them individually with one of the commands here. Some Git UI tools also offer the possibility to see line endings in the diff.

希望可能提交的列表不会太长,您可以使用下面的命令之一单独检查它们。一些GitUI工具还提供了在diff中查看行尾的可能性。

Regarding the case where the commit "that killed CRLFs" is also doing something else, it depends. If it's important for you to keep each commit doing only one thing, then squashing won't work. You could instead use the "edit" option for the commit that introduced CRLFs and replace the CRLFs with LFs in an editor (or the command dos2unix <filename> is also an option). Note however that you might have some merge conflicts to resolve afterwards if you've edited the same lines in future commits.

至于“杀死CRLF的人”还在做其他事情的情况,这要视情况而定。如果让每个提交只做一件事对您来说很重要,那么挤压是行不通的。相反,您可以对引入CRFL的COMMIT使用“EDIT”选项,并在编辑器中用LFS替换CRFL(或者命令dos2unix也是一个选项)。但是,请注意,如果您在以后的提交中编辑了相同的行,则可能需要在以后解决一些合并冲突。

优秀答案推荐

I mentioned:

我提到过:



Using a git rebase -x, you could call a script which would git add --renormalize ., to make sure your local Git config is applied.

使用git rebase-x,您可以调用一个脚本来添加git--renormal ize.,以确保应用您本地的Git配置。




Guildenstern also points out in the comments to git test fix

吉尔登斯特恩还在评论中指出了git测试修复



The git test fix subcommand can run command such as a formatter or linter and apply its resulting changes to each provided commit.

For example: git test fix --exec 'cargo fmt --all'.


Preventing merge conflicts


It can be difficult to apply formatter or linter changes by hand (with e.g. git rebase --exec) because it necessarily rebases the descendants of fixed commits.

This oftentimes causes merge conflicts that are about to be resolved by formatting or linting the next commit. (As a workaround, some people try fixing the commits in reverse topological order to minimize the chances of merge conflicts.)


git test fix never produces merge conflicts because it fixes each commit in isolation by replacing its the tree OID directly, and leaves descendant commits otherwise unchanged. (You can do the same thing by hand by calling git amend with the --reparent option)



See git test fix in action here.

请参阅此处的Git测试修复程序。


更多回答

28 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com