Re: [PATCH 2/3] merge-ort: allow rename detection to be disabled

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

 



On Wed, Mar 12, 2025 at 09:06:35AM +0100, Patrick Steinhardt wrote:
> On Fri, Mar 07, 2025 at 03:48:41PM +0000, Elijah Newren via GitGitGadget wrote:
> > From: Elijah Newren <newren@xxxxxxxxx>
> >
> > When merge-ort was written, I did not at first allow rename detection to
> > be disabled, because I suspected that most folks disabling rename
> > detection were doing so solely for performance reasons.  Since I put a
> > lot of working into providing dramatic speedups for rename detection
> > performance as used by the merge machinery, I wanted to know if there
> > were still real world repositories where rename detection was
> > problematic from a performance perspective.  We have had years now to
> > collect such information, and while we never received one, waiting
> > longer with the option disabled seems unlikely to help surface such
> > issues at this point.  Also, there has been at least one request to
> > allow rename detection to be disabled for behavioral rather than
> > performance reasons, so let's start heeding the config and command line
> > settings.
>
> It might be nice to provide a link to that request for more context.

I don't know if a link exists; I suspect the request referred to here is
an email that Johannes Schindelin wrote to Elijah privately).

But I am almost certain that the behavior requested here is to disable
rename detection to match the behavior of GitHub's prior use of libgit2
to perform merges, where we also had rename detection disabled (for
reasons that are unclear to me, but Peff might know).

> > diff --git a/merge-ort.c b/merge-ort.c
> > index b4ff24403a1..a6960b6a1b4 100644
> > --- a/merge-ort.c
> > +++ b/merge-ort.c
> > @@ -3448,6 +3448,11 @@ static int detect_and_process_renames(struct merge_options *opt)
> >
> >  	if (!possible_renames(renames))
> >  		goto cleanup;
> > +	if (opt->detect_renames == 0) {

    if (!opt->detect_renames)

?

> > +		renames->redo_after_renames = 0;
> > +		renames->cached_pairs_valid_side = 0;
> > +		goto cleanup;
> > +	}
> >
> >  	trace2_region_enter("merge", "regular renames", opt->repo);
> >  	detection_run |= detect_regular_renames(opt, MERGE_SIDE1);
>
> Do we want to add a test that demonstrates that the option works as
> expected?

Yeah, having a test here would be nice.

Thanks,
Taylor




[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