On Wed, Feb 27, 2019 at 08:02:35AM -0800, Elijah Newren wrote: > > > I have found what I suspect to be a bug, or at least not desirable > > > behavior in my case. In one branch, I have moved all files in a > > > directory to another directory. The first directory is now empty > > > in this branch (I haven't tested whether this is significant). > > > > I suspect that because you've moved all the files git thinks the > > directory has been renamed and that's why it moves a/file2 when fix is > > cherry-picked in the example below. I've cc'd Elijah as he knows more > > about how the directory rename detection works. > > Yes, Phillip is correct. If the branch you were > merging/cherry-picking still had any files at all in the original > directory, then no directory rename would be detected. You can read > up more details about how it works at > https://git.kernel.org/pub/scm/git/git.git/tree/Documentation/technical/directory-rename-detection.txt Is there a way to disable it (either by config, or for a single run)? I know there's merge.renames, but it's plausible somebody might want file-level renames but not directory-level ones. -Peff
