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

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
[off-list ref] wrote:

quoted

On Sat, Jul 10 2021, Elijah Newren wrote:

quoted

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).

...

quoted

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/ (local)