Git development
 help / color / mirror / Atom feed
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


  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