Cherry-pick with ignore whitespace / line-endings

Question

is there a way to tell git cherry-pick to use the renormalize merge strategy? I'm not sure the -X option is working.

I have a bunch of commits that seem to assume one type of line ending, and I'm trying to apply them to a branch that assumes another. Not having a good time...

Answer 1

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.

Answer 2

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:

1. -X ignore-all-space option also ignores leading whitespaces, which might be troublesome in some situations and languages like Python.
2. So you have to manually review after using that option, or...
3. 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.