Cherry-pick with ignore whitespace / line-endings
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...
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) <<<<< 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.