Git: how to mark a file as conflicted after "git merge-file"?

Question

I've been using "git merge-file" to help me port code from a different repository. This works great.

However, when a merge conflict happens, though "git merge-file" will properly report it, the file isn't marked as needing resolution in "git status". In the status, the file is just seen as modified (understandably, since the merge happened outside of git's usual flow).

This is a problem because sometimes when importing a large number of files, I'll miss the message highlighting the conflict.

Is there a way to manually tell git that the file needs resolution?

I tried "git update-index --unmerged somefile", but that didn't appear to work: the file isn't listed as conflicted.

Answer 1

You must use git update-index --index-info or git update-index --stdin.

In particular, you must create nonzero stage index entries: up to three of them for each file. As the documentation notes, you should also remove the corresponding stage-zero entry (though you may want to make sure that it matches either the HEAD commit version or the work-tree version first, so as to avoid clobbering carefully-staged variants such as those made by git add -p).

Git represents a "failure to merge" case by writing nonzero-stage entries to the index. The work-tree version of the file can contain literally anything as it is entirely irrelevant (to the updating of the index, that is; see comments below). The stage-1 entry is the base version of the file; the stage-2 entry is the --ours version; the stage-3 entry is the --theirs version. Note that one or more of these may be missing, i.e., some stage slots may be empty. For instance, if the base version is missing, the original conflict was an "add/add" conflict.

Running git mergetool, for instance, extracts the three versions from the higher numbered stage entries and then invokes your chosen merge tool on the three input files. The git status command reports an unmerged state for the files.

Note that the content of the three versions must exist in the repository. To write content to the repository database, use git hash-object -w. See the git hash-object documentation for details. The update-index command takes the hash ID of the in-repository blob object (plus the mode, stage number, and name, of course).