[PATCH v4 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

Changed in v4:

changes to the content:

 * use Junio's much better example for diff3
 * clarify in the commit message why we're not mentioning git apply: to
   avoid dealing with patches (thanks to Junio)
 * adjust the wording around "multi-step operation like a rebase" (thanks to
   Junio)
 * Say "see git-config for more" in the description of zdiff3. Like Patrick
   said the explanation of zdiff3 is not really satisfiying, but I don't
   know how to write a satisfying explanation, and it's better to have a
   short and obviously unsatisfying explanation than a long unsatisfying
   one. Added a note in the commit message that perhaps this should be
   improved in the future. (from Patrick's comment)

changes cleaning things up:

 * add periods at the ends of various sentences in an attempt to be more
   consistent (thanks to Junio & Patrick)
 * Adjust the formatting around the [NOTE] to make the CI whitespace check
   pass
 * Replace a couple of instances of "code" with "lines" (thanks to Junio)
 * Fix Ben's email address (thanks to Ben)
 * Remove the double signoff (thanks to Ben).
 * Make the cherry-pick commit message more accurate (thanks to Patrick)

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 | 339 +++++++++++++++++++++++++++
 Documentation/meson.build            |   1 +
 command-list.txt                     |   1 +
 10 files changed, 366 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-v4
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2237/jvns/merge-conflicts-v4
Pull-Request: https://github.com/gitgitgadget/git/pull/2237

Range-diff vs v3:

 1:  7aa0ae7ec3 ! 1:  486a77dbd7 doc: add new gitmergeconflicts man page
     @@ Commit message
      
          - The process for resolving a merge conflict is only explained in the
            `git merge` man page, even though there are several other commands
     -      which can result in conflicts
     +      which can result in conflicts.
          - Sometimes we use "ours" and "theirs" to refer to the two sides of
            the merge conflicts and sometimes we use HEAD and MERGE_HEAD. It should
            be consistent. Also the terms "ours" and "theirs" are not explained.
            Similarly, it says "The part before the `=======` is typically your
            side...", but doesn't explain what "typically" means.
          - It introduces the merge format using an analogy to RCS, which very few
     -      Git users have ever used
     +      Git users have ever used.
          - In "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.", it's not clear to users what "2" and "3" are supposed
     -      to mean
     +      to mean.
          - It uses a cultural reference ("Conflict resolution is hard; let's go
            shopping.") which is confusing or unfamiliar to some people. I think it
            would be clearer for users to use a code example instead.
     -    - It doesn't explain the difference between diff3 and zdiff3
     -    - It sometimes uses the term "area" and sometimes uses the term "hunk"
     +    - It doesn't explain the difference between diff3 and zdiff3.
     +    - It sometimes uses the term "area" and sometimes uses the term "hunk".
      
          Also document the unified `--abort`, `--continue` workflow in one
          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`.
     +    there are other ways that merge conflicts can happen to avoid getting
     +    into the difference between applying a patch and doing a 3-way merge.
     +
     +    Things to potentially improve in future docs revisions:
     +
     +    - The explanation of zdiff3 is unsatisfying. It would be good if we
     +      could have a clear example of a case where zdiff3 is helpful and a
     +      case where it's harmful, and if we could give a better sense for
     +      the reasons why users are actually choosing zdiff3 over diff3
     +      (or the reverse) in real life.
      
          Co-Authored-By: Marie Claire LeBlanc Flanagan <hello@marieflanagan.com>
     -    Helped-by: D. Ben Knoble <ben.knoble+github@gmail.com>
     +    Helped-by: D. Ben Knoble <ben.knoble@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>
      
     @@ Documentation/gitmergeconflicts.adoc (new)
      +  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
     ++* Or (if you're in a multi-step operation like a rebase) skip the problematic
     ++  commit with the appropriate `--skip` command.
      +
      +WHAT IS A MERGE CONFLICT?
      +-------------------------
     @@ Documentation/gitmergeconflicts.adoc (new)
      +  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 -- one side added "cherry" and the other side
     -+added "banana":
     ++fruits in different ways -- one side has "cherry" and the other side
     ++has "banana":
      +
      +----
      +FRUITS = [
     @@ Documentation/gitmergeconflicts.adoc (new)
      +]
      +----
      +
     -+The code from one side of the merge conflict is between `<<<<<<<` and
     -+`=======`, and the code for the other side is between `=======` and
     ++The lines from one side of the merge conflict is between `<<<<<<<` and
     ++`=======`, and the lines from the other side is between `=======` and
      +`>>>>>>>`. See <<ours,"OURS" AND "THEIRS">> below for a full explanation
      +of which side is which.
      +
     @@ Documentation/gitmergeconflicts.adoc (new)
      +
      +The process for resolving a merge conflict is:
      +
     -+1. Run `git status` to get a list of files with merge conflicts
     ++1. Run `git status` to get a list of files with merge conflicts.
      +2. For each one, find the conflict markers
     -+   (the `<<<<<<<`, `=======`, `>>>>>>>`) and edit the code to
     -+   fix the conflict
     -+3. Run `git add FILENAME` for each file to mark the conflict as resolved
     ++   (the `<<<<<<<`, `=======`, `>>>>>>>`) and edit the file to
     ++   fix the conflict.
     ++3. Run `git add FILENAME` for each file to mark the conflict as resolved.
      +4. Run the appropriate `--continue` command to continue the operation
      +   that was interrupted by the conflict, for example `git merge --continue`
      +   or `git rebase --continue`. See <<git_status,EXAMPLE: GIT STATUS OUTPUT>>
     @@ Documentation/gitmergeconflicts.adoc (new)
      +* 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
     ++* `git log --merge --patch <filename>`  will list all commits which
      +  caused the merge conflict for `<filename>`, and the diff
      +  of how they changed the file.
      +
     @@ Documentation/gitmergeconflicts.adoc (new)
      +`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.
     -+
      +----
      +FRUITS = [
      +    "apple",
     @@ Documentation/gitmergeconflicts.adoc (new)
      +    "cherry",
      +    "mango",
      +||||||| 1c22e48
     ++	"banana",
     ++	"cherry",
      +    "mangoooo",
      +=======
      +    "banana",
     @@ Documentation/gitmergeconflicts.adoc (new)
      +]
      +----
      +
     ++With this view, you can see that both sides fixed a spelling
     ++mistake in "mango", and each removed one fruit to the list.
     ++This makes it more clear how to resolve the merge conflict: since one
     ++side removed `banana` and one side removed `cherry`, it would probably
     ++make sense to remove both from the list, like this:
     ++
     ++----
     ++FRUITS = [
     ++    "apple",
     ++    "mango",
     ++    "orange",
     ++]
     ++----
     ++
      +[NOTE]
     -+================================
      +`zdiff3` is an alternative to `diff3` that makes the merge conflict
     -+shorter by making it more ambiguous.
     -+================================
     ++shorter by making it more ambiguous. See linkgit:git-config[1] for more.
      +
      +[[ours]]
      +"OURS" AND "THEIRS"
 2:  8bdbd64ca3 = 2:  6862cb4f04 doc: git-merge: link to new merge conflicts guide
 3:  34ba85fcad = 3:  2bd9850822 doc: git-rebase: link to new merge conflicts guide
 4:  85e117b070 = 4:  53083b48a3 doc: git-revert: link to new merge conflicts guide
 5:  f99c99f955 ! 5:  92cfdf260c doc: git-cherry-pick: link to new merge conflicts guide
     @@ Metadata
       ## Commit message ##
          doc: git-cherry-pick: link to new merge conflicts guide
      
     -    Remove the discussion of merge conflicts and replace it with a link to
     -    the guide.
     -
          Signed-off-by: Julia Evans <julia@jvns.ca>
      
       ## Documentation/git-cherry-pick.adoc ##
 6:  7831b77178 = 6:  bbbf44aff1 doc: git-pull: link to new merge conflicts guide

-- 
gitgitgadget