Cherry-pick with ignore whitespace / line-endings
So, for completeness, the answer is that the ignore-all-space
merge strategy does the job:
git cherry-pick -X ignore-all-space <commit-id>
And that will let you painlessly cherry-pick commits made when the file had, eg, windows line endings onto a version that has unix file endings.
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)<<<<< HEADIndent 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 1Indent 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.