git: How automatically merge non-conflicting changes in the same file?

Question

I am trying to resolve a git conflict.

Let's say I have a file versions.json which is already existing in the repo:

{
  "a": {
    "name": "component-a",
    "version": 1,
  },
  "b": {
    "name": "component-b",
    "version": 1,
  },
}

Then,

• there is a CI pipeline with parallel stages. One building "component-a", the second building "component-b", both being in a monorepo.
• When "component-a" completes, it updates the file and sets "version": 2 in "a"
• When "component-b" completes, it updates the file and sets "version": 2 in "b"
• Each component will
• Do the changes
• commit the changes
• do a git pull --rebase
• do a git push

This fails with a merge conflict:

Rebasing (1/2)
Auto-merging versions.json
CONFLICT (add/add): Merge conflict in versions.json
error: could not apply 29b568d2... <previous commit message>

Components will never change the same line, so there is no real conflict IMO.

I tried to add a pull BEFORE the commit which works most of the time, but as the monorepo is quite big it takes time and some time which results in a race condition where one component commits during the pull of the other.

So I would like to fix it on the final push or pull directly.

Is there a way to do this in an automated fashion without human interaction?

Answer 1

The title is a trick question:

How automatically merge non-conflicting changes in the same file?

That's what already happens, and it's what will happen as soon as you fix the actual problem, which is simply that your parallel pipeline stages need to start from a shared commit where the file already exists. The reason is in Git, conflicts can only be automatically resolved in a "Modify vs Modify" scenario. If one or both sides "Add" or "Delete" the file, then automatic conflict resolution will not occur.

Since you are rebasing 2 commits instead of 1, which we can see from the output:

Rebasing (1/2)

And since the conflict is:

CONFLICT (add/add): Merge conflict in versions.json

We know that the first commit being rebased must be the commit where the file gets added, and the second commit is where the file is modified. The first commit is not the same ID for each stage of the pipeline, which is causing the "add/add" conflict.

The fix, is to sync up all of the stages so they are starting from the same commit ID which already includes the file, and from then on re-running the pipeline should be able to auto-resolve the file as you expect, because the line changes are all more than 2 lines apart.