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

From: Elijah Newren <newren@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: What's cooking in git.git (Aug 2018, #06; Wed, 29)
Date: Thu, 30 Aug 2018 09:11:35 -0700	[thread overview]
Message-ID: <CABPp-BE43kFwRZ90-EWB9Em6xk-T=QfNXCepY=0O5OYYZe-qAg@mail.gmail.com> (raw)
In-Reply-To: <xmqqzhx36er2.fsf@gitster-ct.c.googlers.com>

On Thu, Aug 30, 2018 at 8:44 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> 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.

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