Git:从源代码控制文件中删除回车符

发布于 2024-08-25 17:48:28 字数 211 浏览 6 评论 0原文

我有一个 Git 存储库,其中包含一些 DOS 格式的文件(\r\n 行结尾)。我只想通过 dos2unix 运行文件(这会将所有文件更改为 UNIX 格式,并以 \n 行结尾),但这会对历史记录产生多么严重的影响,以及是否值得推荐?

我假设标准是始终对源代码控制文件使用 UNIX 行结尾,并且可以选择在本地切换到特定于操作系统的行结尾?

I've got a Git repository that has some files with DOS format (\r\n line endings). I would like to just run the files through dos2unix (which would change all files to UNIX format, with \n line endings), but how badly would this affect history, and is it recommended at all?

I assume that the standard is to always use UNIX line endings for source-controlled files, and optionally switch to OS-specific line endings locally?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

葬﹪忆之殇 2024-09-01 17:48:28

当我们从 svn 转换到 git(在类似中央(裸)的)scm 环境中时,crlf 的事情让我们发疯。最终我们遇到的问题是,我们将全局 .gitconfig 文件复制到每个人的用户根目录(是的,Windows 和 Linux),第一个文件来自 Windows 系统,并且 core.autocrlf=true 和 core.safecrlf=false 这造成了严重破坏对于 Linux 用户(比如 bash 脚本不起作用以及所有那些可怕的 ^M)。因此,我们最初做了一个签出和克隆脚本,在这些命令之后执行了 dos2unix。然后我运行了 core.autocrlf 和 core.safecrlf 配置项,并根据操作系统设置它们:

Windows:core.autocrlf=true 和 core.safecrlf=false
Linux: core.autocrlf=input 和 core.safecrlf=false

这些设置为:
---在 Windows 上 ---

git config --global core.autocrlf true
git config --global core.safecrlf false

在 Linux 上 ---

git config --global core.autocrlf input
git config --global core.safecrlf false

然后,对于我们的 Linux 开发人员,我们设置了一个小 bash 脚本 /usr/local/bin/gitfixcrlf:

#!/bin/sh
# remove local tree
git ls-files -z | xargs -0 rm
# checkout with proper crlf
git checkout .

他们只需在本地沙箱克隆上运行一次。任何未来的克隆都已正确完成。现在任何未来的推拉都已正确处理。因此,这解决了我们的多个操作系统换行问题。另请注意,Mac 的配置与 Linux 相同。

This crlf thing drove us crazy when we converted from svn to git (in a central (bare) like) scm environment. The thing that ultimately got us was we copied the global .gitconfig file to everyone's user root (yep both windows and linux) with the initial one coming from a Windows system and having core.autocrlf=true and core.safecrlf=false which played havoc on the linux users (like bash scripts didn't work and all those awful ^M's). So we initially did a checkout and clone script that did a dos2unix after these commands. Then I ran across the core.autocrlf and core.safecrlf config items and set them based on the O/S:

Windows: core.autocrlf=true and core.safecrlf=false
Linux: core.autocrlf=input and core.safecrlf=false

These were set with:
---on Windows---

git config --global core.autocrlf true
git config --global core.safecrlf false

---on Linux---

git config --global core.autocrlf input
git config --global core.safecrlf false

Then for our Linux developers we setup a little bash script /usr/local/bin/gitfixcrlf:

#!/bin/sh
# remove local tree
git ls-files -z | xargs -0 rm
# checkout with proper crlf
git checkout .

Which they only had to run on their local sandbox clones once. Any future cloning was done correctly. Any future push pulls now were handled correctly. So, this solved our multiple O/S issues with linefeeds. Also Note that Mac falls in the same config as Linux.

无声静候 2024-09-01 17:48:28

您必须使用的方法取决于您的存储库的公开程度。

如果您不介意或不关心更改所有 SHA,因为您或多或少是唯一使用它的人,但希望始终解决此问题,您可以运行 git filter-branch 并将 dos2unix 应用于每次提交中的所有文件。 (如果您共享存储库,其他人或多或少都需要完全更新它,因此这有潜在的危险。)

因此,更好的选择也是更简单的方法是仅在当前头中更改它。这意味着您过去的提交仍然具有 \r\n 结尾,但除非您从过去进行了大量挑选,否则这应该不是问题。当然,差异工具可能会更频繁地抱怨,但通常您只会与附近的提交进行差异,因此随着提交的积累,这个问题会自行解决。

UNIX 行结尾是标准的,你是对的。最好的方法是将编辑器设置为仅在 Windows 上写入这些结尾。否则,您还可以使用 autocrlf 设置。


添加历史重写部分:

上次我做了同样的事情,我使用以下命令将所有文件更改为 unix 结尾。

#!/bin/bash
all2dos() { find * -exec dos2unix {} \; }
export -f all2dos
git filter-branch -f --tree-filter 'all2dos' --tag-name-filter cat --prune-empty -- --all

The approach you’ll have to use depends on how public your repository is.

If you don’t mind or care about changing all SHAs because you’re more or less the only one using it but want to have this issue sorted out for all times, you can run a git filter-branch and apply dos2unix to all files in each commit. (If you’re sharing the repository, everyone else needs more or less to completely renew it, so this is potentially dangerous.)

So the better option and also an easier way would be to change it only in the current heads. This means that your past commits still have \r\n endings but unless you’re doing much cherry-picking from the past this should not be a problem. The diff tools might complain a bit more often, of course, but normally you’ll only diff with commits in the vicinity, so this issue resolves itself as the commits accumulate.

And UNIX line endings are standard, you’re correct about that. Best approach is to setup your editor to only write these endings even on windows. Otherwise, there is also a autocrlf setting which you can use.


Addition to the history rewriting part:

Last time I did the same, I used the following command to change all files to unix endings.

#!/bin/bash
all2dos() { find * -exec dos2unix {} \; }
export -f all2dos
git filter-branch -f --tree-filter 'all2dos' --tag-name-filter cat --prune-empty -- --all
香草可樂 2024-09-01 17:48:28

对于持续的解决方案,请查看 core.autocrlf (和 core.safecrlf)配置参数< /a>.

对整个存储库执行一次此操作只会创建一个几乎不可能合并的提交(因为这些文件中的每一行都会被修改),但是一旦您通过了它,它应该没什么大不了的。 (是的,您可以使用 git filter-branch 来进行整个历史记录的修改,但这有点可怕。)

For the continuing solution, have a look at the core.autocrlf (and core.safecrlf) config parameters.

Doing this once to your whole repository will just create one commit that's pretty impossible to merge with (since every line in those files will be modified), but once you get past it, it should be no big deal. (Yes, you could use git filter-branch to make the modification all the way through history, but that's a bit scary.)

蓝梦月影 2024-09-01 17:48:28

如果您的版本控制文件列表包含二进制文件,或者您无法轻松更改历史记录...这里有一个方便的花哨单行:

https://unix.stackexchange.com/a/365679/112190

If your list of version controlled files includes binaries, or you can't change history easily... here is a handy dandy one-liner:

https://unix.stackexchange.com/a/365679/112190

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文