summaryrefslogtreecommitdiff
path: root/cache-tree.c
diff options
context:
space:
mode:
authorElijah Newren <newren@gmail.com>2019-08-17 18:41:31 (GMT)
committerJunio C Hamano <gitster@pobox.com>2019-08-19 17:08:03 (GMT)
commit345480d1ed462135d98e99cb5b5a426da27257c8 (patch)
treed08c98200023dc13dbb98959cccf3c0bf1f0901d /cache-tree.c
parentb4db8a2b768742f4f43d4a6cdb1db39c2ffc9f7f (diff)
downloadgit-345480d1ed462135d98e99cb5b5a426da27257c8.zip
git-345480d1ed462135d98e99cb5b5a426da27257c8.tar.gz
git-345480d1ed462135d98e99cb5b5a426da27257c8.tar.bz2
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>
Diffstat (limited to 'cache-tree.c')
0 files changed, 0 insertions, 0 deletions