Re: [PATCH] reset: --unmerge
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- Oct 25, 2016, 11:06 UTC
- Message-ID
- <CACsJy8B-GcMNv7pYYLpaUXc2kKnvyYEYm6w=fiaHy7rt4aug1Q@mail.gmail.com>
- In-Reply-To
- <xmqqa8dttkbw.fsf@gitster.mtv.corp.google.com>
On Tue, Oct 25, 2016 at 6:10 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 19 quoted lines
> 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.
Show 5 quoted lines
> 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