From: "Julia Evans via GitGitGadget" <gitgitgadget@gmail.com>
To: git@vger.kernel.org
Cc: ps@pks.im, Julia Evans <julia@jvns.ca>, Julia Evans <julia@jvns.ca>
Subject: [PATCH 2/7] [doc] git-merge: link to new merge conflicts guide
Date: Thu, 24 Sep 2026 14:44:17 +0000 [thread overview]
Message-ID: <a1686a2d82ef9357ecff07c1247092d3dd5ecf95.1790261062.git.gitgitgadget@gmail.com> (raw)
In-Reply-To: <pull.2237.git.1790261062.gitgitgadget@gmail.com>
From: Julia Evans <julia@jvns.ca>
All of the info about merge conflicts has been moved to the new guide
Signed-off-by: Julia Evans <julia@jvns.ca>
---
Documentation/git-merge.adoc | 125 +----------------------------------
1 file changed, 3 insertions(+), 122 deletions(-)
diff --git a/Documentation/git-merge.adoc b/Documentation/git-merge.adoc
index a055384ad6..5b7b41cd10 100644
--- a/Documentation/git-merge.adoc
+++ b/Documentation/git-merge.adoc
@@ -49,7 +49,8 @@ a log message from the user describing the changes. Before the operation,
A merge stops if there's a conflict that cannot be resolved
automatically or if `--no-commit` was provided when initiating the
merge. At that point you can run `git merge --abort` or `git merge
---continue`.
+--continue`. See linkgit:gitmergeconflicts[7]
+(or `git help mergeconflicts`) for a guide to handling merge conflicts.
`git merge --abort` will abort the merge process and try to reconstruct
the pre-merge state. However, if there were uncommitted changes when the
@@ -231,127 +232,6 @@ git merge v1.2.3^0
git merge --ff-only v1.2.3
----
-HOW CONFLICTS ARE PRESENTED
----------------------------
-
-During a merge, the working tree files are updated to reflect the result
-of the merge. Among the changes made to the common ancestor's version,
-non-overlapping ones (that is, you changed an area of the file while the
-other side left that area intact, or vice versa) are incorporated in the
-final result verbatim. When both sides made changes to the same area,
-however, Git cannot randomly pick one side over the other, and asks you to
-resolve it by leaving what both sides did to that area.
-
-By default, Git uses the same style as the one used by the "merge" program
-from the RCS suite to present such a conflicted hunk, like this:
-
-------------
-Here are lines that are either unchanged from the common
-ancestor, or cleanly resolved because only one side changed,
-or cleanly resolved because both sides changed the same way.
-<<<<<<< yours:sample.txt
-Conflict resolution is hard;
-let's go shopping.
-=======
-Git makes conflict resolution easy.
->>>>>>> theirs:sample.txt
-And here is another line that is cleanly resolved or unmodified.
-------------
-
-The area where a pair of conflicting changes happened is marked with markers
-+<<<<<<<+, `=======`, and +>>>>>>>+. The part before the `=======`
-is typically your side, and the part afterwards is typically their side.
-
-The default format does not show what the original said in the conflicting
-area. You cannot tell how many lines are deleted and replaced with
-Barbie's remark on your side. The only thing you can tell is that your
-side wants to say it is hard and you'd prefer to go shopping, while the
-other side wants to claim it is easy.
-
-An alternative style can be used by setting the `merge.conflictStyle`
-configuration variable to either `diff3` or `zdiff3`. In `diff3`
-style, the above conflict may look like this:
-
-------------
-Here are lines that are either unchanged from the common
-ancestor, or cleanly resolved because only one side changed,
-<<<<<<< yours:sample.txt
-or cleanly resolved because both sides changed the same way.
-Conflict resolution is hard;
-let's go shopping.
-||||||| base:sample.txt
-or cleanly resolved because both sides changed identically.
-Conflict resolution is hard.
-=======
-or cleanly resolved because both sides changed the same way.
-Git makes conflict resolution easy.
->>>>>>> theirs:sample.txt
-And here is another line that is cleanly resolved or unmodified.
-------------
-
-while in `zdiff3` style, it may look like this:
-
-------------
-Here are lines that are either unchanged from the common
-ancestor, or cleanly resolved because only one side changed,
-or cleanly resolved because both sides changed the same way.
-<<<<<<< yours:sample.txt
-Conflict resolution is hard;
-let's go shopping.
-||||||| base:sample.txt
-or cleanly resolved because both sides changed identically.
-Conflict resolution is hard.
-=======
-Git makes conflict resolution easy.
->>>>>>> theirs:sample.txt
-And here is another line that is cleanly resolved or unmodified.
-------------
-
-In addition to the +<<<<<<<+, `=======`, and +>>>>>>>+ markers, it uses
-another +|||||||+ marker that is followed by the original text. You can
-tell that the original just stated a fact, and your side simply gave in to
-that statement and gave up, while the other side tried to have a more
-positive attitude. You can sometimes come up with a better resolution by
-viewing the original.
-
-
-HOW TO RESOLVE CONFLICTS
-------------------------
-
-After seeing a conflict, you can do two things:
-
- * Decide not to merge. The only clean-ups you need are to reset
- the index file to the `HEAD` commit to reverse 2. and to clean
- up working tree changes made by 2. and 3.; `git merge --abort`
- can be used for this.
-
- * Resolve the conflicts. Git will mark the conflicts in
- the working tree. Edit the files into shape and
- `git add` them to the index. Use `git commit` or
- `git merge --continue` to seal the deal. The latter command
- checks whether there is a (interrupted) merge in progress
- before calling `git commit`.
-
-You can work through the conflict with a number of tools:
-
- * Use a mergetool. `git mergetool` to launch a graphical
- mergetool which will work through the merge with you.
-
- * Look at the diffs. `git diff` will show a three-way diff,
- highlighting changes from both the `HEAD` and `MERGE_HEAD`
- versions. `git diff AUTO_MERGE` will show what changes you've
- made so far to resolve textual conflicts.
-
- * Look at the diffs from each branch. `git log --merge -p <path>`
- will show diffs first for the `HEAD` version and then the
- `MERGE_HEAD` version.
-
- * Look at the originals. `git show :1:filename` shows the
- common ancestor, `git show :2:filename` shows the `HEAD`
- version, and `git show :3:filename` shows the `MERGE_HEAD`
- version.
-
-
EXAMPLES
--------
@@ -406,6 +286,7 @@ linkgit:git-reset[1],
linkgit:git-diff[1], linkgit:git-ls-files[1],
linkgit:git-add[1], linkgit:git-rm[1],
linkgit:git-mergetool[1]
+linkgit:gitmergeconflicts[7]
GIT
---
--
gitgitgadget
next prev parent reply other threads:[~2026-09-24 14:44 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-24 14:44 [PATCH 0/7] [doc] Add new page on merge conflicts Julia Evans via GitGitGadget
2026-09-24 14:44 ` [PATCH 1/7] [doc] Add new gitmergeconflicts man page Julia Evans via GitGitGadget
2026-09-24 20:36 ` Junio C Hamano
2026-09-24 22:04 ` Junio C Hamano
2026-09-30 13:19 ` Patrick Steinhardt
2026-09-30 19:53 ` Julia Evans
2026-09-30 20:37 ` Junio C Hamano
2026-10-01 5:14 ` Patrick Steinhardt
2026-10-01 12:10 ` Julia Evans
2026-10-02 17:58 ` Junio C Hamano
2026-10-05 16:54 ` Julia Evans
2026-10-05 17:22 ` Junio C Hamano
2026-10-05 19:11 ` Julia Evans
2026-09-24 14:44 ` Julia Evans via GitGitGadget [this message]
2026-09-25 16:36 ` [PATCH 2/7] [doc] git-merge: link to new merge conflicts guide D. Ben Knoble
2026-09-25 16:59 ` Julia Evans
2026-09-25 18:19 ` Junio C Hamano
2026-09-25 19:32 ` Ben Knoble
2026-09-25 21:49 ` Junio C Hamano
2026-09-25 19:34 ` Ben Knoble
2026-10-02 17:01 ` Julia Evans
2026-10-02 17:50 ` Junio C Hamano
2026-10-02 18:53 ` Julia Evans
2026-10-02 21:38 ` Junio C Hamano
2026-10-03 2:25 ` D. Ben Knoble
2026-10-03 4:12 ` Junio C Hamano
2026-09-30 13:19 ` Patrick Steinhardt
2026-09-24 14:44 ` [PATCH 3/7] [doc] git-rebase: " Julia Evans via GitGitGadget
2026-09-24 14:44 ` [PATCH 4/7] [doc] git-revert: " Julia Evans via GitGitGadget
2026-09-24 14:44 ` [PATCH 5/7] [doc] git-cherry-pick: " Julia Evans via GitGitGadget
2026-09-25 17:17 ` Junio C Hamano
2026-09-28 20:58 ` Julia Evans
2026-09-28 21:25 ` Junio C Hamano
2026-09-24 14:44 ` [PATCH 6/7] [doc] git-pull: " Julia Evans via GitGitGadget
2026-09-24 14:44 ` [PATCH 7/7] [doc] ignore conflict markers in gitmergeconflicts.adoc Julia Evans via GitGitGadget
2026-10-07 21:21 ` Junio C Hamano
2026-10-09 12:06 ` Julia Evans
2026-09-24 22:20 ` [PATCH 0/7] [doc] Add new page on merge conflicts Junio C Hamano
2026-09-24 23:37 ` Jeff King
2026-09-28 20:41 ` Julia Evans
2026-09-29 1:32 ` Jeff King
2026-09-29 1:56 ` Junio C Hamano
2026-09-25 16:25 ` D. Ben Knoble
2026-10-02 17:39 ` Julia Evans
2026-10-03 2:29 ` D. Ben Knoble
2026-10-05 18:49 ` Julia Evans
2026-10-06 16:53 ` D. Ben Knoble
2026-10-06 17:09 ` D. Ben Knoble
2026-10-09 12:00 ` [PATCH v2 0/6] " Julia Evans via GitGitGadget
2026-10-09 12:00 ` [PATCH v2 1/6] doc: add new gitmergeconflicts man page Julia Evans via GitGitGadget
2026-10-09 17:58 ` Junio C Hamano
2026-10-09 18:53 ` Julia Evans
2026-10-09 12:00 ` [PATCH v2 2/6] doc: git-merge: link to new merge conflicts guide Julia Evans via GitGitGadget
2026-10-09 18:20 ` Junio C Hamano
2026-10-09 12:00 ` [PATCH v2 3/6] doc: git-rebase: " Julia Evans via GitGitGadget
2026-10-09 18:22 ` Junio C Hamano
2026-10-09 12:00 ` [PATCH v2 4/6] doc: git-revert: " Julia Evans via GitGitGadget
2026-10-09 18:24 ` Junio C Hamano
2026-10-09 12:00 ` [PATCH v2 5/6] doc: git-cherry-pick: " Julia Evans via GitGitGadget
2026-10-09 18:26 ` Junio C Hamano
2026-10-09 12:00 ` [PATCH v2 6/6] doc: git-pull: " Julia Evans via GitGitGadget
2026-10-09 18:27 ` Junio C Hamano
2026-10-09 15:41 ` [PATCH v2 0/6] [doc] Add new page on merge conflicts Junio C Hamano
2026-10-09 15:53 ` Julia Evans
2026-10-09 18:36 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a1686a2d82ef9357ecff07c1247092d3dd5ecf95.1790261062.git.gitgitgadget@gmail.com \
--to=gitgitgadget@gmail.com \
--cc=git@vger.kernel.org \
--cc=julia@jvns.ca \
--cc=ps@pks.im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox