Is it normal to have conflicts during applying a git patch?

Question

I have two repos let's say main repo and copy repo, and they have to get synced using patches. Their master branches are synced and I apply patches from main repo-dev branch on copy repo. And after creating a patch and applying it on copy repo, I merge dev branch into the master on main repo to keep them synced.

I have created the patch file on main repo using:

git format-patch origin/master..origin/develop --stdout > ../patches/patch-001.patch

and when I try to apply this patch on copy repo using:

git am -3 --ignore-space-change patch-001.patch 

I get Patch failed at 0002 ... and I have to resolve conflicts for almost every commit in the patch file.

The question is that is it normal to have conflicts during applying a patch? I have done this before but no such problems happened.

Resolving this amount of conflicts (for about 50 commits) is a very hard and confusing process. I'm using the PyCharm itself to resolve conflicts for every patch failure but still hard. Is there any easier way to do this?

Why these conflicts happen? Is it because I have merges between those commits?

Answer 1

It's neither "normal" nor "abnormal". It is what it is. If your white cat gets a slow-growing skin cancer on an ear-tip, it's easily removed via simple surgery. Is skin cancer on your light-skinned-cat's ear "normal"? It's not abnormal, if your cat goes outside: UV on low-melanin-content skin cells causes mutations, and sometimes those lead to basal cell cancer. You can keep your cat indoors (this is generally advised for most house cats anyway) but that's no guarantee that he won't get skin cancer on a pink ear-tip or nose either.¹

Why [do] these conflicts happen?

When Git is doing a merge, Git finds three input files. When you apply a patch, Git may choose to do a merge, if there's an index: line in the patch.² The index line tells Git what the original file was, to which the patch applies. Git can then apply the patch—which applies only to the original file at this point—to that original file to come up with "their file".

Git now has the same information it would use for any merge: the original file, your version of the file with your changes, and their version of the file with their changes. Git can now compare your changes to their changes, to see if they overlap.

If what they changed is independent of what you changed, Git will be able to combine these changes. For instance, suppose they fixed the spelling of the word speeling on line 10, and you didn't. Suppose that, instead, you fixed the lack of a copyright notice by adding 40 lines of copyright notice at the top of the file. Git will be able to see that the speeling line is now line 50, rather than line 10, and that it should apply their fix. Git will apply their fix and all will be well.

But if you also fixed the speeling line and some other words on the same line, Git doesn't know whether to take your fix or their fix. So Git now complains of a merge conflict on this line. That's because your changes affect the same lines of the base file that their changes affect. Git doesn't know which ones to use.

Is that normal? It is if you both changed the same lines of the same files. It all depends on what lines "you" changed, and what lines "they" changed, based on which common starting version of the file you both started from. It doesn't if you got those changes from someone else somewhere along the way: as long as they didn't have those changes in the version they started from, so that "your" changes (which include someone else's changes) and their changes overlap, you'll get a conflict.

Note that you get a conflict even if your changes and their changes don't exactly overlap. For instance, if they change lines 5-through-8 and you change line 9, these changes "touch at the edge" ("abut", to use the fancy word) and Git will call that a conflict too.

---

¹I had a solid-black kitty that got some kind of cancer on her nose, when I lived in Utah. So even plenty of melanin isn't a guarantee against this, though it helps. She had a pretty decent life though, making it to "senior kitty" status. Her sister died the previous year from kidney failure, so it's likely she might not have lasted much longer even if she'd made it through the cancer-removal surgery. Nose surgery is a much bigger deal than ear-tip clipping, unfortunately.

²If the patch lacks an index line, Git can't do a three-way merge. But this just means that a patch that doesn't apply fails, rather than trying a merge; you'll need the --reject flag, and you will have to hand-edit the patch result.