使用忽略空格/行末的方式进行Cherry-pick

Question

有没有办法告诉git cherry-pick使用renormalize合并策略？我不确定-X选项是否有效。

我有一堆提交似乎假定了一种行尾，而我正在尝试将它们应用于另一个使用另一种行尾的分支。 感觉很不好...

- hwjp

---

我想我可能已经回答了自己的问题。-X renormalize 不起作用，但是 -X ignore-all-space 能够完成任务... - hwjp

Answer 1

因此，为了完整起见，答案是 ignore-all-space 合并策略会完成工作：

git cherry-pick -X ignore-all-space <commit-id>

并且，这将让您轻松地挑选一些提交过的内容，比如在文件有Windows换行符时进行的提交，然后应用到具有Unix换行符版本中。

- hwjp

Answer 2

我知道这个问题已经很老了，但是还是回答一下，因为这是从谷歌搜索“git cherry-pick ignore whitespace”得到的第一个帖子。

尽管 -X ignore-all-space 可以正常工作，但如果不使用忽略空格选项进行 cherry-pick 时出现冲突，您必须手动检查提交。（或者在 cherry-picking 时使用 --no-commit 并使用 git diff --staged 进行审核）

在某些情况下，-X ignore-all-space 选项看起来很好，但是某些缩进是错误的。

例如，假设您在不使用 ignore-all-space 的情况下遇到了一些前导空格的合并冲突，就像这样：

    Change from theirs, Indent level 1(no conflict with/out whitespace)
<<<<< HEAD
Indent level 0
=====
    Indent level 1 without any code change
>>>>> cherry-picked commit

在这种情况下，-X ignore-all-space不会显示任何冲突，但实际提交将如下所示：

    Change from theirs, indent level 1
Indent level 0

这里发生的事情是更改了逻辑，所以先前的代码（缩进级别0）应该缩进到级别1，但由于指定了忽略所有空格选项，因此并没有缩进。

所以 tl;dr 是：

1. -X 忽略所有空格选项还会忽略前导空格，在某些情况下和像 Python 这样的语言可能会有问题。 2. 因此，在使用该选项后必须手动进行审核，或者... 3. 使用 -X 忽略行尾空格选项，手动处理前导空格冲突。

但不要停止阅读，因为这些选项不是问题的主要原因 - 问题的核心是不是每个人都遵循相同的空格规则。

对于前导和尾随空格：使用 linting 工具、IDE 或其他工具来遵循相同的规则。这与操作系统无关，如果您的团队付出一些努力使其他开发人员的生活更轻松，那么可以遵循这些规则。

针对行尾符的变化：这取决于操作系统，但是幸运的是，为了支持多平台开发环境，Git 支持 core.autocrlf 和 core.eol。有关更多详细信息，请参见 git-scm。

- ik1ne

---

ignore-cr-at-eol 策略在我的情况下也很有用。即 -X ignore-cr-at-eol。（附加说明）。 - Cryptor