Re: [PATCH v2 06/20] merge-recursive: don't force external callers to do our logging

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jul 26, 2019 at 12:57 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> Elijah Newren <newren@xxxxxxxxx> writes:
>
> > 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.
>
> Interesting.  It seems that b520abf1c8f did a suboptimal jobs but
> this step cleans it up quite nicely.
>
> Are there callers of merge_trees() in other codepaths, and do they
> want this change?
>
> There is only one, builtin/checkout.c::merge_working_tree(), which
> is used when switching to a different commit.  I think it would not
> hurt to give the same warning (but I also think it would not hurt to
> simply disable rename detection in that context); we should record
> the whatever decision we make in the log message.

I was surprised to read this because I thought I did that...but I
guess that was in patch 15 for a slightly different case.  Yeah, I can
add some words to the commit message about this.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux