Is there any way to force a Git merge conflict without touching branches?

Question

Situation:

I have a branch master and a branch feature . I want to make changes in feature and PR them to master, with some of the changes being marked as merge conflicts.

To illustrate, say there's a file test.txt in branch master like this.

foo

Feature looks like this

bar
zed

I want to create a PR from feature master where some changes (eg the change from foo to bar) are marked as merge conflicts and must be manually resolved. Meanwhile, some changes, like the addition of zed, are not marked as conflicts. Essentially, I need manual intervention on those kind of conflicts to be marked and resolved before the PR can be closed, but I don't want all of the changes to be reviewed.

Is there any way to do this? Potentially by writing git conflict markers manually into feature?

Answer 1

Is there any way to do this?

Only by creating an actual conflict.

Merges that can have conflicts ¹ have three inputs:

1. a merge base: the common commit from which the other two commits descend, for git merge , or an artificially chosen commit for git cherry-pick or git revert , for instance;
2. the current commit ( HEAD or --ours , or sometimes local );
3. the other commit (sometimes called other or remote or --theirs ).

A low-level (in-the-file) conflict occurs when:

• there is a difference in some file as seen in the output of git diff --find-renames from the merge base to the current copy of the file, and
• there is a difference in the same file as seen in the output of git diff --find-renames from the merge base to the other commit, and
• these changes touch the same lines, or otherwise abut (the end of one is the beginning of the other).

In this particular case, when Git tries to combine the two sets of changes, the changes will collide and you'll see a conflict, unless you use -Xours or -Xtheirs to automatically choose one out of the two conflicting changes.

(High level conflicts also have the same three inputs, but occur when, eg, one side of the diff modifies the file, and the other side removes the file. There's no set-of-lines in which to have a conflict, but there is still a conflict: should Git keep the modified file, or delete the file entirely?)

---

¹ Any true merge—by which I mean the process of merging, or to merge as a verb—can have conflicts. The phrasing here is meant to paper over the fact that git merge sometimes does not perform a merge, when it does a fast-forward operation.