Re: [BUG] All files in folder are moved when cherry-picking commit that moves fewer files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux