I know this question is significantly old, but adding this answer because this is the first post from googling "git cherry-pick ignore whitespace".
Even though -X ignore-all-space
works fine, you have to manually check the commit if the cherry-pick without ignore space option had some conflicts. (or use --no-commit
while cherry-picking and git diff --staged
to review it)
In some cases, -X ignore-all-space
option looks fine, but some indentations are wrong.
For example, suppose you had some merge conflict with leading whitespace while not using ignore-all-space, like this:
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
In this case, -X ignore-all-space
shows no conflict but the actual commit will look like this:
Change from theirs, indent level 1
Indent level 0
What happened here is they changed logic so the previous code (Indent level 0) should be indented to level 1, but it didn't because you specified ignore-all-space option.
So the tl;dr is:
-X ignore-all-space
option also ignores leading whitespaces, which might be troublesome in some situations and languages like Python.
- So you have to manually review after using that option, or...
- Use
-X ignore-space-at-eol
instead, and handle leading whitespace conflicts manually.
But don't stop reading, because these options are not the main reason of this problems - the core of this problem is not everyone is sticking to same whitespace rules.
For leading&trailing whitespaces: use linting tools, or IDEs, or whatever to stick to same rules. This is not OS-specific and can be followed if your team puts some effort to making other developers' life easier.
For eol changes: this is OS-specific, but git fortunately supports core.autocrlf and core.eol for multi-platform development enveronment. see git-scm for more details.