Re: [RFC] Bump {diff,merge}.renameLimit ?

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Mon, Jul 12 2021, Elijah Newren wrote:

> Hi Ævar,
>
> Thanks for reading and commenting.  You certainly brought a new angle
> to the question...
>
> On Sun, Jul 11, 2021 at 10:00 AM Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> wrote:
>>
>> On Sat, Jul 10 2021, Elijah Newren wrote:
>>
>> > I'm considering bumping {diff,merge}.renameLimit, which control the
>> > quadratic portion of rename/copy detection.  Should they be bumped?
>> > If so, moderately higher, or much higher?
>> >
>> > I lean towards a moderate bump for diff.renameLimit, and preferably
>> > more than just a moderate bump for merge.renameLimit.  I have
>> > calculations for what "moderate" translates to, based on a number of
>> > assumptions.  But there's several reasons to break with past
>> > guideposts for how these limits were picked.  See below for various
>> > arguments in each of the directions.
>> >
>> > So...thoughts?
>>
>> I think the most relevant is something you didn't state: That when this
>> limit was introduced (well, diff.*, not merge.*) there was no progress
>> output in git.
>
> I am convinced that good progress output is very important.  I've
> submitted multiple patches for progress output specifically for rename
> detection[1]
>
> However, I am not convinced that the lack of progress output in git
> when this limit was introduced is the most relevant thing.  If it
> were, then the lively thread when Peff posted his past series to both
> introduce the progress output for rename detection and simultaneously
> bump the limits probably would have spurred comments about not needing
> both[2].

I see I had a dead-end reply in that thread in 2011 (didn't spot the
progress patch there).

...

>> We should err entirely on producing consistent and predictable results,
>> and not change how git works when we it hits some arbitrary limit. To
>> the extent that this is needed it's sufficient to opt-in to it, i.e. we
>> do/should show a progress bar, advice() etc. showing why we're doing
>> this much work, so those users can adjust the limit (or not).

> So I've read and re-read your response multiple times, but I am still
> not sure what you're advocating for.  I think you're either advocating
> for rename detection to be turned off by default, or for a new
> "unlimited" mode to be introduced and be the default (maybe even
> redefining what the value of "0" means in order to implement this),
> but I can't tell which.  Could you clarify?

I'm advocating for an "unlimited" default as long as we have
progress/advice or whatever other output would direct users for whom
it's very slow to tweaking the setting (or not).

Anyway, yes some may disagree with this stance. I'm not saying it's
demonstrably obvious that we should have "unlimited".

I do think that it's much better if git behaves that way, i.e. that we
don't have arbitrary limits that completely change behavior once they're
tripped.

Better to spend more CPU, and if it's too slow for someone they can
tweak the limits.

> [1] In particular:
>    d6861d0258df (progress: fix progress meters when dealing with lots
> of work, 2017-11-13)
>    9268cf4a2ef6 (sequencer: show rename progress during cherry picks,
> 2017-11-13)
>    81c4bf02964e (diffcore-rename: reduce jumpiness in progress
> counters, 2020-12-11)
>
> [2] See https://lore.kernel.org/git/20110219101936.GB20577@sigill.intra.peff.net/