Elijah Newren [off-list ref] writes:
This is not true. If src/main.c is 99% similar to src/foo.c, and is
0% similar to the src/main.c in the new commit, we match the old
src/main.c to the new src/main.c despite being far more similar
src/foo.c. Unless break detection is turned on, we do not allow
content similarity to trump (full) filename equality.
Absolutely. And we are talking about a new optimization that kicks
in only when there is no break or no copy detection going on, no?
On Sat, Feb 13, 2021 at 3:56 PM Junio C Hamano [off-list ref] wrote:
Elijah Newren [off-list ref] writes:
quoted
This is not true. If src/main.c is 99% similar to src/foo.c, and is
0% similar to the src/main.c in the new commit, we match the old
src/main.c to the new src/main.c despite being far more similar
src/foo.c. Unless break detection is turned on, we do not allow
content similarity to trump (full) filename equality.
Absolutely. And we are talking about a new optimization that kicks
in only when there is no break or no copy detection going on, no?
Yes, precisely, we are only considering cases without break
detection...and thus we are considering cases where for the last 15
years or more, sufficiently large filename similarity (an exact
fullname match) trumps any level of content similarity. I think it is
useful to note that while my optimization is adding more
considerations that can overrule maximal content similarity, it is not
the first such code choice to do that.
But let me back up a bit...
When I submitted the series, you and Stolee went into a long
discussion about an optimization that I didn't submit, one that feels
looser on "matching" than anything I submitted, and which I think
might counter-intuitively reduce performance rather than aid it. (The
performance side only comes into view in combination with later
series, but it was why I harped so much since then on only comparing
against at most one other file in the steps before full inexact rename
detection.) I was quite surprised by the diversion, but it made it
clear to me that my descriptions and commit messages were far too
vague and could be read to imply a completely different algorithm than
I intended. So, I tried to be far more careful in subsequent
iterations by adding wider context and contrasts.
Further, after I wrote various things to try to clarify the
misunderstandings, I noticed that Stolee picked out one thing and
stated that "This idea of optimizing first for 100% filename
similarity is a good perspective on Git's rename detection algorithm."
(see https://lore.kernel.org/git/57d30e7d-7727-8d98-e3ef-bcfeebf9edd3@gmail.com/)
So, that particular point seemed to help him understand more, and
thus might be useful extra context for others reading along now or in
the future.
Given all the above, I was trying to address earlier misunderstandings
and provide more context. Perhaps I swung the pendulum too far and
talked too much about other cases, or perhaps I just worded things
poorly again. All I was attempting to do in the commit message was
point out the multiple basic rules with filename and content
similarity, to lay the groundwork for new rules that do alternative
weightings.
Anyway, I've added a few more tweaks to try to improve the wording for
the next round I'll submit today. Given my track record so far, it
would not be surprising if it still needed more tweaks.
I do not consider "the same file changed in place" the same as "we
seem to have lost a file in the old tree, ah, we found one that has
the same basename in a different directory" at all, so your argument
still does not make any sense to me, sorry.
2021年2月13日(土) 17:25 Elijah Newren [off-list ref]:
On Sat, Feb 13, 2021 at 3:56 PM Junio C Hamano [off-list ref] wrote:
quoted
Elijah Newren [off-list ref] writes:
quoted
This is not true. If src/main.c is 99% similar to src/foo.c, and is
0% similar to the src/main.c in the new commit, we match the old
src/main.c to the new src/main.c despite being far more similar
src/foo.c. Unless break detection is turned on, we do not allow
content similarity to trump (full) filename equality.
Absolutely. And we are talking about a new optimization that kicks
in only when there is no break or no copy detection going on, no?
Yes, precisely, we are only considering cases without break
detection...and thus we are considering cases where for the last 15
years or more, sufficiently large filename similarity (an exact
fullname match) trumps any level of content similarity. I think it is
useful to note that while my optimization is adding more
considerations that can overrule maximal content similarity, it is not
the first such code choice to do that.
But let me back up a bit...
When I submitted the series, you and Stolee went into a long
discussion about an optimization that I didn't submit, one that feels
looser on "matching" than anything I submitted, and which I think
might counter-intuitively reduce performance rather than aid it. (The
performance side only comes into view in combination with later
series, but it was why I harped so much since then on only comparing
against at most one other file in the steps before full inexact rename
detection.) I was quite surprised by the diversion, but it made it
clear to me that my descriptions and commit messages were far too
vague and could be read to imply a completely different algorithm than
I intended. So, I tried to be far more careful in subsequent
iterations by adding wider context and contrasts.
Further, after I wrote various things to try to clarify the
misunderstandings, I noticed that Stolee picked out one thing and
stated that "This idea of optimizing first for 100% filename
similarity is a good perspective on Git's rename detection algorithm."
(see https://lore.kernel.org/git/57d30e7d-7727-8d98-e3ef-bcfeebf9edd3@gmail.com/)
So, that particular point seemed to help him understand more, and
thus might be useful extra context for others reading along now or in
the future.
Given all the above, I was trying to address earlier misunderstandings
and provide more context. Perhaps I swung the pendulum too far and
talked too much about other cases, or perhaps I just worded things
poorly again. All I was attempting to do in the commit message was
point out the multiple basic rules with filename and content
similarity, to lay the groundwork for new rules that do alternative
weightings.
Anyway, I've added a few more tweaks to try to improve the wording for
the next round I'll submit today. Given my track record so far, it
would not be surprising if it still needed more tweaks.
On Sat, Feb 13, 2021 at 5:32 PM Junio C Hamano [off-list ref] wrote:
I do not consider "the same file changed in place" the same as "we
seem to have lost a file in the old tree, ah, we found one that has
the same basename in a different directory" at all, so your argument
still does not make any sense to me, sorry.
I'm not set on the commit message wording, you asked why I had used
the terms I did and I tried to explain. I also explained how the
wording seemed to have helped Stolee understand.
If you'd like to suggest an alternative commit message, I'm happy to take it.
2021年2月13日(土) 17:25 Elijah Newren [off-list ref]:
quoted
On Sat, Feb 13, 2021 at 3:56 PM Junio C Hamano [off-list ref] wrote:
quoted
Elijah Newren [off-list ref] writes:
quoted
This is not true. If src/main.c is 99% similar to src/foo.c, and is
0% similar to the src/main.c in the new commit, we match the old
src/main.c to the new src/main.c despite being far more similar
src/foo.c. Unless break detection is turned on, we do not allow
content similarity to trump (full) filename equality.
Absolutely. And we are talking about a new optimization that kicks
in only when there is no break or no copy detection going on, no?
Yes, precisely, we are only considering cases without break
detection...and thus we are considering cases where for the last 15
years or more, sufficiently large filename similarity (an exact
fullname match) trumps any level of content similarity. I think it is
useful to note that while my optimization is adding more
considerations that can overrule maximal content similarity, it is not
the first such code choice to do that.
But let me back up a bit...
When I submitted the series, you and Stolee went into a long
discussion about an optimization that I didn't submit, one that feels
looser on "matching" than anything I submitted, and which I think
might counter-intuitively reduce performance rather than aid it. (The
performance side only comes into view in combination with later
series, but it was why I harped so much since then on only comparing
against at most one other file in the steps before full inexact rename
detection.) I was quite surprised by the diversion, but it made it
clear to me that my descriptions and commit messages were far too
vague and could be read to imply a completely different algorithm than
I intended. So, I tried to be far more careful in subsequent
iterations by adding wider context and contrasts.
Further, after I wrote various things to try to clarify the
misunderstandings, I noticed that Stolee picked out one thing and
stated that "This idea of optimizing first for 100% filename
similarity is a good perspective on Git's rename detection algorithm."
(see https://lore.kernel.org/git/57d30e7d-7727-8d98-e3ef-bcfeebf9edd3@gmail.com/)
So, that particular point seemed to help him understand more, and
thus might be useful extra context for others reading along now or in
the future.
Given all the above, I was trying to address earlier misunderstandings
and provide more context. Perhaps I swung the pendulum too far and
talked too much about other cases, or perhaps I just worded things
poorly again. All I was attempting to do in the commit message was
point out the multiple basic rules with filename and content
similarity, to lay the groundwork for new rules that do alternative
weightings.
Anyway, I've added a few more tweaks to try to improve the wording for
the next round I'll submit today. Given my track record so far, it
would not be surprising if it still needed more tweaks.