-1

We recently linted out entire codebase. Yay! But now we're struggling to forward port patches across the linted commit. For example we have branches V1 and V2. V2 was created by linting V1 at some point in time. Now we want to cherry-pick a commit from V1 (orange) onto the head of V2. I'm struggling to get the commit to cherry-pick cleanly without a ton of conflicts. Any suggestions?

enter image description here

Edit: This is what I've tried

git checkout orange
Apply lint
git commit --amend --no-edit

At this point I have a orange' So far I've tried

git rebase HEAD~ --onto origin/V2
AND
git checkout origin/V2
git cherry-pick orange'


EncryptedWatermelon
  • 4,788
  • 1
  • 12
  • 28
  • What have you tried exacly. `git checkout V1; git cherrypick ` should do the job. If you have conflicts then there is no choice just to resolve them. – Marek R Jul 15 '22 at 12:23
  • Create a new commit from autoformatting V1 then apply that to V2 – mousetail Jul 15 '22 at 12:23
  • What you're experiencing is totally normal and expected. There is no magic path between an edited linked version of a file and a differently edited nonlinted version of the same file. You need to do the resolution manually. – matt Jul 15 '22 at 12:26
  • @mousetail the problem with formatting V1 again is we only want the specific changes in the orange commit. – EncryptedWatermelon Jul 15 '22 at 14:34

2 Answers2

0

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.

matt
  • 515,959
  • 87
  • 875
  • 1,141
-1

Got it to work

git checkout orange
Apply lint
git commit --amend --no-edit
git checkout origin/V2
git cherry-pick orange' -X theirs'
EncryptedWatermelon
  • 4,788
  • 1
  • 12
  • 28
  • 1
    `-X theirs` (which can be spelled a couple of other ways too) tells Git: *whenever there is a conflict, blindly use the #3 file in the index to resolve the conflict*. The #3 file is the one Git calls `--theirs`, though during cherry-picking, it's either ours or a mishmash of ours-and-theirs. The idea of telling Git to use that one *without checking if that's the right one* is rarely a very good idea (it's only good if you're sure, which usually means "I already did it by hand once and found out"). – torek Jul 15 '22 at 14:24