樱桃选择忽略空格/行结尾

hwj*_*wjp 23 linux git line-endings

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

我有一堆提交似乎假设一种类型的行结束,我正在尝试将它们应用于假设另一种类型的分支.没有好时光......

hwj*_*wjp 36

因此,为了完整性,答案是ignore-all-space合并策略完成工作:

git cherry-pick -X ignore-all-space <commit-id>
Run Code Online (Sandbox Code Playgroud)

这将让你轻松地挑选文件时提交的提交,例如,windows行结尾到具有unix文件结尾的版本.


ik1*_*1ne 5

我知道这个问题已经很老了,但是添加这个答案是因为这是谷歌搜索“git cherry-pick 忽略空格”的第一篇文章。

即使-X ignore-all-space工作正常,如果不带忽略空间的cherry-pick 选项有一些冲突,您也必须手动检查提交。(或--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
Run Code Online (Sandbox Code Playgroud)

在这种情况下,-X ignore-all-space显示没有冲突,但实际提交将如下所示:

    Change from theirs, indent level 1
Indent level 0
Run Code Online (Sandbox Code Playgroud)

这里发生的事情是他们改变了逻辑,所以之前的代码(缩进级别 0)应该缩进到级别 1,但它没有因为你指定了 ignore- all -space选项。

所以 tl;dr 是:

  1. -X ignore-all-space option 还会忽略前导空格,这在某些情况下和 Python 等语言中可能会很麻烦。
  2. 因此,您必须在使用该选项后手动查看,或者...
  3. -X ignore-space-at-eol改为使用,并手动处理前导空白冲突。

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

对于前导和尾随空格:使用 linting 工具或 IDE 或任何遵循相同规则的工具。这不是特定于操作系统的,如果您的团队努力让其他开发人员的生活更轻松,则可以遵循。

对于 eol 更改:这是特定于操作系统的,但幸运的是 git 支持 core.autocrlf 和 core.eol 用于多平台开发环境。有关更多详细信息,请参阅git-scm

  • [`ignore-cr-at-eol`](https://git-scm.com/docs/git-merge#Documentation/git-merge.txt-ignore-cr-at-eol) 策略在我的情况也是如此。即`-Xignore-cr-at-eol`。([附加说明](https://git-scm.com/docs/git-diff#Documentation/git-diff.txt---ignore-cr-at-eol))。 (2认同)