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

[Elijah Newren <newren@gmail.com>]

Hi Junio,

On Wed, Aug 29, 2018 at 3:38 PM Junio C Hamano <gitster@pobox.com> wrote:

> * en/directory-renames-nothanks (2018-08-29) 4 commits
>  - SQUASH???
>  - am: avoid directory rename detection when calling recursive merge machinery
>  - merge-recursive: add ability to turn off directory rename detection
>  - t3401: add another directory rename testcase for rebase and am
>
>  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:

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

- Small spelling error: s/predicable/predictable/

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

Thanks,
Elijah