Elijah Newren <new...@gmail.com> writes: >> Rename detection logic in "diff" family that is used in "merge" has >> learned to guess when all of x/a, x/b and x/c have moved to z/a, >> z/b and z/c, it is likely that x/d added in the meantime would also >> want to move to z/d by taking the hint that the entire directory >> 'x' moved to 'z'. Incidentally, this avoids updating a file in the >> working tree after a (non-trivial) merge whose result matches what >> our side originally had. > > Thanks for adding a comment about the fix for the unnecessary update. > However, you've dropped a comment from the original release note about > the other fix this series also provides, namely, "A bug causing dirty > files involved in a rename to be overwritten during merge has also > been fixed as part of this work."
Thanks again.
