git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Improving merge of tricky conflicts

From
Junio C Hamano <gitster@pobox.com>
Date
Jul 24, 2020, 06:01 UTC
Message-ID
<xmqqblk5moxx.fsf@gitster.c.googlers.com>
In-Reply-To
<CA+P7+xpPDu900dao08wfYtZ2pqU89D9vmwQPuFT-z5S5b-DXNA@mail.gmail.com>
Jacob Keller <jacob.keller@gmail.com> writes:
Show 12 quoted lines
> On Thu, Jul 23, 2020 at 2:43 PM Junio C Hamano <gitster@pobox.com> wrote:
>> If your merge used the merge (as opposed to diff3) style, and seeing
>> that the resulting conflict is not easy to review and you wish you
>> used diff3 style instead, it is way too late for any option to "git
>> merge" to help you.
>>
>> But having an option to "git checkout" lets you move forward from
>> that state, so it also makes 100% more sense than an option to "git
>> merge".
>
> Perhaps the issue is just that it's not discoverable easily because
> it's a different command.
That may be true.

By the way, "git checkout --conflict=<style>" is a short-hand for "git checkout --merge --conflict=<style>" and it is quite useful not just in the said case of "oops, I cannot read this conflict with the 'merge' style---let's switch to 'diff3' style". After starting to attempt resolving the conflict, sometimes I become unsure if the resolution I've been working on is correct, and want to start from scratch. In such a case, even without switching the style to a different one, "git checkout --merge" to discard the changes I made in the working tree file and reproduce the auto-merged state with conflict markers, is a good tool in your toolbox to know (being able to give a different conflict style is merely a natural extension of the feature).

Perhaps in Documentation/git-merge.txt there can be a mention of
	When you really screwed up your resolution, you could use
	"git checkout --merge -- $paths" to revert selected paths
	back to the state just before the auto-merge gave up and
	asked your help in resolving.  The --conflict=<style> option
	can be used instead of the "--merge" option in the command
	to use a different conflict marking style.  See
	git-checkout[1] for details.

or something along that line. People who are unware of "checkout -m" in such a situation may run "git reset --hard" and redo the whole merge from scratch, but you do not have to discard the resolution you made in other paths successfully only to redo a few files that you botched.

Previous: Jacob KellerNext: Sergey Organov
Message 20 of 25 in “Improving merge of tricky conflicts”
  1. B. SteblerJul 21, 2020
  2. Johannes SixtJul 22, 2020
  3. Jeff KingJul 22, 2020
  4. Junio C HamanoJul 22, 2020
  5. Jeff KingJul 23, 2020
  6. Junio C HamanoJul 24, 2020
  7. Jeff KingJul 24, 2020
  8. Junio C HamanoJul 24, 2020
  9. Martin von ZweigbergkJan 16, 2021
  10. Jeff KingJan 21, 2021
  11. Martin von ZweigbergkJan 21, 2021
  12. Jeff KingJan 21, 2021
  13. Sergey OrganovJul 22, 2020
  14. Junio C HamanoJul 22, 2020
  15. Sergey OrganovJul 22, 2020
  16. Jeff KingJul 23, 2020
  17. Sergey OrganovJul 23, 2020
  18. Junio C HamanoJul 23, 2020
  19. Jacob KellerJul 24, 2020
  20. Junio C HamanoJul 24, 2020
  21. Sergey OrganovJul 24, 2020
  22. Junio C HamanoJul 24, 2020
  23. Sergey OrganovJul 24, 2020
  24. Junio C HamanoJul 24, 2020
  25. Bono SteblerJul 22, 2020

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.