Allow specifying specialized merge-backend per path.

This allows 'merge' attribute to control how the file-level
three-way merge is done per path.

 - If you set 'merge' to true, leave it unspecified, or set it
   to "text", we use the built-in 3-way xdl-merge.

 - If you set 'merge' to false, or set it to "binary, the
   "binary" merge is done.  The merge result is the blob from
   'our' tree, but this still leaves the path conflicted, so
   that the mess can be sorted out by the user.  This is
   obviously meant to be useful for binary files.

 - 'merge=union' (this is the first example of a string valued
   attribute, introduced in the previous one) uses the "union"
   merge.  The "union" merge takes lines in conflicted hunks
   from both sides, which is useful for line-oriented files such
   as .gitignore.

Instead fo setting merge to 'true' or 'false' by using 'merge'
or '-merge', setting it explicitly to "text" or "binary" will
become useful once we start allowing custom per-path backends to
be added, and allow them to be activated for the default
(i.e. 'merge' attribute specified to 'true' or 'false') case,
using some other mechanisms.  Setting merge attribute to "text"
or "binary" will be a way to explicitly request to override such
a custom default for selected paths.

Currently there is no way to specify random programs but it
should be trivial for motivated contributors to add later.

There is one caveat, though.  ll_merge() is called for both
internal ancestor merge and the outer "final" merge.  I think an
interactive custom per-path merge backend should refrain from
going interactive when performing an internal merge (you can
tell it by checking call_depth) and instead just call either
ll_xdl_merge() if the content is text, or call ll_binary_merge()
otherwise.

Signed-off-by: Junio C Hamano <junkio@cox.net>

0 files changed, 0 insertions, 0 deletions