git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Elijah Newren <newren@gmail.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 22:17:16 -0700	[thread overview]
Message-ID: <xmqq7dhtzd7n.fsf@gitster.g> (raw)
In-Reply-To: CABPp-BFrLd+h0rzkY5nijVLzXh7bUK5t7Go=EY9jZksCeKqQLg@mail.gmail.com

Elijah Newren <newren@gmail.com> writes:

> 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?

I'm prone to mixing them up, too, but I think they are the sides of
the same coin.  Imagine there is a path X on the source side, and
two paths Y and Z on the destination side.  With exhaustive match,
Z might be a better match (content-wise) to X than Y is to X.

For the path X on the source that is matched with a suboptimal
counterpart Y on the destination side, we may call the situation a
false-positive because with a more exhaustive search we might have
been able to find Z that is a better match.  For the path Z on the
destination side that was culled too early with heuristics and
failed to be matched with the source path X that got matched with a
suboptimal destination path Y, it is a loss for Z---it wasn't chosen
when it should have been (i.e. a false negative, as Z saw no
counterparts).

In any case, during the word search for "inexact", "more precise",
"more expensive", I do not think negatives and positives will play a
big role anyway, so...

  reply	other threads:[~2021-07-14  5:17 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
2021-07-14  5:17               ` Junio C Hamano [this message]
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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=xmqq7dhtzd7n.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=newren@gmail.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).