Thread (3 messages) 3 messages, 3 authors, 2018-09-01

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

flat view

From: Junio C Hamano <hidden>
Date: 2018-08-30 15:44:22

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help