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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 30, 2018, 15:44 UTC
Message-ID: <xmqqzhx36er2.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <CABPp-BG1VCmCMHe=5qayS0G_Z_=e8aVQ121LWuo-OBuiUxiCYg@mail.gmail.com>

Elijah Newren <newren@gmail.com> writes:

Show 11 quoted lines

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

Show 10 quoted lines

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