Re: What's cooking in git.git (Aug 2018, #06; Wed, 29)

>
> Elijah Newren <newren@gmail.com> writes:
>
> >>  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".

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