[PATCH v5 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-v5
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2237/jvns/merge-conflicts-v5
Pull-Request: https://github.com/gitgitgadget/git/pull/2237

Range-diff vs v4:

 1:  486a77dbd7 ! 1:  8b526e2bd7 doc: add new gitmergeconflicts man page
     @@ Commit message
          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@gmail.com>
          Helped-by: Patrick Steinhardt <ps@pks.im>
     @@ Documentation/gitmergeconflicts.adoc (new)
      +    "cherry",
      +    "mango",
      +||||||| 1c22e48
     -+	"banana",
     -+	"cherry",
     ++    "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.
     ++mistake in "mango", and each removed one fruit from 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:
 2:  6862cb4f04 = 2:  3dc763a2a2 doc: git-merge: link to new merge conflicts guide
 3:  2bd9850822 = 3:  02351af1b5 doc: git-rebase: link to new merge conflicts guide
 4:  53083b48a3 = 4:  10f8947b68 doc: git-revert: link to new merge conflicts guide
 5:  92cfdf260c = 5:  e1fe1c4aa3 doc: git-cherry-pick: link to new merge conflicts guide
 6:  bbbf44aff1 = 6:  4f434f5acd doc: git-pull: link to new merge conflicts guide

-- 
gitgitgadget