On Tue, Oct 25, 2016 at 6:10 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > The procedure to resolve a merge conflict typically goes like this: > > - first open the file in the editor, and with the help of conflict > markers come up with a resolution. > > - save the file. > > - look at the output from "git diff" to see the combined diff to > double check if the resolution makes sense. > > - perform other tests, like trying to build the result with "make". > > - finally "git add file" to mark that you are done. > > and repeating the above until you are done with all the conflicted > paths. If you, for whatever reason, accidentally "git add file" by > mistake until you are convinced that you resolved it correctly (e.g. > doing "git add file" immediately after saving, without a chance to > peruse the output from "git diff"), there is no good way to recover. I made this exact mistake on a giant, half-resolved merge conflict the other day and panicked. While I prepared myself to script update-index to restore stages 2 and 3, I found "update-index --unresolve". It sounds like this "reset --unmerge" is the same functionality, right? I'm not objecting this patch though, update-index is not something a casual user should use. > There is "git checkout -m file" but that overwrites the working tree > file to reproduce the conflicted state, which is not exactly what > you want. You only want to reproduce the conflicted state in the > index, so that you can inspect the (proposed) merge resolution you > already have in your working tree. -- Duy