]> git.ipfire.org Git - thirdparty/git.git/commit
merge-recursive: don't force external callers to do our logging
authorElijah Newren <newren@gmail.com>
Sat, 17 Aug 2019 18:41:31 +0000 (11:41 -0700)
committerJunio C Hamano <gitster@pobox.com>
Mon, 19 Aug 2019 17:08:03 +0000 (10:08 -0700)
commit345480d1ed462135d98e99cb5b5a426da27257c8
treed08c98200023dc13dbb98959cccf3c0bf1f0901d
parentb4db8a2b768742f4f43d4a6cdb1db39c2ffc9f7f
merge-recursive: don't force external callers to do our logging

Alternatively, you can view this as "make the merge functions behave
more similarly."  merge-recursive has three different entry points:
merge_trees(), merge_recursive(), and merge_recursive_generic().  Two of
these would call diff_warn_rename_limit(), but merge_trees() didn't.
This lead to callers of merge_trees() needing to manually call
diff_warn_rename_limit() themselves.  Move this to the new
merge_finalize() function to make sure that all three entry points run
this function.

Note that there are two external callers of merge_trees(), one in
sequencer.c and one in builtin/checkout.c.  The one in sequencer.c is
cleaned up by this patch and just transfers where the call to
diff_warn_rename_limit() is made; the one in builtin/checkout.c is for
switching to a different commit and in the very rare case where the
warning might be triggered, it would probably be helpful to include
(e.g. if someone is modifying a file that has been renamed in moving to
the other commit, but there are so many renames between the commits that
the limit kicks in and none are detected, it may help to have an
explanation about why they got a delete/modify conflict instead of a
proper content merge in a renamed file).

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge-recursive.c
sequencer.c