git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Elijah Newren <newren@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Derrick Stolee <stolee@gmail.com>,
	Elijah Newren via GitGitGadget <gitgitgadget@gmail.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH 3/3] diff: correct warning message when renameLimit exceeded
Date: Tue, 13 Jul 2021 18:22:48 -0700	[thread overview]
Message-ID: <CABPp-BFrLd+h0rzkY5nijVLzXh7bUK5t7Go=EY9jZksCeKqQLg@mail.gmail.com> (raw)
In-Reply-To: <xmqqim1dzomt.fsf@gitster.g>

On Tue, Jul 13, 2021 at 6:10 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Elijah Newren <newren@gmail.com> writes:
>
> > The exhaustiveness of the quadratic portion comes from comparing each
> > file to more other files, not in using a different type of comparison.
>
> Exactly.  By culling potential matches early with heuristics, we
> make a trade-off of risking false-negatives but save a lot of cycles
> while trying to find "renames with modifications (which is what we
> called 'inexact rename')", and my comment equated  fewer false-negatives
> with more precision.

Okay, I think I'm following what you're saying now, mostly, but I'm
curious about the false negative comment.

Am I mixing up negatives/positives (as I'm prone to do), or would it
be more correct to say the new algorithm risks suboptimal positives
rather than that it risks false negatives?

In particular, the new algorithm will compare files with the same
basename and just accept that pairing if they are similar enough, even
if there might be a better match elsewhere.  However, a lack of a
match in same-basenamed files will not cause those files to have no
match; they will instead just be included in the exhaustive detection
portion, so we can still detect renames for such paths.

  reply	other threads:[~2021-07-14  1:23 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-11  0:46 [PATCH 0/3] Improve the documentation and warnings dealing with rename/copy limits Elijah Newren via GitGitGadget
2021-07-11  0:46 ` [PATCH 1/3] doc: clarify documentation for " Elijah Newren via GitGitGadget
2021-07-11  4:37   ` Bagas Sanjaya
2021-07-11  4:52     ` Elijah Newren
2021-07-12 15:03   ` Derrick Stolee
2021-07-12 21:27     ` Junio C Hamano
2021-07-11  0:46 ` [PATCH 2/3] doc: document the special handling of -l0 Elijah Newren via GitGitGadget
2021-07-11  4:54   ` Eric Sunshine
2021-07-11  4:54     ` Elijah Newren
2021-07-11  0:46 ` [PATCH 3/3] diff: correct warning message when renameLimit exceeded Elijah Newren via GitGitGadget
2021-07-12 15:09   ` Derrick Stolee
2021-07-12 18:13     ` Elijah Newren
2021-07-14  0:47       ` Junio C Hamano
2021-07-14  1:06         ` Elijah Newren
2021-07-14  1:10           ` Junio C Hamano
2021-07-14  1:22             ` Elijah Newren [this message]
2021-07-14  5:17               ` Junio C Hamano
2021-07-14 15:09                 ` Elijah Newren
2021-07-14  1:12 ` [PATCH v2 0/4] Rename/copy limits -- docs, warnings, and new defaults Elijah Newren via GitGitGadget
2021-07-14  1:12   ` [PATCH v2 1/4] diff: correct warning message when renameLimit exceeded Elijah Newren via GitGitGadget
2021-07-14  1:12   ` [PATCH v2 2/4] doc: clarify documentation for rename/copy limits Elijah Newren via GitGitGadget
2021-07-14  7:37     ` Ævar Arnfjörð Bjarmason
2021-07-14 16:30       ` Elijah Newren
2021-07-14 22:08         ` Ævar Arnfjörð Bjarmason
2021-07-14 22:56           ` Elijah Newren
2021-07-14  1:12   ` [PATCH v2 3/4] doc: document the special handling of -l0 Elijah Newren via GitGitGadget
2021-07-14 16:45     ` Jeff King
2021-07-14 17:17       ` Elijah Newren
2021-07-14 17:33         ` Jeff King
2021-07-14 19:32           ` Elijah Newren
2021-07-14  1:12   ` [PATCH v2 4/4] Bump rename limit defaults (yet again) Elijah Newren via GitGitGadget
2021-07-14 16:43     ` Jeff King
2021-07-14 17:32       ` Elijah Newren
2021-07-14 17:57         ` Jeff King
2021-07-14 20:03           ` Elijah Newren
2021-07-14 20:47             ` Jeff King
2021-07-15  0:45   ` [PATCH v3 0/4] Rename/copy limits -- docs, warnings, and new defaults Elijah Newren via GitGitGadget
2021-07-15  0:45     ` [PATCH v3 1/4] diff: correct warning message when renameLimit exceeded Elijah Newren via GitGitGadget
2021-07-15  0:45     ` [PATCH v3 2/4] doc: clarify documentation for rename/copy limits Elijah Newren via GitGitGadget
2021-07-15  0:45     ` [PATCH v3 3/4] diffcore-rename: treat a rename_limit of 0 as unlimited Elijah Newren via GitGitGadget
2021-07-15 23:17       ` Junio C Hamano
2021-07-15  0:45     ` [PATCH v3 4/4] Bump rename limit defaults (yet again) Elijah Newren via GitGitGadget
2021-07-15 13:36     ` [PATCH v3 0/4] Rename/copy limits -- docs, warnings, and new defaults Derrick Stolee
2021-07-15 23:20     ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABPp-BFrLd+h0rzkY5nijVLzXh7bUK5t7Go=EY9jZksCeKqQLg@mail.gmail.com' \
    --to=newren@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=stolee@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).