[PATCH v3 0/6] [doc] Add new page on merge conflicts

["Julia Evans via GitGitGadget" <gitgitgadget@gmail.com>]

Handling merge conflicts is difficult, and currently Git's guidance on merge
conflicts isn't giving users the information they need to navigate the
process. As usual, the process I used to write this was to collect comments
from Git users on the existing documentation, and then address those issues.
I listed the specific issues we're aiming to solve in the first commit
message in the series.

This patch series introduces a new manual page, gitmergeconflicts, which
explains the process of explaining a merge conflict with examples. It also
links to that new page from the commands which can cause merge conflicts,
instead of trying to reexplain the process every time.

Changed in v2:

 * Explain what a merge conflict is (thanks to Junio & Ben)
 * rewrite the "ours" vs "theirs" section (thanks to Patrick for the
   comments)
 * add git log --merge (thanks to Ben)
 * Leave most of the content of git cherry-pick as-is, to make this patch
   set smaller (thanks to Junio)
 * remove the SYNOPSIS since hopefully that won't be required anymore by the
   time this is merged
 * Fix a typo in git revert (s/reverted conflict/reverted commit/)
 * 's/the the/the/' (thanks to Patrick)
 * s/[doc] Thing/doc: thing/ in commit messages (thanks to Tuomas)'
 * squash the commit fixing the linter error (thanks to Junio)
 * list reviewers in Reviewed-by

Changed in v3:

Thanks to all the comments from Junio.

 * Add signoff from Marie
 * In "For example, here's a merge conflict where both sides edited a list
   of", add a little more detail about how to interpret the merge conflict
 * When we introduce a merge mention "semantic merge conflicts"
 * Say "... and any other command that does a merge" when listing commands
   that can cause merge conflicts.
 * Reviewed-by is not the right thing, use Helped-by
 * Adjust phrasing in git revert and git cherry-pick man pages
 * Reference the "ours" section in "git show :2:filename shows the "ours""
 * "there's one file left with conflicts in it: fruits.py" isn't precise
   enough, instead say "the conflicts in fruits.py haven't been marked as
   resolved"
 * Delete the explanation of zdiff3 and add a brief warning instead. Don't
   be too prescriptive, we should tell people what the issue is (ambiguity)
   instead of trying to impose our opinion.
 * Explain ||||||| when we add diff3
 * Fix example in "EXAMPLE OF RESOLVING A MERGE CONFLICT" to make it
   consistent with the other examples
 * Replace "configuration option" with "configuration variable"
 * Mention --skip instead of saying "the most common ways", which is
   ambiguous
 * Add a pointer to the extended AUTO_MERGE sentence

some non-changes in v3:

 * didn't add any extra Reviewed-by
 * "return your branch to its original state": left the same because during
   a multistep cherry-pick the branch does need to be returned to its
   original state
 * leave the explanation of AUTO_MERGE the same since Marie says it's more
   clear this way
 * leave contractions alone for now
 * don't say semantic merge applies to all merges since I think that will be
   clear to readers
 * the wording of "When Git merges two commits together" is a bit weird but
   we don't have a better idea right now
 * don't explain --left-right. Can be very easily added in the future if we
   think it's important.

Thanks to Lobo, Adam Svahn, Louis Vanier, David Turner, Ben Zanin, Salih,
and about 12 others who gave feedback on both the original git merge man
page, as well as the proposed improvements.

Julia Evans (6):
  doc: add new gitmergeconflicts man page
  doc: git-merge: link to new merge conflicts guide
  doc: git-rebase: link to new merge conflicts guide
  doc: git-revert: link to new merge conflicts guide
  doc: git-cherry-pick: link to new merge conflicts guide
  doc: git-pull: link to new merge conflicts guide

 .gitattributes                       |   1 +
 Documentation/Makefile               |   1 +
 Documentation/git-cherry-pick.adoc   |   8 +-
 Documentation/git-merge.adoc         | 125 +---------
 Documentation/git-pull.adoc          |   3 +-
 Documentation/git-rebase.adoc        |  13 +-
 Documentation/git-revert.adoc        |   5 +
 Documentation/gitmergeconflicts.adoc | 330 +++++++++++++++++++++++++++
 Documentation/meson.build            |   1 +
 command-list.txt                     |   1 +
 10 files changed, 357 insertions(+), 131 deletions(-)
 create mode 100644 Documentation/gitmergeconflicts.adoc


base-commit: 3bc0341126508f78f5869cbfc0005e987efdf0c7
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2237%2Fjvns%2Fmerge-conflicts-v3
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2237/jvns/merge-conflicts-v3
Pull-Request: https://github.com/gitgitgadget/git/pull/2237

Range-diff vs v2:

 1:  ab0344f947 ! 1:  7aa0ae7ec3 doc: add new gitmergeconflicts man page
     @@ Commit message
          place, since it's a really nice example of a place Git has a consistent
          interface between similar commands.
      
     +    Only discuss merge, rebase, cherry-pick, and revert for now even though
     +    there are other ways that merge conflicts can happen because it's
     +    awkward to talk about `am`, `apply`, and `checkout -m`.
     +
          Co-Authored-By: Marie Claire LeBlanc Flanagan <hello@marieflanagan.com>
     -    Reviewed-by: D. Ben Knoble <ben.knoble+github@gmail.com>
     -    Reviewed-by: Patrick Steinhardt <ps@pks.im>
     +    Helped-by: D. Ben Knoble <ben.knoble+github@gmail.com>
     +    Helped-by: Patrick Steinhardt <ps@pks.im>
     +    Signed-off-by: Julia Evans <julia@jvns.ca>
     +    Signed-off-by: Marie Claire LeBlanc Flanagan <hello@marieflanagan.com>
          Signed-off-by: Julia Evans <julia@jvns.ca>
      
       ## .gitattributes ##
     @@ Documentation/gitmergeconflicts.adoc (new)
      +-----------
      +
      +Merge conflicts can happen during a `git merge`, `git rebase`, `git
     -+cherry-pick`, `git pull`, or `git revert`. All of those commands use
     -+the same merge algorithm, and the process for resolving a merge conflict
     -+is always very similar.
     ++cherry-pick`, `git pull`, `git revert`, or any other command that does
     ++a merge. All of those commands use the same merge algorithm, and the
     ++process for resolving a merge conflict is always very similar.
      +
     -+The most common ways to handle a merge conflict are:
     ++There are 3 ways to handle a merge conflict:
      +
      +* Resolve the conflict. (see <<resolve,HOW TO RESOLVE A MERGE CONFLICT>>
      +  below for details)
     -+* Or stop the operation and return your branch to its original state
     ++* Stop the operation and return your branch to its original state
      +  with the appropriate `--abort` command, for example `git merge --abort`
      +  or `git rebase --abort`. See <<git_status,EXAMPLE: GIT STATUS OUTPUT>> below
      +  for how to find the command to run.
     ++* Or (if you're in a multi-step rebase or cherry-pick) skip the problematic
     ++  commit with the appropriate `--skip` command
      +
      +WHAT IS A MERGE CONFLICT?
      +-------------------------
     @@ Documentation/gitmergeconflicts.adoc (new)
      +  sides' edits in the file, and leaves <<markers, merge conflict markers>>
      +  that you need to resolve.
      +
     ++[NOTE]
     ++================================
     ++Even if Git successfully merges both sides with no conflicts, it's
     ++possible to end up with code that doesn't work. For example, this can
     ++happen if one side renames a function, and the other side adds a call to
     ++the old function. This is called a "semantic merge conflict".
     ++================================
     ++
      +[[markers]]
      +MERGE CONFLICT MARKERS
      +----------------------
     @@ Documentation/gitmergeconflicts.adoc (new)
      +When there's a merge conflict, Git will update the conflicted file
      +to include merge conflict markers `<<<<<<<`, `=======`, and `>>>>>>>`.
      +For example, here's a merge conflict where both sides edited a list of
     -+fruits in different ways:
     ++fruits in different ways -- one side added "cherry" and the other side
     ++added "banana":
      +
      +----
      +FRUITS = [
     @@ Documentation/gitmergeconflicts.adoc (new)
      +    "apple",
      +<<<<<<< HEAD
      +    "cherry",
     -+    "mango",
      +=======
      +    "banana",
     -+    "mango",
      +>>>>>>> add-fruit
     ++    "mango",
      +    "orange",
      +]
      +----
     @@ Documentation/gitmergeconflicts.adoc (new)
      +  See also `merge.tool` in linkgit:git-config[1] for a list of
      +  the mergetools Git supports.
      +
     -+* You can set the configuration option `merge.conflictstyle=diff3`.
     -+  See <<diff3,DIFF3 AND ZDIFF3>> below for more.
     ++* You can set the configuration variable `merge.conflictstyle=diff3`.
     ++  See <<diff3,DIFF3>> below for more.
      +
      +* `git log --merge -p <filename>`  will list all commits which
      +  caused the merge conflict for `<filename>`, and the diff
     @@ Documentation/gitmergeconflicts.adoc (new)
      +* Look at the original files.  `git show :1:filename` shows the
      +  common ancestor, `git show :2:filename` shows the "ours"
      +  version, and `git show :3:filename` shows the "theirs"
     -+  version.
     ++  version. See <<ours,"OURS" AND "THEIRS">> below for more on
     ++  "ours" and "theirs".
      +
      +Here are some ways to track your progress while handling a conflict:
      +
     @@ Documentation/gitmergeconflicts.adoc (new)
      +
      +* Use `git diff AUTO_MERGE` to show what changes you've made so far to
      +  resolve the conflicts.
     ++  See <<automerge,EXAMPLE OF USING `AUTO_MERGE`>> below for more.
      +
      +[[git_status]]
      +EXAMPLE: GIT STATUS OUTPUT
     @@ Documentation/gitmergeconflicts.adoc (new)
      +  original state
      +* you should run `git rebase --continue` when you're done resolving all
      +  the conflicts
     -+* there's one file left with conflicts in it: `fruits.py`
     ++* the conflicts in `fruits.py` haven't been marked as resolved
      +
      +----
      +$ git status
     @@ Documentation/gitmergeconflicts.adoc (new)
      +
      +
      +[[diff3]]
     -+DIFF3 AND ZDIFF3
     -+----------------
     ++DIFF3
     ++-----
      +
      +By default, Git doesn't include the original code when formatting
      +a merge conflict. To include the original code, you can set the
     -+configuration option `merge.conflictstyle` to `diff3` or `zdiff3`.
     ++configuration option `merge.conflictstyle` to `diff3`.
      +This extra context can make it much easier to understand what's
      +happening in a merge conflict.
      +
      +Here's an example of what a merge conflict would look like when using
     -+`diff3`. It shows, in order, the "ours" side of the conflict, the
     -+original code (`"mangoooo"`), and the "theirs" side of the
     -+conflict. With this view, you can see that both sides fixed the spelling
     ++`diff3`. There's an extra section (between `|||||||` and `=======`)
     ++with the original code.
     ++
     ++With this view, you can see that both sides fixed a spelling
      +mistake in "mango", and each added one fruit to the list.
      +
      +----
     @@ Documentation/gitmergeconflicts.adoc (new)
      +]
      +----
      +
     -+Here's the same example using `zdiff3`. `zdiff3` takes lines that are
     -+shared between both sides (the `"mango"` line) and moves them outside
     -+the conflicted area. This makes the conflicted area shorter, but the
     -+downside is that it's impossible to tell if `"mango"` was part of the
     -+original list of fruits or not.
     -+
     -+----
     -+FRUITS = [
     -+    "apple",
     -+<<<<<<< HEAD
     -+    "cherry",
     -+||||||| 1c22e48
     -+    "mangoooo",
     -+=======
     -+    "banana",
     -+>>>>>>> add-fruit
     -+    "mango",
     -+    "orange",
     -+]
     -+----
     -+
     ++[NOTE]
     ++================================
     ++`zdiff3` is an alternative to `diff3` that makes the merge conflict
     ++shorter by making it more ambiguous.
     ++================================
      +
      +[[ours]]
      +"OURS" AND "THEIRS"
 2:  d5241eb901 = 2:  8bdbd64ca3 doc: git-merge: link to new merge conflicts guide
 3:  72b1207045 = 3:  34ba85fcad doc: git-rebase: link to new merge conflicts guide
 4:  cfa0a8254a ! 4:  85e117b070 doc: git-revert: link to new merge conflicts guide
     @@ Documentation/git-revert.adoc: both will discard uncommitted changes in your wor
       See "Reset, restore and revert" in linkgit:git[1] for the differences
       between the three commands.
       
     -+If there have been new commits since the reverted commit, there may
     -+be a merge conflict. See linkgit:gitmergeconflicts[7]
     -+(or `git help mergeconflicts`) for a guide to handling merge conflicts.
     ++Reverting a commit may result in a merge conflict.
     ++See linkgit:gitmergeconflicts[7] (or `git help mergeconflicts`)
     ++for a guide to handling merge conflicts.
      +
       OPTIONS
       -------
 5:  62b70e9a02 ! 5:  f99c99f955 doc: git-cherry-pick: link to new merge conflicts guide
     @@ Documentation/git-cherry-pick.adoc: Given one or more existing commits, apply th
       
      -When it is not obvious how to apply a change, the following
      -happens:
     -+When it is not obvious how to apply a change, there may
     -+be a merge conflict. See linkgit:gitmergeconflicts[7]
     -+(or `git help mergeconflicts`) for a guide to handling merge conflicts.
     -+
      +When a merge conflict happens:
       
       1. The current branch and `HEAD` pointer stay at the last commit
     @@ Documentation/git-cherry-pick.adoc: happens:
       
      -See linkgit:git-merge[1] for some hints on resolving such
      -conflicts.
     --
     ++See linkgit:gitmergeconflicts[7] (or `git help mergeconflicts`)
     ++for a guide to handling merge conflicts.
     + 
       OPTIONS
       -------
     - <commit>...::
      @@ Documentation/git-cherry-pick.adoc: $ git cherry-pick -Xpatience topic^  <4>
       SEE ALSO
       --------
 6:  ac77db6762 = 6:  7831b77178 doc: git-pull: link to new merge conflicts guide

-- 
gitgitgadget