git merge:过滤文件以避免愚蠢的冲突(例如空格或大小写更改)

发布于 2024-10-15 03:57:43 字数 201 浏览 4 评论 0原文

我目前在 git 中进行一个非常复杂的合并,并且有很多冲突。冲突涉及两个 Ada 源文件。

我想要进行合并,忽略空格更改和大小写更改(因为 Ada 语言不区分大小写)。 你知道是否有办法告诉 git 在合并之前忽略某种更改?

我的解决方案目前是在合并之前在两个分支上运行 GNAT 漂亮的打印,但如果 git 中包含一个通用的解决方案,那将对我有很大帮助。

I'm currently inside a very complicated merge in git, and I have many conflicts. The conflict is about two Ada source files.

I would like to make a merge that would ignore both whitespace changes and case changes (as the Ada language is case insensitive).
Do you know if there is a way to tell git to ignore some kind of changes before a merge ?

My solution is currently to run the GNAT pretty print on both branches before the merge, but if there was a common solution included in git, that would help me a lot.

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

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

发布评论

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

评论(2

薄荷→糖丶微凉 2024-10-22 03:57:43

来自 git 1.7 的发行说明 .4:

* “递归”策略还学会了忽略各种空格
变化;最值得注意的是 -Xignore-space-at-eol。

我不知道是否有一种策略可以忽略大小写的变化

from the release notes of git 1.7.4:

* The "recursive" strategy also learned to ignore various whitespace
changes; the most notable is -Xignore-space-at-eol.

I don't know if there is a strategy to ignore case changes though

无言温柔 2024-10-22 03:57:43

关于大小写问题,这在合并期间在不区分大小写的操作系统上是有问题的,这对于 git 2.0.1+ 来说不会是问题(2014 年 6 月 25 日)。

请参阅 提交 ae352c7f37ef2098e03ee86bc7fd75b210b17683 作者:大卫·特纳 (dturner-tw)

merge-recursive.c:修复大小写更改合并错误

在不区分大小写的文件系统上,合并时,如果传入提交已重命名文件,仅更改其大小写,则该文件将从工作树中错误地删除。
合并重命名时,旧名称的文件将被删除 - 但由于文件系统认为旧名称与新名称相同,因此新文件实际上将被删除。

我们通过不在阶段 0 的索引中删除具有案例克隆的文件来避免这种情况。

Regarding the case issue, which is problematic on case insensitive OS during a merge, this won't be an issue with git 2.0.1+ (June 25, 2014).

See commit ae352c7f37ef2098e03ee86bc7fd75b210b17683 by David Turner (dturner-tw)

merge-recursive.c: fix case-changing merge bug

On a case-insensitive filesystem, when merging, a file would be wrongly deleted from the working tree if an incoming commit had renamed it changing only its case.
When merging a rename, the file with the old name would be deleted -- but since the filesystem considers the old name to be the same as the new name, the new file would in fact be deleted.

We avoid this by not deleting files that have a case-clone in the index at stage 0.

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