[PATCH v5 0/1] mergetool: remove unconflicted lines

There's not much to say other that what the commit message of the patch says.

Note: no feedback has been ignored; I replied to all the feedback, I didn't hear anything back.

Changes since v4:

 * Improved commit message with suggestions from Phillip Wood.

Felipe Contreras (1):
  mergetool: add automerge configuration

 Documentation/config/mergetool.txt |  3 +++
 git-mergetool.sh                   | 17 +++++++++++++++++
 t/t7610-mergetool.sh               | 18 ++++++++++++++++++
 3 files changed, 38 insertions(+)

Range-diff:
1:  776c1fbb97 ! 1:  2dc53f4dda mergetool: add automerge configuration
    @@ Metadata
      ## Commit message ##
         mergetool: add automerge configuration
     
    -    It doesn't make sense to display lines without conflicts in the
    -    different views of all mergetools.
    +    The purpose of mergetools is to resolve conflicts when git cannot
    +    automatically do so.
     
    -    Only the lines that warrant conflict markers should be displayed.
    +    In order to do that git has added markers in the specific areas that
    +    need resolving, which the user must manually fix. The tool is supposed
    +    to help with that.
     
    -    Most people would want this behavior on, but in case some don't; add a
    -    new configuration: mergetool.autoMerge.
    +    However, by passing the original BASE, LOCAL, and REMOTE files, many
    +    changes without conflict are presented to the user when in fact nothing
    +    needs to be done for those.
    +
    +    We can fix that by propagating the final version of the file with the
    +    automatic merge to all the panes of the mergetool (BASE, LOCAL, and
    +    REMOTE), and only make them differ on the places where there are actual
    +    conflicts.
    +
    +    As most people will want the new behavior, we enable it by default.
    +    Users that do not want the new behavior can set the new configuration
    +    mergetool.autoMerge to false.
     
         See Seth House's blog post [1] for the idea, and the rationale.