Is there a way to make Git mark a file as conflicted?

Question

It's possible to commit files that contains conflict data. Is there a way to mark these files as conflicted again, so that running git mergetool will generate the necessary files and run the merge tool?

score 46 · Answer 1 · answered May 18 '16 at 16:37

If the index is already in a conflict state, simply check out the file with the --conflict=merge flag:

git checkout --conflict=merge file

If the index is clean because the unresolved file has been [erroneously] added, just reset it before checking it out:

git reset file
git checkout --conflict=merge file

This will allow you to resume conflict resolution normally (e.g., git mergetool).

NOTE: Promoting a comment to @jakub-narębski's answer into its own answer by request from @fourpastmidnight. :)

Thanks @Gingi. I saved a bookmark to this because I knew I'd need it again, and today was the day. And as promised, +1!! — fourpastmidnight, Oct 18 '22 at 21:28

score 33 · Accepted Answer · answered May 07 '10 at 01:17

33

You can get contents of file with conflict markers using git checkout --conflict=merge -- file, but if you have cleaned up index by using git add file (or if GUI did that for you) it wouldn't work.

There is git update-index --unresolve, but it is hacky, and does not work very reliably. I think the state it restores would be not enough for git-mergetool.

You would probably have to redo merge, or use git update-index --cacheinfo to manually set stages version... git-stash can help you preserve correctly resolved conflicts.

answered May 07 '10 at 01:17

Jakub Narębski

309,089
65
217
230

1

Heh, I was just writing this response. ;-) – ebneter May 07 '10 at 01:24
2

what is hacky and unreliable about it? – Christian Neverdal May 10 '10 at 12:52
1

`git update-index --unresolve` was created in "ancient" times to allow to restore `git diff --ours` etc. after (accidental) `git add` confirming conflict resolution. It stuffs HEAD version (not version with automatically resolvable conflicts resolved) in stage #2, stuffs MERGE_HEAD version in stage #3, and doesn't put anything in stage #1, the ancestor version. – Jakub Narębski May 10 '10 at 21:37
So .. the answer is: "No, it's not possible, Git can easily corrupt the repository". Nice. (I'm in a situation where a file was committed from a remote machine that no-one currently has access to. "re-doing the merge" is physically impossible. – Adam Oct 16 '12 at 09:34
@Adam: That shouldn't matter. Before doing merge git always downloads (fetches) commits into current repository, so instead of doing `git pull ` you can do `git merge ` which is shortcut for `git merge /`, and `/` is remote-tracking branch. – Jakub Narębski Oct 16 '12 at 16:08
@JakubNarębski The repository has files commmited with conflicts INSIDE them (I believe: someone did "git pull", and there were so many changes that they didnt see the "CONFLICT" message scroll off top of screen. Then they committed some other change, and BANG! repository is now corrupt). It is now impossible to get git to treat those as "conflicted" files any more. In the end, I used a text editor (and spent a LOT of time) re-writing the affected files :(. – Adam Oct 16 '12 at 20:10
1

If somebody commits a mixture of conflicting merge and actual work, I fail to see how that's a case where "Git can easily corrypt the repository". Git has saved verbatim copy of the state this committer has asked, no matter how insane that state is. In the end, I'd probably redo the merge and then do `git diff` with the redone merge and this messed up merge commit. *That* diff hopefully contains roughly the changeset that was originally intended to be committed so you do not need to manually re-create all that work. – Mikko Rantalainen Apr 29 '13 at 06:11
9

If the index is clean because the unresolved file has been erroneously added, you can just reset it: `git reset file; git checkout --conflict=merge file`. – Gingi Feb 24 '14 at 23:20
1

@Gingi Awesome!! Just what I was looking for. I've been wanting to know how to do this for quite a while. You should make this an answer--I'd up-vote it! – fourpastmidnight May 18 '16 at 15:13

score 7 · Answer 3 · answered May 18 '10 at 15:08

7

The most elegant solution would be to prevent this problem from the very beginning:
git config --global mergetool.[tool].cmd [command-line call] git config --global mergetool.[tool].trustExitCode false

answered May 18 '10 at 15:08

Christian Neverdal

5,655
6
38
93

2

Yes. This will cause Git to ask every time if the file was merged successfully instead of relying on the merge tool itself to report success or failure truthfully. – Christian Neverdal Jul 12 '13 at 06:43
1

so does that mean it will not 'git add' the files unless you answer yes? I also have 'mergetool.prompt = false' will that affect this? – Superole Nov 11 '13 at 09:17
That is correct. I would think that mergetool.prompt would have to be true. – Christian Neverdal Nov 11 '13 at 13:20

score 2 · Answer 4 · edited May 23 '17 at 11:33

2

As far as I know, ~~you won't be able to commit while a file still contain conflict markers in it.~~... which is not exactly true:
The OP mentions that you can (I copy here his pastbin), but that won't be enough for the mergetool to be trigger again:

Auto-merged README
CONFLICT (content): Merge conflict in README
Automatic merge failed; fix conflicts and then commit the result.
lynx:~/test_clone$ ls
README
lynx:~/test_clone$ git add README
lynx:~/test_clone$ git commit -a
Created commit 46ee062: It works!
lynx:~/test_clone$ ls
README
lynx:~/test_clone$ cat README
<<<<<<< HEAD:README
testingtesting
=======
hmm
>>>>>>> 881d60f5f738bc5716f5c9a9384e262b535717fd:README
lynx:~/test_clone$

As Charles Bailey comments, and illustrates in this SO answer, the mergetool is queried because there are 3 instances of the same file in the index:

For an unmerged file in a conflict git makes available the common base, local and remote versions of the file in the index. (This is where they are read from for use in a 3-way diff tool by git mergetool.) You can use git show to view them:

# common base:
git show :1:afile.txt

# 'ours'
git show :2:afile.txt

# 'theirs'
git show :3:afile.txt

git add (with whatever content, including conflict markers) will automatically removes 2 of them, ensuring the mergetool won't be called again.

edited May 23 '17 at 11:33

Community

1
1

answered May 06 '10 at 11:50

VonC

1,262,500
529
4,410
5,250

Indeed you can. Merely doing a git add will remove the marker and you are then free to commit. http://pastebin.com/KKLtCZ35 – Christian Neverdal May 06 '10 at 17:53
@Christian: interesting (I have amended the answer to reflect it), but will the `git mergetool` detect it and re-trigger a merge? – VonC May 06 '10 at 18:14
git determines that a file is conflicted if it has multiple entries in the index, rather than just the usual one. git places conflict markers in the working tree version to help the user resolve the conflict but these are not how git counts the file as unmerged. Calling git add tells git to add the working tree version of the file to the index _removing all the other entries_. After git add, as there is now just a single index entry the file is no longer 'unresolved' so you can commit it. – CB Bailey May 06 '10 at 21:56
@Christian: completed my answer after Charles's comment. – VonC May 07 '10 at 04:16
1

@CharlesBailey Is it possible to add extra entry for a file in index to intentionally cause git to interpret a file as conflicting? I think that in some situations it would be nice to have fabricated conflicting versions in index after running custom merge driver... – Mikko Rantalainen Apr 29 '13 at 06:17

score 0 · Answer 5 · answered Jan 18 '15 at 17:28

0

Please use git update-index --unresolve

Since git 1.7 it uses resolve-undo info from the index to restore all 3 stages (1:base, 2:ours, 3:theirs): https://github.com/git/git/commit/8aa38563b22c84b06ea1fff9638cc1f44fda726f

answered Jan 18 '15 at 17:28

Dmitry Oksenchuk

121
1
4

Is there a way to make Git mark a file as conflicted?

5 Answers5

Linked

Related