Elijah Newren [off-list ref] writes:
quoted
Recent addition of "directory rename" heuristics to the
merge-recursive backend makes the command susceptible to false
positives and false negatives, but the risk is even more grave when
used in the context of "git am -3", which does not know about any
surrounding unmodified paths while inspecting a patch. The
heuristic is disabled to keep the machinery "more stupid but
predicable".
I had separate comments about the SQUASH patch in the relevant thread,
but I've got a few comments on the release note itself, which I hope
are helpful:
Yes indeed.
- Perhaps change the last sentence to '...heuristic is disabled for
"git am -3" to keep...', just to be slightly more clear about where it
is disabled?
Yes, indeed that is a very good idea.
- Small spelling error: s/predicable/predictable/
This too.
- Do we really want to say "even more" here? I'd rather we left those
two words off or found another rewording. Obviously, I'm biased, but
there's more than just my own opinion of and vested interest in the
directory rename detection feature. I'm afraid users may interpret
this sentence as saying the git project feels we've shipped a
generally bad/unsafe feature, but are only taking corrective action in
the most egregious of cases. That seems to me like a scary message to
send. Maybe I'm just mis-reading what you meant, but I wanted to at
least check what you meant here and, if that meaning was not
intentional, ask whether we could improve the wording.
I am biased towards "keep it stupid and simple and predictable"
camp, and want to make sure that users do not to blindly trust
overly-clever behaviour of the tool. As heuristics can always make
mistakes either way, I felt that not saying "more" would be sending
the opposite message---"in normal cases, dir-rename code will notice
presence or absense of whole-directory renames without mistakes but
when used in 'am -3' it misbehaves".
But it was not my intention to say "it is generally bad/unsafe". I
just wanted to make sure that the users would understand it is "not
fool-proof and can make mistakes".
Suggestions for a better rewrite is very much appreciated.
Thanks.
On Thu, Aug 30, 2018 at 8:44 AM Junio C Hamano [off-list ref] wrote:
Elijah Newren [off-list ref] writes:
quoted
quoted
Recent addition of "directory rename" heuristics to the
merge-recursive backend makes the command susceptible to false
positives and false negatives, but the risk is even more grave when
used in the context of "git am -3", which does not know about any
surrounding unmodified paths while inspecting a patch. The
heuristic is disabled to keep the machinery "more stupid but
predicable".
...
quoted
- Do we really want to say "even more" here? I'd rather we left those
two words off or found another rewording. Obviously, I'm biased, but
there's more than just my own opinion of and vested interest in the
directory rename detection feature. I'm afraid users may interpret
this sentence as saying the git project feels we've shipped a
generally bad/unsafe feature, but are only taking corrective action in
the most egregious of cases. That seems to me like a scary message to
send. Maybe I'm just mis-reading what you meant, but I wanted to at
least check what you meant here and, if that meaning was not
intentional, ask whether we could improve the wording.
I am biased towards "keep it stupid and simple and predictable"
camp, and want to make sure that users do not to blindly trust
overly-clever behaviour of the tool. As heuristics can always make
mistakes either way, I felt that not saying "more" would be sending
the opposite message---"in normal cases, dir-rename code will notice
presence or absense of whole-directory renames without mistakes but
when used in 'am -3' it misbehaves".
But it was not my intention to say "it is generally bad/unsafe". I
just wanted to make sure that the users would understand it is "not
fool-proof and can make mistakes".
Suggestions for a better rewrite is very much appreciated.
That makes sense. I'm not sure I can concisely convey all the right
points, but here's a stab at rewording:
Recent addition of "directory rename" heuristics to the
merge-recursive backend makes the command susceptible to false
positives and false negatives. In the context of "git am -3", which
does not know about surrounding unmodified paths and thus cannot
inform the merge machinery about the full trees involved, this risk is
particularly severe. As such, the heuristic is disabled for "git am
-3" to keep the machinery "more stupid but predictable".
On 30 August 2018 21:41:35 GMT+05:30, Elijah Newren [off-list ref] wrote:
That makes sense. I'm not sure I can concisely convey all the right
points, but here's a stab at rewording:
Recent addition of "directory rename" heuristics to the
merge-recursive backend makes the command susceptible to false
positives and false negatives. In the context of "git am -3", which
does not know about surrounding unmodified paths and thus cannot
inform the merge machinery about the full trees involved, this risk is
particularly severe. As such, the heuristic is disabled for "git am
-3" to keep the machinery "more stupid but predictable".
FWIW, this sounds better to me than the original.
--
Sivaraam
Sent from my Android device with K-9 Mail. Please excuse my brevity.