What you're describing is normal and expected. Let's say we are on main
and we have one file committed to our repo, 1.txt, and that it consists of
1
2
3
4
5
Now I'll make a change to that file and commit the change:
2
3
4
5
1
Call that commit unlinted changed
. Now I'll go back to the first commit and start a branch; call it linted
. Let's say that linting consists of adding semicolons to every line. So I lint and commit this:
1;
2;
3;
4;
5;
Now I'll edit that and commit the result.
2;
1;
3;
4;
5;
Now I will attempt to cherry-pick main
:
% git cherry-pick main
Auto-merging 1.txt
CONFLICT (content): Merge conflict in 1.txt
And this is exactly what we expect. The two files have, in essence, nothing in common. We can see this clearly if we look at the markup in the conflicted file (I use diff3 style):
% cat 1.txt
<<<<<<< HEAD
2;
1;
3;
4;
5;
||||||| parent of d00743b (unlinted changed)
1
2
3
4
5
=======
2
3
4
5
1
>>>>>>> d00743b (unlinted changed)
By cherry-picking, you are asking the text in the middle to turn simultaneously into the first text and the last text. That's impossible. No machine can figure out what's happened here; it takes a human. That's what a merge "conflict" is: it's a request for human assistance. Assist, as requested.